Su mejor opción es usar Preocupaciones de escritura:estas le permiten decirle a MongoDB qué tan importante es un dato. El problema de escritura más rápido es también el menos seguro:los datos no se descargan en el disco hasta el próximo lavado programado. El más seguro confirmará que los datos se han escrito en el disco en varias máquinas antes de regresar.
La preocupación de escritura que está buscando es FSYNC_SAFE (al menos así se llama desde el punto de vista de Controlador Java ) o REPLICAS_SAFE que confirma que sus datos han sido replicados.
Tenga en cuenta que MongoDB no tiene transacciones en el sentido tradicional:su reversión deberá revertirse a mano, ya que no puede decirle a la base de datos de Mongo que lo haga por usted.
La otra cosa que debe hacer es usar el relativamente nuevo --journal (que usa un registro de escritura anticipada), o use conjuntos de réplicas para compartir sus datos entre muchas máquinas con el fin de maximizar la integridad de los datos en caso de falla o pérdida de energía.
La fragmentación no es tanto una protección contra fallas de hardware como un método para compartir la carga cuando se trata de conjuntos de datos particularmente grandes; la fragmentación no debe confundirse con conjuntos de réplicas, que es una forma de escribir datos en más de un disco en más de una máquina. .
Por lo tanto, si sus datos son lo suficientemente valiosos, definitivamente debería usar conjuntos de réplicas, tal vez incluso ubicar esclavos en otros centros de datos/zonas de disponibilidad/racks/etc para proporcionar la resistencia que necesita.
Hay/habrá (no puedo recordar de antemano si esto ya se ha implementado) una forma de especificar la prioridad de los nodos individuales en un conjunto de réplicas de modo que si el maestro deja de funcionar, el nuevo maestro que se elige es uno en los mismos datos centro si tal máquina está disponible (es decir, para evitar que un esclavo en el otro lado del país se convierta en amo a menos que realmente sea la única otra opción).
