A preocupação de gravação descreve o nível de confirmação solicitado ao MongoDB para operações de escrita em um mongod autônomo, conjuntos de réplicas ou clusters. Em clusters fragmentados, as instâncias mongos passam a preocupação de gravação para os fragmentos.
Observação
Para transações multidocumento, 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 setDefaultRWConcern para mais informações.
Para saber mais sobre como configurar a write concern 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> }
j: Requests acknowledgment that the write operation has been written to the on-disk journal.
wtimeout: Specifies a time limit to prevent write operations from blocking indefinitely.
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 preocupações de gravação w: <value>:
Valor | Descrição |
|---|---|
Solicita o reconhecimento de que a maioria calculada dos membros votantes com 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 em 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 gravações { w: "majority" }.
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 e Os secundários atrasados podem retornar a confirmação de gravação não antes do If you specify a See Acknowledgment Behavior for when | |
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 3nó com um primário e 2 secundários. A especificação de Membros ocultos, atrasados e prioridade 0 podem reconhecer operações de Os secundários atrasados podem retornar a confirmação de gravação não antes do See Acknowledgment Behavior for when | |
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. See Acknowledgment Behavior for when |
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.
If With |
Observação
Especificar uma preocupação de gravação que inclua
j: trueem uma instânciamongodem execução sem registro no diário produz um erro.If journaling is enabled,
w: "majority"may implyj: true. ThewriteConcernMajorityJournalDefaultreplica set configuration setting determines the behavior. See Acknowledgment Behavior for details.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
The implicit default write concern is w: majority. w: majority ensures write durability by requiring replica sets to wait for on-disk journaling by default, controlled by writeConcernMajorityJournalDefault. However, there is an edge case for replica set deployments containing arbiters:
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" }.
On a sharded cluster, DDL (Data Definition Language) operations run with write concern "majority". If you specify a different write concern, the operation overrides the provided write concern with "majority".
Comportamento de confirmação
The w option and the j option determine when mongod instances acknowledge write operations.
Autônomo
Um mongod 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 preocupações de gravação 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
With writeConcernMajorityJournalDefault set to false, MongoDB does not wait for w: "majority" writes to be written to the on-disk journal before acknowledging the writes. As such, "majority" write operations could possibly roll back in the event of a transient loss (e.g. crash and restart) of a majority of nodes in a given replica set.
Conjuntos de réplicas
The w value determines the number of replica set members that must acknowledge the write before returning success. For each eligible member, the j option determines whether the member acknowledges writes after applying the write in memory or after writing to the on-disk journal.
w: "majority"Any data-bearing voting member of the replica set can contribute to write acknowledgment of
"majority"write operations.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.
For behavior details, see
w: "majority"Behavior.w: <number>Qualquer membro de suporte de dados do conjunto de réplicas pode contribuir para o reconhecimento de escrita 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
Hidden, delayed, and priority 0 members can acknowledge w: <number> write operations.
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" } gravações retornam uma confirmação depois que a maioria dos nós portadores de dados grava 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 nós aplicassem o gravar 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 aplicativo 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
To read your own writes on the primary, use the "majority" read concern and the { w: "majority" } write concern. During an election, a read routed to the former primary can return a snapshot that does not include a majority-acknowledged write accepted by the new primary.
If you use a { w: n } write concern where n is greater than the calculated majority of the cluster's nodes and the cluster uses the default settings, enable the write concern "j" option to acknowledge the write to the journal. The "majority" read concern only allows you to read updates that are durable on a majority of nodes in the replica set.
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 ethe associated write operations use
"majority"write concern.
Para obter detalhes, consulte Consistência causal.
w: "majority" Comportamento
With
writeConcernMajorityJournalDefaultset tofalse, MongoDB does not wait forw: "majority"writes to be written to the on-disk journal before acknowledging the writes. As such,"majority"write operations could possibly roll back in the event of a transient loss (e.g. crash and restart) of a majority of nodes in a given replica set.Hidden, delayed, and priority 0 members with
members[n].votesgreater than0can acknowledge"majority"write operations.- 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 banco de dados local
O banco de dados local não oferece suporte a preocupaçõ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.
The majority for write concern "majority" is calculated as the smaller of the following values:
a maioria de 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 Primário-Secundário-Árbitro de membros, 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.
A maioria calculada 2 é, o mínimo de 2 3e. A write deve se propagar para o primário e um dos secundários para reconhecer a preocupação de gravação para o
"majority"cliente.Um conjunto de réplicas com 3 nós votantes, Primário-Secundário-Árbitro (PSA):
A maioria de todos os membros votantes é 2.
O número de todos os membros da votação com recurso de dados é 2.
A maioria calculada 2 é, o mínimo de 2 2e. Como a gravação só pode ser aplicada a membros portadores de dados, a gravação deve se propagar para o primário e o secundário para reconhecer
"majority"a preocupação de gravação para o cliente.Dica
Avoid using
"majority"write concern with P-S-A or other topologies that require all data-bearing voting members to be available to acknowledge writes. For the durability guarantees of a"majority"write concern, deploy a topology that does not require all data-bearing voting members to be available, such as P-S-S.
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 write concern foi especificada no aplicativo. |
| A write concern originou-se de um valor padrão personalizado definido. Consulte |
| A write concern originada do campo |
| A write concern originou-se do servidor na ausência de todas as outras especificações de write concern. |
Write concern contrastada com Commit Quorum
Há diferenças importantes entre quóruns para a confirmação e write concerns:
Construções de índice usam quóruns para a confirmação.
As operações de gravação usam write concerns.
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 write concern é o nível de reconhecimento de que a gravação se propagou para o número especificado de instâncias.
Changed in version 8.0:
O quorum de confirmação especifica quantos nós devem estar prontos para concluir a construção de índice antes que o primário faça a confirmação da construção de índice. Em contraste, quando o primário tiver confirmado a construção de índice, a write concern especifica quantos nós devem replicar a entrada do oplog de construção de í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.