Downgrade do cluster fragmentado 5.0 para 4.4

1. Preocupações de leitura e gravação padrão do cluster

O MongoDB 5.0 alterou o valor padrão para read concern e write concern em todo o cluster, e o downgrade para o MongoDB 4.4 pode alterar esses padrões novamente. Considere configurar manualmente o read concern e write concern do seu cluster antes de fazer o downgrade:

• Para configurar manualmente um valor padrão para um write concern ou preocupação de gravação do cluster, utilize o comando setDefaultRWConcern .

• Se seu cluster inclui um árbitro e você já havia desativado a preocupação "Majority" read para evitar a pressão do cache em determinadas situações, convém configurar --enableMajorityReadConcern false ou replication.enableMajorityReadConcern: false depois de fazer o downgrade.

2. Campos . $ do documento com ou caracteres

O MongoDB 5.0 adiciona suporte para incluir os caracteres . ou $ nos nomes de campo do documento. Você deve excluir todos os documentos que contenham nomes de campos que incluam os caracteres . ou $ antes de fazer o downgrade para o MongoDB 4.4.

3. Arquivos de dados de fuso horário em formato fino

O MongoDB 5.0 permite suporte para arquivos de dados de fuso horário em formato compacto. Se estiver usando arquivos de dados de fuso horário de formato fino em seu sistema, conforme fornecido ao MongoDB com a opção de linha de comando --timeZoneInfo ou a configuração de arquivo de configuração processManagement.timeZoneInfo, será necessário fazer downgrade para o MongoDB 4.4.7 ou posterior, ou então reverter seus arquivos de dados de fuso horário para usar os arquivos de dados anteriores sem formato fino.

4. Refragmentação

Certifique-se de que todas as operações de refragmentação tenham sido concluídas com êxito antes de tentar qualquer procedimento de downgrade. Se uma operação recente de refragmentação falhar devido a um failover primary, você deverá primeiro executar o comando cleanupReshardCollection antes de fazer downgrade do featureCompatibilityVersion do cluster fragmentado.

Se uma operação de refragmentação ainda estiver em execução enquanto você faz downgrade do featureCompatibilityVersion do cluster fragmentado, a operação de refragmentação será cancelada.

5. Versão de compatibilidade de recursos (FCV) de downgrade

Primeiro, verifique o seguinte:

• Certifique-se de que não haja initial sync em andamento. A execução do comando setFeatureCompatibilityVersion enquanto uma initial sync estiver em andamento fará com que a initial sync seja reiniciada.

• Certifique-se de que nenhum nó tenha um campo newlyAdded na configuração do conjunto de réplicas. Execute o seguinte comando em cada nó do cluster fragmentado para verificar isso:

  use local
  db.system.replset.find( { "members.newlyAdded" : { $exists : true } } );

  O campo newlyAdded só aparece no documento de configuração do conjunto de réplicas de um nó durante e logo após uma sincronização inicial.

• Garanta que nenhum membro do conjunto de réplicas esteja no estado ROLLBACK ou RECOVERING.

Em seguida, para fazer downgrade do featureCompatibilityVersion do seu cluster fragmentado:

1. Conecte uma shell do mongo à instância do mongos.

2. Faça o downgrade de featureCompatibilityVersion para "4.4".

   db.adminCommand({setFeatureCompatibilityVersion: "4.4"})

   O comando setFeatureCompatibilityVersion executa grava em uma coleção de sistema interno e é idempotente. Se, por qualquer motivo, o comando não for concluído com êxito, tente novamente o comando na instânciamongos.

   Observação

   • Enquanto setFeatureCompatibilityVersion estiver em execução no cluster fragmentado, migrações, divisões e mesclagens de partes podem apresentar falhas com ConflictingOperationInProgress.

   • Se setFeatureCompatibilityVersion falhar com um erro ManualInterventionRequired e o cluster tiver passado recentemente por uma operação de refragmentação que falhou devido a uma eleição, você deverá executar o comando cleanupReshardCollection antes de tentar setFeatureCompatibilityVersion novamente.

3. Para garantir que todos os membros do cluster fragmentado reflitam o featureCompatibilityVersion atualizado, conecte a cada membro do conjunto de réplicas do shard e a cada membro do conjunto de réplicas do servidor de configuração e marque o featureCompatibilityVersion:

   Dica

   Para um cluster fragmentado que tenha o controle de acesso habilitado, para executar o seguinte comando em um nó do conjunto de réplicas do fragmento, você deve se conectar ao nó como um usuário local do fragmento.

   db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

   Todos os membros devem retornar um resultado que inclua:

   "featureCompatibilityVersion" : { "version" : "4.4" }

   Se algum membro retornar uma featureCompatibilityVersion de "5.0", aguarde até que o membro reflita a versão "4.4" antes de prosseguir.

Para obter mais informações sobre o valor featureCompatibilityVersion retornado, consulte Obter FeatureCompatibilityVersion.

6. Remover os recursos persistentes do FCV 5.0

As etapas a seguir serão necessárias somente se o FCV tiver sido definido como "5.0".

Remova todas as feições do 5.0 persistentes que são incompatíveis com 4.4. Esses incluem:

Coleção de Séries Temporais

Remova todas as coleções de séries temporais.

Gerenciamento de filtros de auditoria em tempo de execução

• Desative o Gerenciamento de Filtros de Auditoria do Runtime definindo auditLog.runtimeConfiguration como false no arquivo de configuração do nó.

• Atualize os filtros de auditoria para esta instância mongod ou mongos no arquivo de configuração local.

7. Remover Recursos 5.0

Remova todas as feições persistentes que utilizam feições do 5.0. Isso inclui, mas não está limitado a:

• Se alguma definição de visualização incluir operadores 5.0, como $dateAdd ou $sampleRate, ela deverá ser removida. Consulte Novos Operadores de Agregação para a lista completa.

Fazer downgrade de um cluster fragmentado

sh.stopBalancer()

sh.getBalancerState()

sh.startBalancer()