Rollbacks durante failover de conjunto de réplicas

Configurar dados de reversão

O parâmetro createRollbackDataFiles controla se os arquivos de reversão são criados ou não durante reversões.

Rollback Data

Por padrão, quando ocorre uma reversão, o MongoDB grava os dados de reversão em arquivos BSON.

Para cada collection cujos dados são rollback, os arquivos de rollback estão localizados em um diretório <dbpath>/rollback/<collectionUUID> e têm nomes de arquivo do formato:

removed.<timestamp>.bson

Por exemplo, se os dados da collection comments no banco de dados reporting sofrerem rollback:

<dbpath>/rollback/20f74796-d5ea-42f5-8c95-f79b39bad190/removed.2020-02-19T04-57-11.0.bson

em que <dbpath> é dbPath de mongod.

grep "rollback file" /var/log/mongodb/mongod.log

Como alternativa, você pode percorrer todos os bancos de dados e executar db.getCollectionInfos() para o UUID específico até obter uma correspondência. Por exemplo:

var mydatabases=db.adminCommand("listDatabases").databases;
var foundcollection=false;
for (var i = 0; i < mydatabases.length; i++) {
   let mdb = db.getSiblingDB(mydatabases[i].name);
   collections = mdb.getCollectionInfos( { "info.uuid": UUID("20f74796-d5ea-42f5-8c95-f79b39bad190") } );
   for (var j = 0; j < collections.length; j++) {   // Array of 1 element
      foundcollection=true;
      print(mydatabases[i].name + '.' + collections[j].name);
      break;
   }
   if (foundcollection) { break; }
}

Exclusão de dados de reversão

Se a operação a ser revertida for uma queda de coleção ou uma exclusão de documento, a reversão da coleta ou exclusão de documento não será gravada no diretório de dados de reversão.

Ler dados de reversão

Para ler o conteúdo dos arquivos de rollback, use bsondump. Com base no conteúdo e no conhecimento de seus aplicativos, os administradores podem decidir o próximo curso de ação.

Diário e Escreva sobre Preocupação majority

Para evitar reversões de dados que foram confirmados para o cliente, execute todos os membros votantes com o registro no diário ativado e use a preocupação de gravação { w: "majority" } para garantir que as operações de gravação se propaguem para a maioria dos nós do conjunto de réplicas antes de retornar com confirmação para o cliente emissor.

A partir do MongoDB 5.0, { w: "majority" } é a preocupação com gravação padrão para a maioria das implantações do MongoDB. Consulte Preocupação de gravação padrão implícita.

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.

Visibilidade de dados que podem ser revertidos

• Independentemente da write concern, outros clientes que usam a read concern podem ver o resultado de uma operação de gravação antes que a operação de gravação seja reconhecida pelo cliente "local" "available" emissor.

• Os clientes que usam a preocupação de leitura "local" ou "available" podem ler dados que podem ser revertidos posteriormente durante failovers de conjuntos de réplicas.

Para operações em uma transação de vários documentos, quando uma transação é confirmada, todas as alterações de dados feitas na transação são salvas e ficam visíveis fora da transação. Ou seja, uma transação não confirmará algumas de suas alterações enquanto reverte outras.

Até que uma transação seja confirmada, as alterações de dados feitas na transação não serão visíveis fora da transação.

No entanto, quando uma transação é gravada em vários fragmentos, nem todas as operações de leitura externas precisam esperar que o resultado da transação confirmada fique visível nos fragmentos. Por exemplo, se uma transação estiver comprometida e escrever 1 estiver visível no fragmento A, mas escrever 2 ainda não estiver visível no fragmento B, uma leitura externa em questão de leitura "local" poderá ler os resultados da escrita 1 sem ver a escrita 2.

Operações do usuário

A partir da versão 4.2, o MongoDB mata todas as operações de usuário em andamento quando um membro insere o estado ROLLBACK.

Construções de índices

• Para a versão de compatibilidade de recursos (fcv) "4.2", o MongoDB espera que quaisquer construções de índice em andamento terminem antes de iniciar uma reversão.

Para obter mais informações sobre o processo de criação de índices, consulte Construções de índices em coleções preenchidas.

Operações de índice quando Preocupação de leitura "majority" está desativada

Desativar a preocupação de leitura "majority" impede que os comandos collMod que modificam um índice sejam revertidos. Se essa operação precisar ser revertida, você deverá ressincronizar os nós afetados com o nó primário.

Limitações de tamanho

O MongoDB é compatível com os seguintes algoritmos de rollback, que possuem diferentes limitações de tamanho:

• Recuperar para um registro de data/hora, em que um primário anterior reverte para um determinado momento consistente e aplica operações até alcançar a ramificação do histórico da fonte de sincronização. Este é o algoritmo de rollback padrão.

  Ao usar esse algoritmo, o MongoDB não limita a quantidade de dados que você pode reverter.

• Rollback via Refetch, em que um antigo primário encontra o ponto em comum entre seu oplog e o oplog da fonte de sincronização. Em seguida, o nó examina e reverte todas as operações em seu oplog até atingir esse ponto em comum. Rollback via Refetch ocorre somente quando a configuração enableMajorityReadConcern em seu arquivo de configuração está definida como false.

  Ao usar esse algoritmo, o MongoDB só pode reverter até 300 MB de dados.

  Observação

  A partir do MongoDB 5.0, enableMajorityReadConcern é definido como true e não pode ser alterado.

Limitações de tempo decorrido de reversão

O limite de tempo de reversão padrão é de 24 horas e é configurável usando o parâmetro rollbackTimeLimitSecs.

O MongoDB mede o tempo decorrido como o tempo entre a primeira operação comum nos oplogs e a última entrada no oplog do membro que está sofrendo rollback.