Downgrade do conjunto de réplicas 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 write concern 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. 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 seu conjunto de réplicas 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 o featureCompatibilityVersion do seu conjunto de réplicas:

1. Conecte um shell mongo ao primary.

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

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

   O comando setFeatureCompatibilityVersion executa gravações em uma collection interna do sistema e é idempotente. Se, por algum motivo, o comando não for concluído com êxito, tente novamente o comando no primary.

3. Para garantir que todos os membros do conjunto de réplicas reflitam o featureCompatibilityVersion atualizado, conecte a cada membro do conjunto de réplicas e marque o featureCompatibilityVersion:

   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 Visualizar FeatureCompatibilityVersion.

5. Remover os recursos persistentes do FCV 5.0

As etapas a seguir serão necessárias somente se 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

• Redefina os padrões no servidor primário no grupo com db.admin.runCommand. O primário deve ser o último servidor de configuração do grupo a ser atualizado.

  db.admin.runCommand(
     {
        setAuditConfig: 1,
        filter: {},
        auditAuthorizationSuccess: false
     }
  )

  O documento de configuração também pode ser removido após o downgrade:

  config.settings.remove({_id: 'audit'});

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

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

6. 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.