La soluzione migliore è utilizzare Write Concerns:questi ti consentono di dire a MongoDB quanto sia importante un dato. Il problema di scrittura più rapido è anche il meno sicuro:i dati non vengono scaricati su disco fino al successivo svuotamento pianificato. Il più sicuro confermerà che i dati sono stati scritti su disco su un certo numero di macchine prima di restituire.
Il problema di scrittura che stai cercando è FSYNC_SAFE (almeno è così che viene chiamato dal punto di vista di Driver Java ) o REPLICAS_SAFE che conferma che i tuoi dati sono stati replicati.
Tieni presente che MongoDB non ha transazioni nel senso tradizionale:il tuo rollback dovrà essere eseguito manualmente poiché non puoi dire al database Mongo di farlo per te.
L'altra cosa che devi fare è usare il relativamente nuovo --journal opzione (che utilizza un registro Write Ahead) oppure utilizza i set di repliche per condividere i dati su più macchine al fine di massimizzare l'integrità dei dati in caso di arresto anomalo/interruzione di corrente.
Lo sharding non è tanto una protezione contro i guasti hardware quanto un metodo per condividere il carico quando si ha a che fare con set di dati particolarmente grandi:lo sharding non deve essere confuso con i set di repliche che è un modo per scrivere dati su più di un disco su più di una macchina .
Pertanto, se i tuoi dati sono sufficientemente preziosi, dovresti assolutamente utilizzare set di repliche, magari anche collocare slave in altri data center/zone di disponibilità/rack/ecc. al fine di fornire la resilienza di cui hai bisogno.
C'è/sarà (non ricordo a mano se questo è stato ancora implementato) un modo per specificare la priorità dei singoli nodi in un set di repliche in modo tale che se il master va giù il nuovo master che viene eletto sia uno negli stessi dati centro se tale macchina è disponibile (cioè per impedire a uno schiavo dall'altra parte del paese di diventare padrone a meno che non sia davvero l'unica altra opzione).
