Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/

Conjunto de réplicas Oplog

Nesta página

  • Tamanho do log
  • Volumes de trabalho que Podem Exigir um Tamanho maior do Oplog
  • Oplog Status
  • Aplicativo Oplog Lento
  • Comportamento da Coleção do Oplog

O oplog (log de operações) é uma coleção limitada especial que mantém um registro contínuo de todas as operações que modificam os dados armazenados em seus bancos de dados. Se as operações de gravação não modificarem nenhum dado ou falharem, não criarão entradas no oplog.

Diferentemente de outras coletas limitadas, o registro pode ultrapassar o limite de tamanho configurado para evitar a exclusão do majority commit point.

O MongoDB aplica operações de banco de dados no primário e, em seguida, registra as operações no oplog do primário. Em seguida, os membros secundários copiam e aplicam essas operações em um processo assíncrono. Todos os membros do conjunto de réplicas contêm uma cópia do oplog, na coleção local.oplog.rs, o que lhes permite manter o estado atual do banco de dados.

Para facilitar a replicação, todos os membros do conjunto de réplicas enviam pulsações (pings) a todos os outros membros. Qualquer membro secundário pode importar entradas oplog de qualquer outro membro.

Cada operação no oplog é idempotente. Ou seja, as operações oplog produzem os mesmos resultados, sejam aplicadas uma ou várias vezes ao conjunto de dados de destino.

Quando você inicia um membro do conjunto de réplicas pela primeira vez, o MongoDB cria um oplog de tamanho padrão se você não especificar o tamanho do oplog.

Para sistemas Unix e Windows

O tamanho padrão do oplog depende do mecanismo de armazenamento:

Mecanismo de armazenamento
Tamanho Padrão do Oplog

5% de espaço livre em disco

5% da memória física

O tamanho padrão do oplog tem as seguintes restrições:

  • O tamanho mínimo do oplog é de 990 MB. Se 5% de espaço livre em disco ou memória física (o que for aplicável com base no seu storage engine) for menor que 990 MB, o tamanho padrão do oplog será de 990 MB.

  • O tamanho máximo padrão do oplog é 50 GB. Se 5% de espaço livre em disco ou memória física (o que for aplicável com base em seu mecanismo de armazenamento) for maior que 50 GB, o tamanho padrão do oplog será 50 GB.

Para sistemas macOS de 64 bits

O tamanho padrão do oplog é de 192 MB de espaço livre em disco ou memória física, dependendo do mecanismo de armazenamento:

Mecanismo de armazenamento
Tamanho Padrão do Oplog

192 MB do espaço livre em disco

192 MB da memória física

Na maioria dos casos, o tamanho padrão do oplog é suficiente. Por exemplo, se um oplog tiver 5% do espaço livre em disco e for preenchido em 24 horas de operações, os secundários poderão parar de copiar entradas do oplog por até 24 horas sem se tornarem obsoletos demais para continuar replicando. No entanto, a maioria dos conjuntos de réplicas tem volumes de operação muito mais baixos e seus oplogs podem conter números muito maiores de operações.

Antes de mongod criar um oplog, você pode especificar seu tamanho com a opção oplogSizeMB. Depois de iniciar um membro do conjunto de réplicas pela primeira vez, use o comando administrativo replSetResizeOplog para alterar o tamanho do oplog. replSetResizeOplog permite redimensionar o oplog dinamicamente sem reiniciar o processo mongod.

Você pode especificar o número mínimo de horas para preservar uma entrada de oplog em que mongod só remove uma entrada de oplog se ambos os critérios a seguir forem atendidos:

  • O oplog atingiu otamanho máximo configurado .

  • A entrada do oplog é mais antiga que o número configurado de horas com base no relógio do sistema host.

Por padrão, o MongoDB não define um período mínimo de retenção de oplog e trunca automaticamente o oplog, começando com as entradas mais antigas para manter o tamanho máximo de oplog configurado.

Para configurar o período mínimo de retenção de oplog ao iniciar o mongod,:

