MongoDB, como qualquer outro banco de dados, pode falhar ao executar uma operação de gravação. Nesse caso, precisamos de uma estratégia que mantenha a operação em algum lugar para que o banco de dados possa retomar quando for restaurado de volta à operação.
No MongoDB, usamos journaling, onde há um registro de gravação antecipada em arquivos de journal em disco para manter os dados disponíveis em caso de falha. O mecanismo de armazenamento WiredTiger pode usar pontos de verificação para fornecer uma visão consistente dos dados no disco e permitir que o MongoDB se recupere do último ponto de verificação, mas somente se ele não for encerrado inesperadamente. Caso contrário, para as informações que ocorreram durante o último ponto de verificação, o registro no diário deve ter sido ativado para recuperar esses dados.
O procedimento para o processo de recuperação é que:o banco de dados examinará os arquivos de dados para encontrar o identificador do último ponto de verificação, use esse identificador para pesquisar nos arquivos de diário o registro que corresponda a ele e em seguida, aplique as operações nos arquivos de diário desde o último ponto de verificação.
Como funciona o registro no diário no mecanismo de armazenamento WiredTiger
Para cada cliente que inicia uma operação de gravação, o WiredTiger cria um registro de diário composto de operações de gravação internas que foram acionadas pela gravação inicial. Considere um documento em uma coleção que deve ser atualizado e esperamos que seu índice também seja modificado. O WiredTiger criará um único registro de diário que incorporará a operação de atualização e as modificações de índice correspondentes.
Este registro será armazenado em um buffer de memória cuja capacidade máxima é de 128kB. O mecanismo de armazenamento sincroniza esses registros de diário em buffer com o disco quando um dos seguintes é atendido:
- Uma operação de gravação inclui/implica uma preocupação de gravação de j:true.
- O WiredTiger cria um novo arquivo de diário após cada 100 MB de dados.
- A cada 100 milissegundos, dependendo dos storage.journal.commitIntervalMs.
- No caso de membros do conjunto de réplicas:
- Instância de operações que aguardam entradas de oplog, ou seja, operações de leitura executadas como parte de sessões causalmente consistentes e encaminhamento de consultas de verificação no oplog.
- Após cada aplicação em lote das entradas do oplog no caso dos membros secundários.
No caso de um desligamento forçado do mongod, se as operações de gravação estiverem em andamento, as atualizações podem ser perdidas mesmo se os registros do diário permanecerem nos buffers do WiredTiger.
Compressão de dados do diário
A configuração padrão no MongoDB direciona o WiredTiger para usar compactação rápida para os dados do diário. Isso pode ser alterado dependendo de qual algoritmo de compactação você deseja usar a configuração storage.wiredTiger.engineConfig.journalCompressor. Esses registros de log são compactados apenas se seu tamanho for maior que 128 bytes, que é o tamanho mínimo do registro de log do WiredTiger.
Limitando o tamanho de um arquivo de diário
O tamanho máximo de um arquivo de diário é 100 MB e, portanto, se o arquivo exceder esse limite, um novo será criado.
Depois que o arquivo de diário foi usado na recuperação, ou melhor, existem arquivos mais antigos do que aquele que pode ser usado para recuperar do último ponto de verificação, o WiredTiger os remove automaticamente.
Pré-alocação
Os arquivos de diário podem ser pré-alocados com o mecanismo de armazenamento WiredTiger se o processo mongod determinar que é mais eficiente pré-alocar arquivos de diário do que criar novos.
Como o registro no diário funciona no mecanismo de armazenamento na memória
O mecanismo de armazenamento na memória foi declarado como parte da disponibilidade geral (GA) a partir do MongoDB Enterprise versão 3.2.6. Com este mecanismo de armazenamento, os dados são mantidos na memória, portanto, nenhuma técnica de registro em diário separada. Se houver alguma operação de gravação com uma preocupação de gravação (j:true), ela será imediatamente reconhecida.
Para um conjunto de réplicas com um membro votante usando o mecanismo de armazenamento na memória, é preciso definir writeConcernMajorityJournalDefault como false. Caso contrário, se for definido como verdadeiro, o conjunto de réplicas registrará um aviso de inicialização.
Quando esta opção é definida como false, o banco de dados não esperará que w:“majority” write seja gravado no diário em disco antes de reconhecer as gravações. A desvantagem dessa abordagem é que, com a maioria das operações de gravação, podem ser revertidas no caso de uma perda transitória (como reinicialização ou falha) da maioria dos nós em um determinado conjunto de réplicas.
Se estiver usando o mecanismo de armazenamento MMapv1, a pré-alocação de diário pode ser desabilitada usando a opção --nopreallocation ao iniciar o mongod.
Com o mecanismo de armazenamento WiredTiger, a partir do MongoDB versão 4.0, não é possível especificar a opção --nojournal ou mesmo storage.journal.enabled:false para membros do conjunto de réplicas usando o mecanismo de armazenamento WiredTiger.
Gerenciando o diário
Desativando o registro no diário
Journaling só pode ser desabilitado para implantações independentes e não é recomendado para sistemas de produção. Para o MongoDB versão 4.0 ou superior, não é possível especificar nem a opção --nojournal nem storage.journal.enabled:false quando membros do conjunto de réplicas que usam o mecanismo de armazenamento WiredTiger estão envolvidos.
Para desabilitar o journaling, inicie o mongod com a opção de linha de comando --nojournal.
Monitorar o status do diário
Para obter as estatísticas do diário, use o comando db.serverStatus() que retorna wiredTiger.log.
Obter confirmação de confirmação
Usamos a opção write concern with j para obter confirmação de confirmação. {j:verdadeiro}. O registro no diário deve ser ativado neste caso, caso contrário, a instância do mongod pode produzir um erro.
Se o journaling estiver habilitado, w:“majority” pode significar j:true.
Para um conjunto de réplicas, quando j:true, a configuração requer apenas que o primário grave no diário, independentemente da preocupação de gravação w: No entanto, mesmo que j:true esteja configurado para um conjunto de réplicas, podem ocorrer reversões devido ao failover primário do conjunto de réplicas. Todos os arquivos de diário no diretório de diário são reproduzidos sempre que o MongoDB é reiniciado após uma falha antes que o servidor seja detectado. Como esta operação será gravada na saída do log, não será necessário executar --repair. Compressor rápido é o algoritmo padrão de compactação para o diário. No entanto, pode-se alterar isso dependendo da configuração da instância do mongod. Para uma instância mongod autônoma: Para um membro do conjunto de réplicas: Reinicie a instância do mongod: Se estiver usando o arquivo de configuração, use:mongod -f Se estiver usando as opções de linha de comando:inclua a opção --nojournal, remova todas as opções de linha de comando de replicação ou seja, --replSet e defina o parâmetro disableLogicalSessionCacheRefresh como true Encerre a instância do mongod: Atualize o arquivo de configuração para preparar uma reinicialização do membro do conjunto de réplicas com o novo compressor de diário:Remova o armazenamento. journal.enabled, remova o comentário das configurações de replicação para a implantação, remova a opção disableLogicalSessionCacheRefresh e, por último, remova storage.wiredTiger.engineConfig.journalCompressor. Reinicie a instância do mongod como um membro do conjunto de réplicas Para que o MongoDB garanta a durabilidade da operação de gravação, o journaling é usado por meio do qual os dados são gravados no disco por meio de avanço exploração madeireira. Por mais que o mecanismo de armazenamento WiredTiger (que é o mais preferido) possa recuperar dados pelos últimos pontos de verificação, se o MongoDB sair inesperadamente e o journaling não estiver ativado, a recuperação desses dados se tornará impossível. Caso contrário, se o journaling estiver ativado, o MongoDB poderá reaplicar as operações de gravação na reinicialização e manter um estado consistente.
Recuperação de dados de desligamento inesperado
Alterando o Compressor WiredTiger Journal
Mongod --wiredTigerJournalCompressor <differentCompressor|none>
i.e
storage:
journal:
enabled: false
#replication:
# replSetName: replA
setParameter:
disableLogicalSessionCacheRefresh: true
mongod --nojournal --setParameter disableLogicalSessionCacheRefresh=true
db.shutdownServer() or db.getSiblingDB(‘admin).shutdownServer()
storage:
wiredTiger:
engineConfig:
journalCompressor: <newValue>
replication:
replSetName: replA
mongod --wiredTigerJournalCompressor <differentCompressor|none> --replSet ...Conclusão
