Escreva preocupação
Nesta página
A write concern descreve o nível de confirmação solicitado ao MongoDB para operações de escrita em mongod standalone, conjuntos de réplicas ou clusters fragmentados. Em clusters fragmentados, as instâncias mongos passarão a write concern 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.
Se você especificar uma preocupação de gravação "majority" para uma transação de vários documentos e a transação não for replicada para a maioria calculada dos membros do conjunto de réplicas, a transação poderá não reverter imediatamente os membros do conjunto de réplicas. O conjunto de réplicas será finalmente consistente. Uma transação é sempre aplicada ou revertida em todos os membros do conjunto de réplicas.
Conjuntos de réplicas e clusters fragmentados suportam a definição de uma referência de escrita padrão global. As operações que não especificam uma referência de escrita explícita herdam as configurações globais padrão de referência de escrita. Consulte setDefaultRWConcern para obter mais informações.
Para saber mais sobre como configurar a write concern para sistemas hospedados 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> }
a opção w para solicitar o reconhecimento de que a operação de gravação propagou para um número especificado de instâncias do
mongodou para instâncias domongodcom tags especificadas.a opção j para solicitar a confirmação de que a operação de gravação foi gravada no diário em disco, e
A opção wtimeout para especificar 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.
Utilizando a opção w, as seguintes write concerns do w: <value> estão disponíveis:
Valor | Descrição |
|---|---|
Solicita o reconhecimento de que as operações de gravação foram comprometidas de forma duradoura com a maioria calculada dos nós votantes portadores de dados (ou seja, primário e secundário com Por exemplo, considere um conjunto de réplicas com 3 membros de votação, Primário-Secundário-Secundário (P-S-S). Para esse conjunto de réplicas, a maioria calculada é dois, e a preocupação de gravação deve se propagar para o primário e um secundário para reconhecer a preocupação de gravação para o cliente. ObservaçãoMembros ocultos, atrasados e prioridade 0 com Os secundários atrasados podem retornar a confirmação de gravação não antes do Depois que a operação de gravação retornar com uma confirmação Se você especificar uma preocupação de gravação Consulte Comportamento de confirmação para saber quando as instâncias | |
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 3 membros com um primário e 2
secundários. Especificar ObservaçãoMembros ocultos, atrasados e prioridade 0 podem confirmar operações de gravação Os secundários atrasados podem retornar a confirmação de gravação não antes do Consulte Comportamento de confirmação para saber quando as instâncias | |
Solicita confirmação de que as operações de escrita foram propagadas para Os dados podem ser revertidos se um write concern 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 confirmação para saber quando as instâncias |
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.
Se ObservaçãoCom |
Observação
Especificar uma write concern que inclua
j: trueem uma instânciamongodque esteja sendo executada sem registro em 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 milésimos de segundo, para a write
concern. wtimeout só é aplicável para valores w superiores a 1.
wtimeout faz com que as operações de escrita retornem com um erro após o limite especificado, mesmo que a write concern necessária seja bem-sucedida. Quando essas operações de escrita retornam, o MongoDB não desfaz as modificações de dados bem-sucedidas realizadas antes que a write concern exceda o limite de tempo de 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.
Write concern padrão implícito
A partir do MongoDB 5.0, a preocupação de gravação padrão implícita é w: majority. No entanto, considerações especiais são feitas para implantações 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" }.Para um cluster fragmentado, a referência de escrita padrão é sempre recuperada do servidor de configuração. Como o servidor de configuração deve ter zero árbitro, a referência de escrita padrão implícita para um cluster fragmentado é sempre
"majority". Mesmo que um fragmento esteja em uma topologia Primário-Secundário-Árbitro, ele ainda terá uma referência de escrita padrão de"majority". A partir do MongoDB 5.1, essa configuração não é permitida se a referência de escrita em todo o cluster não estiver definida.
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:
Não Árbitros | Árbitros | Nós de votação | Maioria dos nós de votação | Write concern padrão implícito |
|---|---|---|---|---|
2 | 1 | 3 | 2 | { w: 1 } |
4 | 1 | 5 | 3 | { w: "majority" } |
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" }.
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 mongod standalone 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 dispositivo standalone e as write concerns relevantes:
j não é especificado | j:true | j:false | |
|---|---|---|---|
w: 1 | inMemory | Diário em disco | inMemory |
w: "majority" | Diário no disco se estiver executando com registro no diário | Diário em disco | 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 especificado para w set o número de membros do conjunto de réplicas que devem confirmar a gravação antes de retornar o sucesso. Para cada membro elegível do conjunto de réplicas, a opção j determina se o membro reconhece as gravações depois de aplicar a operação de gravação na memória ou depois de gravar no diário no 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, a confirmação requer uma operação de escrita no diário no disco (j: true).writeConcernMajorityJournalDefaulto padrão étrueSe
false, a confirmação requer operação de escrita na memória (j: false).
j: trueO reconhecimento exige a operação de gravação 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 aplicativo cliente, o aplicativo poderá ler o resultado da gravação se a read concernmajorityestiver definida.
Observação
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 (j: false).j: trueO reconhecimento exige a operação de gravação 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.
Informações adicionais
Sessões causalmente consistentes e write concerns
Com sessões de cliente causalmente consistentes, as sessões de cliente só garantem consistência causal 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.
Write Concern não suportada no local banco de dados
O banco de dados local não oferece suporte a questões de gravação. O MongoDB ignora silenciosamente qualquer write concern configurada para uma operação em uma coleção 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) vs.
o número de todos os membros votantes portadores de dados.
Aviso
Nos casos em que o número da maioria calculada é igual ao número de todos os membros votantes portadores de dados (como na implantação de 3membros Primário-Secundário-Árbitro), a preocupação de gravação "majority" pode expirar ou nunca ser reconhecida se um membro votante portador de dados estiver 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.Uma réplica com 3 membros votantes, Primário-Secundário-Árbitro (P-S-A)
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 the write concern"majority"to the client.Dica
Evite usar uma preocupação de gravação
"majority"com um (P-S-A) ou outras topologias que exijam que todos os nós votantes portadores de dados estejam disponíveis para reconhecer as gravações. Os clientes que desejam as garantias de durabilidade de usar uma preocupação de gravação"majority"devem, em vez disso, implantar uma topologia que não exija que todos os nós votantes portadores de dados estejam disponíveis (por exemplo. P-S-S).
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 |
|---|---|
clientSupplied | A preocupação de gravação foi especificada no aplicativo. |
customDefault | A preocupação de gravação originou-se de um valor padrão personalizado definido. Consulte setDefaultRWConcern. |
getLastErrorDefaults | A preocupação de gravação originada do campo settings.getLastErrorDefaults do conjunto de réplicas. |
implicitDefault | 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. |