Sua melhor aposta é usar Write Concerns - eles permitem que você diga ao MongoDB o quão importante é um dado. A preocupação de gravação mais rápida também é a menos segura - os dados não são liberados para o disco até a próxima liberação agendada. O mais seguro confirmará que os dados foram gravados no disco em várias máquinas antes de retornar.

A preocupação de gravação que você está procurando é FSYNC_SAFE (pelo menos é assim que é chamado do ponto de vista do Driver Java ) ou REPLICAS_SAFE que confirma que seus dados foram replicados.

Tenha em mente que o MongoDB não tem transações no sentido tradicional - seu rollback terá que ser feito manualmente, pois você não pode dizer ao banco de dados Mongo para fazer isso por você.

A outra coisa que você precisa fazer é usar o relativamente novo --journal opção (que usa um log de gravação antecipada) ou use conjuntos de réplicas para compartilhar seus dados em várias máquinas para maximizar a integridade dos dados em caso de falha/perda de energia.

A fragmentação não é tanto uma proteção contra falhas de hardware como um método para compartilhar a carga ao lidar com conjuntos de dados particularmente grandes - a fragmentação não deve ser confundida com conjuntos de réplicas, que é uma maneira de gravar dados em mais de um disco em mais de uma máquina .

Portanto, se seus dados forem valiosos o suficiente, você definitivamente deve usar conjuntos de réplicas, talvez até mesmo alocar escravos em outros data centers/zonas de disponibilidade/racks/etc para fornecer a resiliência necessária.

Existe / haverá (não me lembro de imediato se isso foi implementado ainda) uma maneira de especificar a prioridade de nós individuais em um conjunto de réplicas, de modo que, se o mestre cair, o novo mestre eleito seja um dos mesmos dados center se tal máquina estiver disponível (ou seja, impedir que um escravo do outro lado do país se torne mestre, a menos que seja realmente a única outra opção).