Най-добрият ви залог е да използвате Write Concerns - те ви позволяват да кажете на MongoDB колко важна е част от данните. Най-бързият Write Concern е и най-малко безопасен - данните не се изхвърлят на диска до следващото планирано промиване. Най-сигурният ще потвърди, че данните са били записани на диск на няколко машини, преди да се върне.
Проблемът за запис, който търсите, е FSYNC_SAFE (поне така се нарича от гледна точка на драйвер за Java ) или REPLICAS_SAFE, което потвърждава, че вашите данни са били копирани.
Имайте предвид, че MongoDB няма транзакции в традиционния смисъл - вашето връщане назад ще трябва да бъде върнато на ръка, тъй като не можете да кажете на базата данни Mongo да направи това вместо вас.
Другото нещо, което трябва да направите, е или да използвате сравнително новия --journal опция (която използва Write Ahead Log) или използвайте комплекти реплики, за да споделяте данните си между много машини, за да увеличите максимално целостта на данните в случай на срив/загуба на захранване.
Шардингът не е толкова защита срещу хардуерен срив, колкото метод за споделяне на натоварването, когато се работи с особено големи набори от данни - шардингът не трябва да се бърка с наборите реплики, което е начин за запис на данни на повече от един диск на повече от една машина .
Следователно, ако вашите данни са достатъчно ценни, определено трябва да използвате комплекти реплики, може би дори да разполагате подчинени устройства в други центрове за данни/зони за наличност/стелажи/и т.н., за да осигурите устойчивостта, от която се нуждаете.
Има/ще има (не мога да си спомня веднага дали това все още е внедрено) начин за указване на приоритета на отделните възли в набор от реплики, така че ако главният се изтрие, избраният нов главен е един в същите данни център, ако такава машина е налична (т.е. да попречи на роб от другия край на страната да стане господар, освен ако това наистина не е единствената друга опция).
