A write concern descreve o nível de confirmação solicitado do MongoDB para operações de gravação em um bancomongod de dados autônomo, conjuntos de réplicas ou clusters fragmentados. Em clusters fragmentados, mongos as instâncias passam a preocupação de gravação para os shards.
Observação
Para transações com vários documentos, você define a write concern no nível da transação, não no nível da operação individual. Não defina explicitamente a write concern para operações individuais de escrita em uma transação.
Conjuntos de réplicas e clusters fragmentados suportam um preocupação de gravação padrão global. Operações sem um preocupação de gravação explícito herdam o padrão global. A preocupação de gravação global padrão é maioria. Consulte para mais setDefaultRWConcern informações.
Para saber mais sobre como configurar a preocupação de gravação para implantações hospedadas no MongoDB Atlas, consulte Construir um Aplicativo Resiliente com MongoDB Atlas
Especificação de write concern
A write concern pode incluir os seguintes campos:
{ w: <value>, j: <boolean>, wtimeout: <number> }
w: solicita confirmação de que a operação de gravação se propagou para um número específico de instâncias
mongodmongodou para instâncias com tags especificadas.j: Solicita confirmação de que a operação de gravação foi gravada no diário em disco .
wtimeout: especifica um limite de tempo para impedir que as operações de gravação sejam bloqueadas indefinidamente.
w Opção
A opção w solicita o reconhecimento de que a operação de gravação se propagou para um número específico de instâncias mongod ou para instâncias mongod com tags especificadas. Se a write concern estiver faltando no w campo , o MongoDB define a w opção para a write concern padrão.
Observação
Se você usar setDefaultRWConcern para definir a write concern padrão, deverá especificar um valor de campo w.
A opção w aceita as seguintes write concerns w: <value>:
Valor | Descrição |
|---|---|
Solicita o reconhecimento de que a maioria calculada dos membros votantes portadores de dados escreveu de forma duradoura a alteração em seu oplog local . Em seguida, os membros aplicam as alterações de forma assíncrona à medida que as leem de seus oplogs locais. Os membros votantes com dados de um conjunto de réplicas são o membro primário e quaisquer membros secundários com Para obter mais informações, consulte Leituras após { w: "maioria" } gravações.
Por exemplo, considere um conjunto de réplicas com 3 membros votantes, Primary-Secondary-Secondary (PSS). Para esse conjunto de réplicas, a maioria calculada 2é, e a write concern deve se propagar para os oplogs do primário e de um secundário para reconhecer a preocupação de gravação para o cliente. Membrosocultos , atrasados Os secundários atrasados podem retornar a confirmação de gravação não antes do Se você especificar uma preocupação de gravação Consulte Comportamento de reconhecimento para saber quando | |
Solicita confirmação de que a operação de gravação se propagou para o número especificado de instâncias
Por exemplo, considere um conjunto de réplicas de 3membro com um primário e 2 secundários. A especificação de Osmembros ocultos , atrasados e Os secundários atrasados podem retornar a confirmação de gravação não antes do Consulte Comportamento de reconhecimento para saber quando | |
Solicita confirmação de que as operações de escrita foram propagadas para Os dados podem ser revertidos se um preocupação de gravação customizado exigir apenas o reconhecimento da primária e a primária é reduzida antes que as operações de gravação sejam replicadas para qualquer uma das secundárias. Consulte Comportamento de reconhecimento para saber quando |
j Opção
A opção j solicita o reconhecimento do MongoDB de que a operação de gravação foi escrita no jornal em disco.
Com |
Observação
Especificar uma preocupação de gravação que inclua
j: trueemmongoduma instância em execução sem registro no diário produz um erro.Se o registro no diário estiver ativado,
w: "majority"pode implicar emj: true. A configuração do conjunto de réplicas dowriteConcernMajorityJournalDefaultdetermina o comportamento. Consulte Comportamento de confirmação para obter detalhes.Uma write concern que inclui ou implica em
j: truecausa uma sincronização imediata do diário. Consulte Processo de diário.
wtimeout
Esta opção especifica um limite de tempo, em milissegundos, para que uma operação de gravação se propague para membros suficientes para obter a preocupação de gravação depois que a operação for bem-sucedida no primary. wtimeout não se aplica se w for menor ou igual a 1. Se a operação de gravação não atingir a preocupação de gravação dentro desse limite de tempo, o MongoDB retornará um erro de preocupação de gravação .
wtimeout faz com que as operações de escrita retornem com um erro de preocupação de gravação após o limite especificado, mesmo que a preocupação de gravação necessária seja bem-sucedida. Quando essas operações de gravação retornam, o MongoDB não desfaz as modificações de dados bem-sucedidas realizadas antes que a preocupação de gravação exceda o limite de tempo wtimeout.
Se você não especificar a opção wtimeout e o nível da write concern for inatingível, a operação de escrita será bloqueada indefinidamente. Especificar um valor wtimeout de 0 é equivalente a uma write concern sem a opção wtimeout.
Observação
Para definir um limite de tempo para a operação de escrita primária, use o método maxTimeMS().
Write concern padrão implícito
O preocupação de gravação padrão implícito é w: majority. w: majority garante a durabilidade de gravação ao exigir que os conjuntos de réplicas aguardem o registro no diário no disco por padrão, controlado por writeConcernMajorityJournalDefault. No entanto, há um caso extremo para implantações de conjunto de réplicas contendo árbitros:
A maioria dos votos de um conjunto de réplicas é de 1 mais metade do número de membros votantes, arredondado para baixo. Se o número de membros votantes portadores de dados não for maior que a maioria votante, o write concern padrão é
{ w: 1 }.Em todos os outros cenários, a preocupação de gravação padrão é
{ w: "majority" }.
Especificamente, MongoDB usa a seguinte fórmula para determinar a preocupação de escrita padrão:
if [ (#arbiters > 0) AND (#non-arbiters <= majority(#voting-nodes)) ] defaultWriteConcern = { w: 1 } else defaultWriteConcern = { w: "majority" }
Por exemplo, considere as seguintes implantações e suas respectivas preocupações de escrita padrão:
Non-Arbiters | Árbitros | Nós de votação | Maioria dos nós de votação | Write concern padrão implícito |
|---|---|---|---|---|
2 | 1 | 3 | 2 |
|
4 | 1 | 5 | 3 |
|
No primeiro exemplo:
Existem 2 não-arbitores e 1 árbitro para um total de 3 nós de votação.
A maioria dos nós de votação (1 mais metade de 3, arredondado para baixo) é 2.
O número de não-arbitros (2) é igual à maioria dos nós de votação (2), resultando em uma preocupação implícita de escrita de
{ w: 1 }.
No segundo exemplo:
Existem 4 não-árbitros e 1 árbitro para um total de 5 nós votantes.
A maioria dos nós de votação (1 mais metade de 5, arredondado para baixo) é 3.
O número de não-arbitros (4) é maior que a maioria dos nós de votação (3), resultando em uma preocupação implícita de escrita de
{ w: "majority" }.
Em um cluster fragmentado, operações DDL (Data Definition Language) são executadas com preocupação de gravação "majority". Se você especificar uma preocupação de gravação diferente, a operação substituirá a preocupação de gravação fornecida por "majority".
Comportamento de confirmação
A opção w e a opção j determinam quando as instâncias do mongod reconhecem operações de gravação.
Autônomo
Um autônomo reconhece uma operação de gravação após aplicar a gravação na memória ou depois de gravar no diário em disco. A tabela a seguir lista o comportamento de confirmação para um autônomo com as write concerns mongod relevantes:
j não é especificado | j:true | j:false | |
|---|---|---|---|
| inMemory | On-disk journal | inMemory |
| Diário no disco se estiver executando com registro no diário | On-disk journal | inMemory |
Observação
Com writeConcernMajorityJournalDefault definido como false, o MongoDB não espera que w: "majority" as gravações sejam gravadas no diário em disco antes de confirmar as gravações. Dessa forma, as operações de gravação "majority" poderiam ser revertidas no caso de uma perda transitória (por exemplo, falha e reinicialização) da maioria dos nós em determinado conjunto de réplicas.
Conjuntos de réplicas
O valor w determina o número de membros do conjunto de réplicas que devem confirmar a gravação antes de retornar o sucesso. Para cada membro qualificado, a opção j determina se o membro reconhece as gravações depois de aplicar a gravação na memória ou depois de gravar no diário em disco .
w: "majority"Qualquer membro votante com dados do conjunto de réplicas pode contribuir para a confirmação de gravação de operações de gravação de
"majority".A tabela a seguir lista quando o membro pode reconhecer a gravação com base no valor j:
jnão é especificadoA confirmação depende do valor de
writeConcernMajorityJournalDefault:Se
true, o reconhecimento exigirá que o MongoDB torne as gravações duráveis sincronizando-as com o diário em disco, equivalente aj: true.writeConcernMajorityJournalDefaulto padrão étrueSe
false, a confirmação requer operação de escrita na memória, equivalente aj: false.
j: trueO reconhecimento exige que o MongoDB torne as gravações duráveis por meio da sincronização com o registro no diário em disco.
j: falseA confirmação requer operação de escrita na memória.
Normalmente, se
j: falseestiver definido, não é necessário gravar a operação no diário em disco. No entanto, sewriteConcernMajorityJournalDefault: trueestiver definido, é necessário escrever a operação no diário , mesmo quej: falseesteja definido.Se
j: falseewriteConcernMajorityJournalDefault: trueestiverem definidos, as operações de gravação serão gravadas no diário de forma assíncrona.As gravações que têm
w: majorityconjunto não são reconhecidas como concluídas até que o diário seja liberado para o disco.w: majorityas gravações aguardam a conclusão do snapshot de leitura"majority", independentemente da configuraçãoj. Isso ocorre porque, sewriteConcernMajorityJournalDefault: trueestiver definido, o snapshot de leitura majoritário será baseado na maioria das gravações registradas no diário.Depois que a operação de gravação retornar com uma confirmação
w: majoritypara o aplicação cliente , o aplicação poderá ler o resultado da gravação se a preocupação de leituramajorityestiver definida.
Para obter detalhes sobre o comportamento, consulte
w: "majority"Comportamento.w: <number>Qualquer membro de suporte de dados do conjunto de réplicas pode contribuir para o reconhecimento de gravação de w: <number> operações de gravação.
A tabela a seguir lista quando o membro pode reconhecer a gravação com base no valor j:
jnão é especificadoA confirmação requer operação de escrita na memória, equivalente a
j: false.j: trueO reconhecimento exige que o MongoDB torne as gravações duráveis por meio da sincronização com o registro no diário em disco.
j: falseA confirmação requer operação de escrita na memória.
Observação
Membros ocultos, atrasados e prioridade 0 podem confirmar operações de gravação w: <number>.
Os secundários atrasados podem retornar a confirmação de gravação não antes do secondaryDelaySecsconfigurado.
Lê depois de { w: "maioria" } Escreve
A partir do MongoDB 8.0, { w: "majority" } escreve retorna uma confirmação depois que a maioria dos membros portadores de dados escreve de forma duradoura a entrada do oplog. Em seguida, os membros aplicam de forma assíncrona as alterações à medida que as leem de seus oplogs locais. Em versões anteriores, o MongoDB esperou até que os membros aplicassem a gravação antes de retornar a confirmação.
As queries nos secundários imediatamente após uma confirmação de gravação { w: "majority" } podem ser lidas da coleção antes que o secundário aplique alterações da gravação.
Se seu aplicação ler de secundários e exigir acesso imediato a alterações de { w: "majority" } gravações, execute essas operações em uma sessão causalmente consistente.
Informações adicionais
Recomendações de Preocupação de Leitura e Gravação
Para ler suas próprias gravações no primário, use a "majority" preocupação de leitura e a { w: "majority" } preocupação de gravação.
Se você usar uma preocupação de { w: n } gravação em n que é maior do que a maioria calculada dos nós do cluster e o cluster usar as configurações padrão, habilite a opção preocupação de gravação "j" para confirmar a gravação no diário. A preocupação de "majority" leitura só permite que você leia atualizações que sejam duráveis na maioria dos nós no conjunto de réplicas.
Observação
Se você executar gravações com uma preocupação de gravação { w: n } e n for maior que a maioria calculada, sem registro no diário e com as configurações de cluster padrão, poderá receber uma confirmação de gravação antes que a gravação seja durável na maioria dos nós.
Sessões causalmente consistentes e write concerns
Sessões de cliente causalmente consistentes garantem a consistência causal somente se:
as operações de leitura associadas usam
"majority"read concern eas operações de gravação associadas usam a preocupação de gravação
"majority".
Para obter detalhes, consulte Consistência causal.
w: "majority" Comportamento
Com
writeConcernMajorityJournalDefaultdefinido comofalse, o MongoDB não espera quew: "majority"as gravações sejam gravadas no diário em disco antes de confirmar as gravações. Dessa forma, as operações de gravação"majority"poderiam ser revertidas no caso de uma perda transitória (por exemplo, falha e reinicialização) da maioria dos nós em determinado conjunto de réplicas.Membros ocultos, atrasados e prioridade 0 com
members[n].votesmaior que0podem reconhecer"majority"operações de gravação.Os secundários atrasados podem retornar a confirmação de gravação não antes do
secondaryDelaySecsconfigurado.
Iniciando no MongoDB 5.0, os membros do conjunto de réplicas no estado
STARTUP2não participam em majorias de escrita.
Preocupação de gravação não suportada no banco de dados local
O banco de dados local não oferece suporte a questões de gravação. O MongoDB ignora silenciosamente qualquer preocupação de gravação configurada para operações em coleções no banco de dados local.
Calculando a maioria para write concern
Dica
O rs.status() retorna o campo writeMajorityCount, o qual contém o cálculo da maioria.
A maioria para preocupação de gravação "majority" é calculada como o menor dos seguintes valores:
a maioria dos todos os membros votantes, incluindo árbitros
o número de todos os membros votantes portadores de dados
Aviso
Se a maioria calculada for igual ao número de todos os membros votantes portadores de dados, como em um 3sistema de membros Primário-Secundário-Árbitro, preocupação de gravação poderá ter um tempo limite ou nunca ser reconhecida se um membro votante portador "majority" de dados está inativo ou inacessível. Se possível, use um membro votante portador de dados, em vez de um árbitro.
Por exemplo, considere:
Uma réplica com 3 membros votantes, Primary-Secundário-Secundário (P-S-S):
A maioria de todos os membros votantes é 2.
O número de todos os membros da votação com recurso de dados é 3.
The calculated majority is 2, the minimum of 2 and 3. The write must propagate to the primary and one of the secondaries to acknowledge the write concern"majority"to the client.Um conjunto de réplicas com 3 membros votantes, Primary-Secondary-Arbiter (PSA):
A maioria de todos os membros votantes é 2.
O número de todos os membros da votação com recurso de dados é 2.
The calculated majority is 2, the minimum of 2 and 2. Since the write can only be applied to data-bearing members, the write must propagate to the primary and the secondary to acknowledge write concern"majority"to the client.Dica
Evite usar
"majority"a preocupação de gravação com PSA ou outras topologias que exijam que todos os membros votantes portadores de dados estejam disponíveis para reconhecer as gravações. Para obter as garantias de durabilidade de um"majority"preocupação de gravação, implemente uma topologia que não exija que todos os membros votantes portadores de dados estejam disponíveis, como o PSS.
Aviso
Evite implementar mais de um arbiter em um conjunto de réplicas. Consulte Preocupações com vários arbiters.
Para adicionar um árbitro a um conjunto de réplicas existente:
Normalmente, se houver dois ou menos membros portadores de dados no conjunto de réplicas, talvez seja necessário definir primeiro a preocupação de gravação em todo o cluster para o conjunto de réplicas.
Consulte preocupação de gravação em todo o cluster para obter mais informações sobre por que você pode precisar definir a preocupação de gravação em todo o cluster.
Você não precisa alterar a questão de escrita em todo o cluster antes de começar um novo conjunto de réplicas com um arbiter.
Escreva a preocupação com a proveniência
O MongoDB rastreia a preocupação de gravação provenance, que indica a origem de uma preocupação de gravação específica. Você pode ver provenance nas métricas getLastError, nos objetos de erro de preocupação de gravação e nos logs do MongoDB.
A tabela a seguir mostra os possíveis valores de write concern provenance e seu significado:
Proveniência | Descrição |
|---|---|
| A preocupação de gravação foi especificada no aplicativo. |
| A preocupação de gravação originou-se de um valor padrão personalizado definido. Consulte |
| A preocupação de gravação originada do campo |
| A preocupação de gravação originou-se do servidor na ausência de todas as outras especificações de preocupação de gravação. |
Write concern contrastada com Commit Quorum
Há diferenças importantes entre quóruns para a confirmação e preocupações de gravação:
Construções de índice usam quóruns para a confirmação.
As operações de gravação usam preocupações de gravação.
Cada nó portador de dados em um cluster é um membro votante.
O quorum para o commit especifica quantos membros votantes com dados, ou quais membros votantes, incluindo o primário, devem estar preparados para confirmar uma construção de índice simultânea. antes que o primário execute o commit.
A preocupação de gravação é o nível de reconhecimento de que a gravação se propagou para o número especificado de instâncias.
Alterado na versão 8.0: O quorum de confirmação especifica quantos nós devem estar prontos para concluir a criação do índice antes que o primário faça a confirmação da criação do índice. Em contraste, quando o primário tiver confirmado a criação do índice, a preocupação de gravação especifica quantos nós devem replicar a entrada do oplog de criação do índice antes que o comando retorne sucesso.
Em versões anteriores, quando o primário confirmava a criação do índice, a preocupação de gravação especificava quantos nós deveriam finalizar a criação do índice antes que o comando retornasse sucesso.