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

Downgrade do cluster fragmentado 5.0 para 4.4

Nesta página

  • Caminho de downgrade
  • Criar cópia de segurança
  • Pré-requisitos
  • Procedimento

Antes de tentar qualquer downgrade, familiarize-se com o conteúdo deste documento.

Importante

Antes de atualizar ou fazer downgrade de um conjunto de réplicas, certifique-se de que todos os membros do conjunto de réplicas estejam em execução. Se você não fizer isso, a atualização ou downgrade não será concluído até que todos os membros sejam iniciados.

Se você precisar fazer o downgrade do 5.0, faça o downgrade para a versão de correção mais recente do 4.4.

O MongoDB suporta apenas downgrades de versão única. Você não pode fazer o downgrade para uma versão que esteja várias versões atrás da versão atual.

Por exemplo, você pode desatualizar uma série 5.0 para uma série 4.4. No entanto, não há suporte para desatualização adicional dessa implantação série 4.4 para uma implantação série 4.2.

Opcional, mas recomendado. Crie uma cópia de segurança do seu banco de dados.

Para reduzir de 5.0 para 4.4, você deve remover feições incompatíveis que são persistentes e/ou atualizar configurações incompatíveis. Esses incluem:

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:

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.

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.

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.

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.

Observação

Os arbiters não replicam a collection admin.system.version. Por esse motivo, os arbiters sempre têm uma versão de compatibilidade de recursos igual à versão de downgrade do binário, independentemente do valor fCV do conjunto de réplicas.

Por exemplo, um arbiter em um cluster do MongoDB 5.0 tem um valor fCV de 4.4.

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

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

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

Aviso

Antes de prosseguir com o procedimento de downgrade, certifique-se de que todos os membros, incluindo os membros do conjunto de réplicas atrasadas no cluster fragmentado, reflitam as alterações de pré-requisito. Ou seja, verifique featureCompatibilityVersion e a remoção de feições incompatíveis para cada nó antes de fazer o downgrade.

1

Utilizando um gerenciador de pacotes ou um download manual, obtenha a versão mais recente na série 4.4. Se estiver usando um gerenciador de pacotes, adicione um novo repositório para os binários 4.4 e execute o processo de downgrade real.

Importante

Antes de atualizar ou fazer downgrade de um conjunto de réplicas, certifique-se de que todos os membros do conjunto de réplicas estejam em execução. Se você não fizer isso, a atualização ou downgrade não será concluído até que todos os membros sejam iniciados.

Se você precisar fazer o downgrade do 5.0, faça o downgrade para a versão de correção mais recente do 4.4.

2

Conecte o mongosh a uma instância do mongos no cluster fragmentado e execute o sh.stopBalancer() para desabilitar o balanceador:

sh.stopBalancer()

Observação

Se houver uma migração em andamento, o sistema concluirá essa migração antes de encerrar o balanceador. Você pode executar sh.isBalancerRunning() para verificar o estado atual do balanceador.

Para verificar se o balanceador está desativado, execute sh.getBalancerState(), que retorna falso se o balanceador estiver desativado:

sh.getBalancerState()

Para obter mais informações sobre como desabilitar o balanceador, consulte Desabilitar o balanceador.

3

Faça downgrade dos binários e reinicie.

4

Faça downgrade dos shards um de cada vez.

  1. Faça o downgrade dos membros secundários do fragmento, um de cada vez:

    1. Execute o comando a seguir em mongosh para executar um desligamento limpo ou consulte Interromper processos mongod para obter mais maneiras de encerrar com segurança o processo mongod:

      db.adminCommand( { shutdown: 1 } )
    2. Substitua o binário 5.0 pelo binário 4.4 e reinicie.

    3. Aguarde até que o membro se recupere para o estado SECONDARY antes de fazer o downgrade do próximo membro secundário. Para verificar o estado do membro, conecte mongosh ao fragmento e execute o método rs.status() .

      Repita para fazer o downgrade para cada membro secundário.

  2. Faça o downgrade do árbitro de shard, se houver.

    Pule esta etapa se o conjunto de réplicas não incluir um árbitro.

    1. Execute o comando a seguir em mongosh para executar um desligamento limpo ou consulte Interromper processos mongod para obter mais maneiras de encerrar com segurança o processo mongod:

      db.adminCommand( { shutdown: 1 } )
    2. Exclua o conteúdo da linguagem de definição de dados (DDL) do árbitro. A configuração do storage.dbPath ou a opção de linha de comando do --dbpath especifica a linguagem de definição de dados (DDL) do árbitro mongod.

      rm -rf /path/to/mongodb/datafiles/*
    3. Substitua o binário 5.0 pelo binário 4.4 e reinicie.

    4. Aguarde até que o membro se recupere para o estado ARBITER . Para verificar o estado do membro, conecte mongosh ao membro e execute o método rs.status() .

  3. Faça downgrade do primary do shard.

    1. Reduza o conjunto de réplicas primário. Conecte mongosh à primária e use rs.stepDown() para reduzir a primária e forçar a eleição de uma nova primária:

      rs.stepDown()
    2. Execute rs.status().

      rs.status()

      Quando o status mostrar que o primary foi desativado e outro membro assume o estado PRIMARY , continue.

    3. Execute o seguinte comando a partir de mongosh para executar um desligamento limpo do primário desativado ou consulte Interromper processos mongod para obter outras maneiras de encerrar com segurança o processo mongod :

      db.adminCommand( { shutdown: 1 } )
    4. Substitua o binário 5.0 pelo binário 4.4 e reinicie.

Repita para os shards restantes.

5
  1. Faça o downgrade dos membros secundários do conjunto de réplicas dos servidores de configuração (CSRS), um de cada vez:

    1. Execute o comando a seguir em mongosh para executar um desligamento limpo ou consulte Interromper processos mongod para obter mais maneiras de encerrar com segurança o processo mongod:

      db.adminCommand( { shutdown: 1 } )
    2. Substitua o binário 5.0 pelo binário 4.4 e reinicie.

    3. Aguarde até que o membro se recupere para o estado SECONDARY antes de fazer o downgrade do próximo membro secundário. Para verificar o estado do membro, conecte mongosh ao fragmento e execute o método rs.status() .

      Repita para fazer o downgrade para cada membro secundário.

  2. Reduza o servidor de configuração primário.

    1. Conecte mongosh ao primário e use rs.stepDown() para reduzir o primário e forçar a eleição de um novo primário:

      rs.stepDown()
    2. Execute rs.status().

      rs.status()

      Quando o status mostrar que o primary foi desativado e outro membro assume o estado PRIMARY , continue.

    3. Execute o seguinte comando a partir de mongosh para executar um desligamento limpo do primário desativado ou consulte Interromper processos mongod para obter outras maneiras de encerrar com segurança o processo mongod :

      db.adminCommand( { shutdown: 1 } )
    4. Substitua o binário 5.0 pelo binário 4.4 e reinicie.

6

Quando o downgrade dos componentes do cluster fragmentado for concluído, conecte mongosh a um mongos e reative o balancer.

sh.startBalancer()

O método { mongosh sh.startBalancer() também habilita a divisão automática para o cluster fragmentado.

Voltar

Conjunto de réplicas