Registro no diário
Nesta página
Para oferecer durabilidade no caso de uma falha, o MongoDB usa o log wri-ahead em arquivos de registro no diário em 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
Você não pode especificar a opção --nojournal ou storage.journal.enabled: false para membros do conjunto de réplicas que usam o mecanismo de armazenamento 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
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 uma operação de gravação incluir ou implicar uma write concern de
j: true.Além disso, para membros secundários, após cada aplicação em lote das entradas oplog.
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.
Journal Files
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
Se um registro de log for menor ou igual a 128 bytes (o tamanho mínimo do registro de log para o 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 de diário.
O WiredTiger remove automaticamente os arquivos de diário antigos e mantém apenas os arquivos necessários para a recuperação do último ponto de verificação. Para determinar quanto espaço em disco reservar para os arquivos de diário, leve em consideração o seguinte:
O tamanho máximo padrão para um checkpoint é de 2 GB
Pode ser necessário ter espaço adicional para que o MongoDB grave novos registros no diário durante a recuperação de um checkpoint
O MongoDB compacta registros no 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 ponto de verificação ou desabilitar a compactação, seus cálculos poderão ser consideravelmente diferentes
Por estas razões é 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 reservar espaço em disco suficiente para seus arquivos de diário, o servidor MongoDB falhará.
Pré-alocação
O WiredTiger pré-aloca arquivos do diário.
Registros no diário e mecanismo de armazenamento in-memory
No 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 preocupação de gravação 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.