Am besten verwenden Sie Write Concerns – damit können Sie MongoDB mitteilen, wie wichtig ein Datenelement ist. Der schnellste Write Concern ist auch der unsicherste – die Daten werden erst beim nächsten geplanten Flush auf die Festplatte geschrieben. Der sicherste wird bestätigen, dass die Daten vor der Rückgabe auf einer Reihe von Computern auf die Festplatte geschrieben wurden.
Das gesuchte Write Concern ist FSYNC_SAFE (zumindest heißt es so aus Sicht des Java-Treiber ) oder REPLICAS_SAFE, das bestätigt, dass Ihre Daten repliziert wurden.
Denken Sie daran, dass MongoDB keine Transaktionen im herkömmlichen Sinne hat – Ihr Rollback muss von Hand durchgeführt werden, da Sie die Mongo-Datenbank nicht anweisen können, dies für Sie zu tun.
Die andere Sache, die Sie tun müssen, ist entweder das relativ neue --journal zu verwenden Option (die ein Write-Ahead-Protokoll verwendet) oder verwenden Sie Replikatsätze, um Ihre Daten auf vielen Computern gemeinsam zu nutzen, um die Datenintegrität im Falle eines Absturzes/Stromausfalls zu maximieren.
Sharding ist weniger ein Schutz vor Hardwareausfällen als vielmehr eine Methode zur Lastverteilung bei besonders großen Datensätzen - Sharding sollte nicht mit Replikatsätzen verwechselt werden, bei denen Daten auf mehr als eine Festplatte auf mehr als einem Computer geschrieben werden .
Wenn Ihre Daten wertvoll genug sind, sollten Sie daher auf jeden Fall Replikatsätze verwenden und möglicherweise sogar Slaves in anderen Rechenzentren/Verfügbarkeitszonen/Racks/usw. platzieren, um die erforderliche Ausfallsicherheit zu gewährleisten.
Es gibt / wird (ich kann mich nicht erinnern, ob dies bereits implementiert wurde) eine Möglichkeit geben, die Priorität einzelner Knoten in einem Replikatsatz so anzugeben, dass bei einem Ausfall des Masters der neue gewählte Master einer in denselben Daten ist Center, wenn eine solche Maschine verfügbar ist (dh einen Sklaven auf der anderen Seite des Landes daran zu hindern, Herr zu werden, es sei denn, dies ist wirklich die einzige andere Option).
