'Write concern' no MongoDB descreve o nível de reconhecimento de gravação que você pode esperar dele. É uma configuração bastante importante para lembrar em suas operações de gravação e seu comportamento é útil para entender, especialmente em implantações distribuídas do MongoDB (ou seja, conjuntos de réplicas e clusters fragmentados). Neste post, discutimos 3 armadilhas ao usar a preocupação de gravação do MongoDB.
Preocupação com a gravação do MongoDB
A documentação do MongoDB define preocupação de gravação como “o nível de confirmação solicitado do MongoDB para operações de gravação em um mongod autônomo ou em conjuntos de réplicas ou em clusters fragmentados. “
Resumindo, uma preocupação de gravação é uma indicação de 'durabilidade' passada junto com as operações de gravação para o MongoDB. Para esclarecer, vejamos a sintaxe:
{ w: <value>, j: <boolean>, wtimeout: <number> }
Where*,
w can be an integer | "majority" | , it represents the number of members that must acknowledge the write. Default value is 1.
j Requests that a write be acknowledged after it is written to the on-disk journal as opposed to just the system memory. Unspecified by default.
wtimeout specifies timeout for the applying the write concern. Unspecified by default. * Você pode encontrar a sintaxe detalhada na documentação Write Concern Specification.
* Saiba mais sobre as diferentes “tags” que você pode usar para valores comuns de preocupação de gravação em nosso blog Compreendendo Durabilidade e Segurança de Gravação no MongoDB.
Exemplo:
db.inventory.insert(
{ sku: "abcdxyz", qty : 100, category: "Clothing" },
{ writeConcern: { w: 2, j: true, wtimeout: 5000 } }
) O problema de gravação da inserção acima pode ser lido da seguinte forma: confirme esta gravação quando 'pelo menos 2 membros do conjunto de réplicas a gravarem em seus diários em 5.000 ms ou retornarem um erro '. Um valor de preocupação de gravação para a opção era majoritário, significando "rsolicita confirmação de que as operações de gravação se propagaram para a maioria dos nós de votação, incluindo o principal. “
#MongoDB Write Concern - 3 Advertências ImperdíveisClique para Tweet
A importância da preocupação com a escrita é aparente. Aumentar os valores de w aumenta a latência das gravações e, ao mesmo tempo, diminui a probabilidade de se perder. A escolha dos valores corretos para a preocupação de gravação depende dos requisitos de latência e durabilidade das gravações que estão sendo executadas.
Com isso como pano de fundo sobre o que é uma preocupação de gravação, vamos passar para as três advertências a serem lembradas ao usar a preocupação de gravação.
AVISO 1: definir o problema de gravação em conjuntos de réplicas sem um wtimeout pode fazer com que as gravações sejam bloqueadas indefinidamente
A definição majoritária (aplicável ao MongoDB 3.0 em diante) acima afirma que o reconhecimento é solicitado da maioria dos “nós de votação”. Observe que “Se você não especificar o wtimeout opção e o nível de preocupação de gravação for inatingível, a operação de gravação será bloqueada indefinidamente. “
Isso pode ter consequências inesperadas, por exemplo, considere um conjunto de réplicas 2+1 (ou seja, um primário, um secundário e um árbitro). Se sua única réplica de leitura ficar inativa, todas as gravações com uma preocupação de gravação w opção de “maioria” serão bloqueadas indefinidamente. O mesmo acontecerá se a opção w estiver configurada para 2. Outro exemplo extremo é no caso de um conjunto de 3+2 réplicas (primário, 2 secundários e 2 árbitros, configuração não recomendada). Todas as gravações "majoritárias" serão bloqueadas mesmo se um único nó de dados estiver indisponível, pois o número majoritário, neste caso, é 3.
A maneira mais simples de aliviar esse problema é sempre especificar um valor wtimeout para que a consulta possa atingir o tempo limite se a preocupação de gravação não puder ser aplicada. No entanto, no caso de tais erros de tempo limite, o MongoDB não desfaz gravações já bem-sucedidas feitas em alguns dos membros antes do tempo limite ocorrer.
Atualmente, também não há configuração para garantir que uma gravação atinja a maioria dos nós que estão atualmente acessíveis, portanto, tenha cuidado ao definir o valor de write concern w com base na topologia desejada durabilidade e disponibilidade.
AVISO 2: você pode perder dados mesmo com w:majority
Parece intuitivo que uma vez que uma escrita tenha sido reconhecida pela maioria dos membros votantes, sua durabilidade seja garantida. No entanto, esse não é o caso! Lembre-se que quando a opção j não é especificada, uma gravação é reconhecida logo após ter sido gravada na memória.
Assim, essa gravação pode ser perdida se uma queda de energia anormal eliminar a maioria dos nós para os quais a gravação foi propagada (e antes de syncPeriodSecs, ou seja, antes que pudesse ser liberado para disco).
Para garantir a durabilidade das gravações, é melhor não desativar o journaling em seu banco de dados e definir a opção j como true. Na verdade, a partir do MongoDB 3.6, o --nojournal sinalizador foi preterido para membros do conjunto de réplicas usando o mecanismo de armazenamento WiredTiger.
Com um valor w de “majority” e a opção j não especificada em um conjunto de réplicas, o comportamento exato da durabilidade depende do valor da configuração do conjunto de réplicas writeConcernMajorityJournalDefault. Quando definido como verdadeiro (e quando o registro no diário está ativado), ele reconhece as gravações depois que elas foram gravadas nos diários da maioria dos membros votantes.
Aparte:mesmo com o registro no diário ativado, suas gravações ainda podem se perder no mecanismo de armazenamento MMAPv1 se ocorrer uma interrupção na duração de commitIntervalMs. O mecanismo de armazenamento WiredTiger, por outro lado, força uma sincronização de arquivos de diário quando recebe uma gravação com a opção j definida como verdadeira. E, mesmo com j definido como false, uma gravação de “maioria” reconhecida em uma implantação mais recente baseada no WiredTiger pode ser perdida apenas quando a maioria dos nós de dados falha simultaneamente.
CAVEAT 3: w:0 ao definir j:true não melhora o desempenho de gravação
Isso é fácil de raciocinar quando você pensa sobre isso, mas igualmente fácil de esquecer. Definir a opção w como 0 geralmente é feito para gravar no banco de dados de uma maneira “dispare e esqueça” – quando você tem uma quantidade razoável de confiança na infraestrutura do banco de dados e se preocupa mais com a latência do que com a durabilidade de cada gravação. No entanto, se você definir a opção j como true, sua opção w será efetivamente substituída, pois o banco de dados garantirá que a gravação seja gravada no diário em disco antes de retornar.
Se você estiver usando preocupações de gravação para garantir o sucesso de suas operações de gravação, lembre-se dessas três advertências cruciais. Estamos aqui para ajudar, então sinta-se à vontade para entrar em contato com qualquer dúvida por meio do Twitter ou por e-mail.