Para configurar o período mínimo de retenção de oplog em um mongod em execução, utilize replSetResizeOplog. Definir o período mínimo de retenção do oplog enquanto o mongod está em execução substitui quaisquer valores definidos na inicialização. Você deve atualizar o valor da configuração do arquivo de configuração correspondente ou da opção de linha de comando para persistir essas alterações por meio da reinicialização do servidor.

As entradas oplog têm registro de data/hora. A oplog window é a diferença de tempo entre os mais recentes e os mais antigos registros de data/hora no oplog. Se um nó secundário perder a conexão com o principal, ele só poderá usar a replicação para sincronizar novamente se a conexão for restaurada dentro da oplog window.

Se você puder prever que a carga de trabalho do seu conjunto de réplicas se assemelhe a um dos seguintes padrões, talvez queira criar um oplog maior do que o padrão. Por outro lado, se seu aplicativo realiza predominantemente leituras com uma quantidade mínima de operações de gravação, um registro menor pode ser suficiente.

Os seguintes volumes de trabalho podem exigir um tamanho do oplog maior.

O oplog deve traduzir várias atualizações em operações individuais para manter a idempotência. Isso pode usar uma grande quantidade de espaço de log sem um aumento correspondente no tamanho dos dados ou no uso do disco.

Se você excluir aproximadamente a mesma quantidade de dados que insere, o banco de dados não aumentará significativamente o uso do disco, mas o tamanho do registro de operações pode ficar bem grande.

Se uma parte significativa do volume de trabalho for de atualizações que não aumentam o tamanho dos documentos, o banco de dados registrará um grande número de operações, mas não alterará a quantidade de dados no disco.

Para visualizar o status do oplog, incluindo o tamanho e a faixa de tempo das operações, execute o método rs.printReplicationInfo(). Para obter mais informações sobre o status do oplog, consulte Verificar o tamanho do oplog.

Em várias situações excepcionais, as atualizações do oplog de um secundário podem ficar atrasadas em relação ao tempo de desempenho desejado. Use db.getReplicationInfo() de um membro secundário e a saída de status de replicação para avaliar o estado atual da replicação e determinar se há algum atraso de replicação não intencional.

A partir do MongoDB 4.2, os administradores podem limitar a taxa na qual o primário aplica suas gravações com o objetivo de manter o atraso abaixo de um valor máximo majority committed configurável flowControlTargetLagSeconds.

Por padrão, o controle de fluxo é enabled.

Observação

Para que o controle de fluxo seja ativado, o conjunto de réplicas/cluster fragmentado deve ter: featureCompatibilityVersion (fCV) de 4.2 e preocupação de leitura majority enabled. Ou seja, o controle de fluxo ativado não terá efeito se fCV não for 4.2 ou se a maioria das preocupações de leitura estiver desativada.

Consulte Atraso de Replicação para obter mais informações.

Os membros secundários de um conjunto de réplicas registram entradas de log oplog que levam mais tempo do que o limite de operação lenta para serem aplicadas. Essas mensagens são logged para os secundários no componente REPL com o texto applied op: <oplog entry> took <num>ms.

2018-11-16T12:31:35.886-05:00 I REPL [repl writer worker 13] applied op: command { ... }, took 112ms

O log do aplicativo oplog lento nos secundários é:

Para obter mais informações sobre como definir o limite de operação lento, consulte

Você não poderá drop a coleção local.oplog.rs de qualquer membro do conjunto de réplicas se sua implantação do MongoDB usar o WiredTiger Storage Engine. Você não pode eliminar a coleção local.oplog.rs de uma instância autônoma do MongoDB. mongod exige o oplog para Replicação e recuperação de um nó se o nó cair.

A partir do MongoDB 5.0, não é mais possível executar operações de gravação manual no oplog em um cluster em execução como um conjunto de réplicas. A execução de operações de gravação no oplog ao ser executada como uma instância autônoma só deve ser feita com a orientação do Suporte do MongoDB.

Voltar

Replicação