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 autônomo , conjuntos de réplicas ou clusters fragmentados. Em clusters fragmentados, as instâncias mongos passarão 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.
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.
Os conjuntos de réplicas e cluster fragmentado oferecem suporte à definição de uma preocupação de gravação padrão. Operações que não especificam uma preocupação de gravação explícita herdam as configurações padrão de preocupação de gravação global. Consulte setDefaultRWConcern para mais 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> }
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 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. Alterado na versão 8.0: O MongoDB não espera que os membros apliquem a alteração antes de reconhecer a gravação, como aconteceu nas versões anteriores. 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 de votação, Primário-Secundário-Secundário (P-S-S). Para esse conjunto de réplicas, a maioria calculada é dois, e a gravação deve se propagar para os oplogs do primário e um secundário para reconhecer a preocupação de gravação para o cliente. Membros 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 Membros 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 Com |
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" }.
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 | { 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 | On-disk journal | inMemory |
w: "majority" | 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 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 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 (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.
Lê depois de { w: "maioria" } Escreve
A partir do MongoDB 8.0, as gravações { w: "majority" } retornam uma confirmação depois que a maioria dos membros com dados grava de forma contínua a entrada oplog. Os membros então aplicam as alterações de forma assíncrona à medida que as leem em seus oplogs locais. Em versões anteriores, o MongoDB esperava até que os membros aplicassem a gravação para retornar a confirmação.
As queries em secundários imediatamente após uma gravação { w: "majority" } retornam uma confirmação podem ser lidas da coleção antes que o secundário aplique as alterações da gravação.
Se seu aplicativo lê de fontes secundárias e exige acesso imediato às alterações feitas nas gravações { w: "majority" }, execute essas operações em uma sessão causalmente consistente.
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).
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 |
|---|---|
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. |
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.