Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
Escreva preocupação
Nesta página
A preocupação de gravação descreve o nível de confirmação solicitado do MongoDB para operações de gravação em um mongod autônoma, conjunto de réplicas ou cluster fragmentado. Em clusters fragmentados, as instâncias mongos passarão a preocupação de gravação para os fragmentos.
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 write concern "majority" para uma transação multidocumento e a transação não conseguir replicar 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á eventualmente 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 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> }
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 membros votantes portadores de dados (ou seja, primário e secundário com 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 é dois, e a write concern deve se propagar para o primário e um secundário para reconhecer a write concern para o cliente. ObservaçãoMembrosocultos, atrasados e priority 0 com Os secundários atrasados podem retornar a confirmação de gravação não antes do Depois que a operação de escrita retornar com uma confirmação Se você especificar uma write concern Consulte Comportamento de reconhecimento 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çãoMembrosocultos, atrasados e priority 0 podem reconhecer Os secundários atrasados podem retornar a confirmação de gravação não antes do Consulte Comportamento de reconhecimento 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 reconhecimento 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 Alterado na versão 3.2: com o |
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 em diário estiver ativado,
w: "majority"pode implicarj: 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 write concern padrão implícita é w: majority. No entanto, considerações especiais são feitas para sistemas 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:
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 as escritas w: "majority" sejam escritas no diário no disco antes de reconhecer as escritas. Dessa forma, as operações de escrita "majority" podem 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 portador de dados do conjunto de réplicas pode contribuir para o reconhecimento por escrito das operações de write
"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.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 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 (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
Membrosocultos, atrasados e priority 0 podem reconhecer w: <number> operações de escrita.
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
"majority"write concern.
Para obter detalhes, consulte Consistência causal.
w: "majority" Comportamento
Com
writeConcernMajorityJournalDefaultdefinido comofalse, o MongoDB não espera que as escritasw: "majority"sejam escritas no diário no disco antes de reconhecer as escritas. Dessa forma, as operações de escrita"majority"podem 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.Membrosocultos, atrasados e priority 0 com
members[n].votesmaior que0confirmam operações de escrita"majority".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 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 que contém o número da maioria calculado.
A maioria das write concerns "majority" é calculada como 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 for igual ao número de todos os membros votantes portadores de dados (como em uma implantação de 3membros Primário-Secundário-Árbitro), write concern "majority" pode ter um tempo limite ou nunca ser reconhecida se um membro votante portador 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 e 3. A write deve se propagar para o primário e um dos secundários para reconhecer a write concern"majority"para o cliente.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.
A maioria calculada é 2, o mínimo de 2 e 2. 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 a write concern"majority"para o cliente.Dica
Evite usar uma write concern
"majority"com um (PSA) ou outras topologias que exijam que todos os membros votantes portadores de dados estejam disponíveis para confirmar as escritas. Os clientes que desejam as garantias de durabilidade de usar uma write concern"majority"devem, em vez disso, implantar uma topologia que não exija que todos os membros votantes portadores de dados estejam disponíveis (por exemplo, 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.
Dica
Veja também:
Escreva a preocupação com a proveniência
O MongoDB rastreia referência de escrita provenance, o que indica a origem de uma referência de escrita específica. Você pode ver provenance mostrado nas métricas getLastError , objeto de erro de referência de escrita e 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 escrita foi especificada no aplicativo. |
customDefault | A write concern originou-se de um valor padrão personalizado definido. Consulte setDefaultRWConcern. |
getLastErrorDefaults | A write concern 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. |
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 quorum para o commit.
As operações de escritura 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 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.
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. Por outro lado, quando o primário tiver confirmado a criação do índice, a preocupação de gravação especifica quantos nós devem finalizar a criação do índice antes que o comando retorne.