Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
Registro no diário
Nesta página
Para oferecer durabilidade no caso de uma falha, o MongoDB usa o registro de gravação antecipada em arquivos de diário no disco.
Journaling e o WiredTiger Storage Engine
Importante
O registro mencionado nesta seção se refere ao log do WiredTiger write-ahead (ou seja, o diário) e não ao arquivo de log do MongoDB.
O WiredTiger usa checkpoints para fornecer uma visualização consistente dos dados no disco e permitir que o MongoDB se recupere do último checkpoint. No entanto, se o MongoDB sair inesperadamente entre os checkpoints, será necessário um registro no diário para recuperar as informações que ocorreram após o último checkpoint.
Observação
A partir do MongoDB 4.0, você não pode especificar a opção --nojournal ou storage.journal.enabled:
false para membros do conjunto de réplicas que usam o storage engine WiredTiger.
Com os registros no diário, o processo de recuperação:
Procura nos arquivos de dados para localizar o identificador do último checkpoint.
Pesquisa nos arquivos do diário o registro que corresponde ao identificador do último checkpoint.
Aplique as operações nos arquivos do diário desde o último checkpoint.
Processo de registros no diário
Alterado na versão 3,2.
Com os registros no diário, o WiredTiger cria um registro de diário para cada operação de gravação iniciada pelo cliente. O registro do diário inclui quaisquer operações de gravação internas causadas pela gravação inicial. Por exemplo, uma atualização de um documento em uma collection pode resultar em modificações nos índices; o WiredTiger cria um único registro do diário, que inclui a operação de atualização e suas modificações de índices associadas.
O MongoDB configura o WiredTiger para usar o buffer na memória para armazenar os registros do diário. Os threads se coordenam para alocar e copiar em sua parte do buffer. Todos os registros de diário de até 128 kB são armazenados em buffer.
O WiredTiger sincroniza os registros do diário em buffer com o disco em qualquer uma das seguintes condições:
Para membros do conjunto de réplicas (membros primários e secundários),
Se houver operações aguardando entradas de oplog. As operações que podem esperar pelas entradas do oplog incluem:
encaminhar queries de verificação contra o oplog
operações de leitura realizadas como parte de sessões causalmente consistentes
Além disso, para membros secundários, após cada aplicação em lote das entradas oplog.
Se uma operação de gravação incluir ou implicar uma write concern de
j: true.Observação
Write concern
"majority"implicaj: truese awriteConcernMajorityJournalDefaultfor verdadeira.A cada 100 milissegundos (consulte
storage.journal.commitIntervalMs).Quando o WiredTiger cria um novo arquivo de diário. Como o MongoDB usa um limite de tamanho de arquivo de diário de 100 MB, o WiredTiger cria um novo arquivo de diário aproximadamente a cada 100 MB de dados.
Importante
Entre as operações de gravação, enquanto os registros do diário permanecem nos buffers do WiredTiger, as atualizações podem ser perdidas após um desligamento forçado do mongod.
Dica
Veja também:
O comando serverStatus retorna informações sobre as estatísticas do diário WiredTiger no campo wiredTiger.log.
Arquivos do diário
Para os arquivos de diário, o MongoDB cria um subdiretório denominado journal no diretório dbPath . Os arquivos de diário do WiredTiger têm nomes com o seguinte formato WiredTigerLog.<sequence> onde <sequence> é um número preenchido com zeros começando em 0000000001.
Registros de diário
Os arquivos do diário contêm um registro para cada operação de gravação iniciada pelo cliente
O registro do diário inclui quaisquer operações de gravação internas causadas pela gravação inicial. Por exemplo, uma atualização de um documento em uma collection pode resultar em modificações nos índices; o WiredTiger cria um único registro do diário, que inclui a operação de atualização e suas modificações de índices associadas.
Cada registro tem um identificador único.
O tamanho mínimo do registro do diário para o WiredTiger é de 128 bytes.
Compressão
Por padrão, o MongoDB configura o WiredTiger para usar compressão snappy para seus registros no diário. Para especificar um algoritmo de compressão diferente ou nenhuma compressão, utilize a configuração do storage.wiredTiger.engineConfig.journalCompressor. Para obter detalhes, consulte Alterar o compressor WiredTiger Journal.
Observação
No caso de um registro de log menor ou igual a 128 bytes (o tamanho mínimo do registro de log para WiredTiger), o WiredTiger não compactará esse registro.
Limite de tamanho de arquivos do diário
Os arquivos do diário do WiredTiger têm um limite de tamanho máximo de aproximadamente 100 MB. Quando o arquivo excede esse limite, o WiredTiger cria um novo arquivo do diário.
O WiredTiger remove automaticamente os arquivos do diário antigos e mantém apenas os arquivos necessários para a recuperação do último checkpoint. Para determinar quanto espaço em disco deve ser reservado para arquivos do diário, considere o seguinte:
O tamanho máximo padrão para um checkpoint é de 2 GB
Pode ser necessário espaço adicional para que o MongoDB escreva novos arquivos do diário enquanto se recupera de um checkpoint
MongoDB comprime arquivos do diário
O tempo necessário para restaurar um checkpoint é específico para seu caso de uso
Se você substituir o tamanho máximo do checkpoint ou desativar a compactação, seus cálculos podem ser significativamente diferentes
Por esses motivos, é difícil calcular exatamente quanto espaço adicional você precisa. Superestimar o espaço em disco é sempre uma abordagem mais segura.
Importante
Se você não separar espaço em disco suficiente para seus arquivos do diário, o MongoDB Server falhará.
Pré-alocação
O WiredTiger pré-aloca arquivos do diário.
Registros no diário e mecanismo de armazenamento in-memory
A partir da versão 3.2.6 do MongoDB Enterprise, o Mecanismo de armazenamento in-memory faz parte da disponibilidade geral (GA). Como seus dados são mantidos na memória, não existe um diário separado. As operações de gravação com uma write concern de j: true são imediatamente reconhecidas.
Se qualquer membro votante de um conjunto de réplicas usar o mecanismo de armazenamento na memória, você deverá definir writeConcernMajorityJournalDefault como false.
Observação
A partir da versão 4.2 (e 4.0.13 e 3.6.14 ), se um membro do conjunto de réplicas usar o mecanismo de armazenamento na memória (com ou sem votação), mas o conjunto de réplicas tiver writeConcernMajorityJournalDefault definido como verdadeiro, o membro do conjunto de réplicas registrará um aviso de inicialização.
Com writeConcernMajorityJournalDefault definido como false, o MongoDB não espera que w: "majority" gravações sejam gravadas no registro em disco antes de reconhecer as gravações. Dessa forma, as operações de gravações "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.