A preocupação de gravação padrão no MongoDB tem sido w:1 desde o MongoDB 2.2 em 2012.

Existem três configurações diferentes que você pode usar para configurar o problema de gravação nas versões atuais do MongoDB (versão 3.2.6 e mais recente):

• w configuração :quantos nós devem reconhecer a gravação antes de declará-la um sucesso. O padrão é 1, o que significa que a confirmação do nó primário é suficiente.
• j configuração :as gravações devem ser registradas no diário antes de serem reconhecidas? O padrão depende de writeConcernMajorityJournalDefault .
• writeConcernMajorityJournalDefault :se você especificar w:majority configuração de preocupação de gravação para suas gravações sem configurar j , qual é o j implícito valor? O padrão é true (as gravações devem ser registradas na maioria dos nós de votação antes de serem reconhecidas).

Há também um wtimeout configuração para configurar quanto tempo o MongoDB deve esperar para que a preocupação de gravação seja satisfeita antes de informar ao cliente que a gravação não foi reconhecida. Caso contrário, as gravações que aguardam a satisfação da preocupação de gravação podem esperar para sempre em vez de falhar.

A configuração especial aqui é w:majority . Isso significa que as gravações devem se propagar para a maioria dos nós de votação (e também aos seus diários) em um conjunto de réplicas a ser reconhecido. Esta é sem dúvida a configuração mais segura, proporcionando bom desempenho, porque:

• Evita que as gravações reconhecidas sejam revertidas em caso de falhas.
• Ele regula a taxa de transferência do aplicativo para que ele não envie gravações mais rápido do que o conjunto de réplicas pode manipular (devido a restrições de hardware, situação de rede etc.).

Como você imaginou, nós de votação incluem o árbitro . Assim, em um conjunto de réplicas com configuração de árbitro primário-secundário, w:majority pode falhar em um cenário em que:

• Um dos nós portadores de dados está off-line por algum motivo.
• O conjunto de réplicas ainda está on-line com um primário gravável, pois a topologia agora é primário-árbitro-off-line.
• Grava com w:1 será bem-sucedido como de costume, mas essas gravações podem ser revertidas (já que não foram gravadas na maioria dos nós com dados de votação).
• Como o árbitro não carrega dados, w:majority as gravações falharão (ou aguardarão indefinidamente), pois o árbitro é contado como um nó de votação.

Por esse motivo, o uso de um árbitro não é recomendado se você planeja usar w:majority em seu aplicativo.

Observe que o uso de um árbitro em um conjunto de réplicas de 3 nós que forma um fragmento em um cluster fragmentado também não é recomendado, pois a movimentação de fragmentos requer w:majority . Ter uma falha de nó portador de dados em um fragmento será prejudicial para as operações de migração de fragmentos.