Menu Docs

Downgrade 6.0 Sharded Cluster to 5.0

Antes de tentar fazer um downgrade, familiarize-se com o conteúdo nesta página.

Importante

Before you upgrade or downgrade a sharded cluster, ensure all sharded cluster members are running. If you do not, the upgrade or downgrade will not complete until all members are started.

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

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 fazer downgrade de uma série 6.0para uma série 5.0. No entanto, não há suporte para desatualização adicional dessa implantação da série 5.0para uma implantação da série 4.4.

Antes de iniciar o procedimento de downgrade, você deve concluir as etapas de pré-requisito a seguir.

1

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

Para saber como criar uma cópia de segurança, consulte Métodos de cópia de segurança para um sistema autogerenciado.

2

Para fazer o downgrade do 6.0 para o 5.0, você deve remover os recursos do 6.0 que são incompatíveis com o 5.0. Para obter uma lista de recursos incompatíveis e como removê-los, consulte Considerações sobre downgrade.

3

Ensure that any resharding operations have successfully completed. If a recent resharding operation has failed due to a primary failover, you must first run the cleanupReshardCollection command before downgrading the featureCompatibilityVersion of your sharded cluster.

If a resharding operation is still running while you downgrade the featureCompatibilityVersion of your sharded cluster, the resharding operation will not complete.

4

To downgrade the FCV of your sharded cluster:

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

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

  3. Certifique-se de que nenhum membro do conjunto de réplicas esteja no estado ROLLBACK ou RECOVERING .

  4. Use mongosh to connect to your mongos instance.

  5. Faça o downgrade de featureCompatibilityVersion para "5.0".

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

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

    Observação

    Troubleshooting

  6. Para garantir que todos os membros do conjunto de réplicas tenham o featureCompatibilityVersion atualizado, conecte a cada membro do conjunto de réplicas e verifique o featureCompatibilityVersion:

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

    Dica

    Controle de acesso

    For a sharded cluster that has access control enabled, to run the adminCommand on a shard replica set member, you must connect to the member as a shard local user.

    Todos os membros devem retornar um resultado que inclua:

    "featureCompatibilityVersion" : { "version" : "5.0" }

    Se algum membro retornar uma featureCompatibilityVersion de "6.0", aguarde até que o membro retorne a versão "5.0" antes de continuar.

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

Aviso

Before proceeding with the downgrade procedure, ensure that all sharded cluster members, including delayed replica set members, have the prerequisite changes. To do that, check the featureCompatibilityVersion and the remove the incompatible features for each node before downgrading.

1

Using either a package manager or a manual download, get the latest release in the 5.0 series. If using a package manager, add a new repository for the 5.0 binaries, then perform the actual downgrade process.

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 6.0, faça o downgrade para a versão de correção mais recente do 5.0.

2

Certifique-se de que os binários do 5.0 estão em seu PATH do sistema. Para confirmar sua versão binária, execute o seguinte comando:

mongod --version

A saída do comando deve indicar uma versão da série 5.0.

3

To disable the balancer, connect mongosh to a mongos instance in the sharded cluster, and run the following command:

sh.stopBalancer()

Observação

If a migration is in progress, MongoDB completes the in-progress migration before stopping the balancer. To check the balancer's current state, run sh.isBalancerRunning().

To verify that the balancer is disabled, run the following command:

sh.getBalancerState()

sh.getBalancerState() returns false if the balancer is disabled.

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

4
  1. To stop mongos, run the following command:

    db.shutdownServer()
  2. Reiniciar mongos with the 5.0 binary.

5
  1. Downgrade the shard's secondary members, one at a time.

    1. Desligue o membro.

      To shut down the mongod process, use mongosh to connect to the deployment and run the following command:

      db.adminCommand( { shutdown: 1 } )
    2. Reinicie o membro.

      Para iniciar um processo do mongod, execute o seguinte comando:

      mongod --dbpath </path-to-data-folder>
    3. Aguarde o membro entrar no estado SECONDARY .

      Before downgrading the next secondary, wait for the member to recover to the SECONDARY state. To check the member's state, use the rs.status() method in mongosh.

    4. Repeat the previous steps to downgrade each secondary member.

  2. Downgrade the shard arbiter, if any.

    Skip this step if the replica set does not include an arbiter.

    Downgrade the arbiter member of the sharded cluster:

    1. Desligue o membro.

      To shut down the arbiter, use mongosh to connect to the arbiter and run the following command:

      db.adminCommand( { shutdown: 1 } )
    2. Exclua o conteúdo da linguagem de definição de dados (DDL) do árbitro.

      Para encontrar a linguagem de definição de dados (DDL) do árbitro mongod, verifique a configuração do storage.dbPath ou a opção de linha de comando --dbpath .

      Execute o seguinte comando:

      rm -rf /path/to/mongodb/datafiles/*
    3. Reinicie o árbitro.

      Para iniciar um processo do mongod, execute o seguinte comando:

      mongod --dbpath </path-to-mongodb-datafiles>
    4. Aguarde o membro entrar no estado ARBITER .

      Before downgrading the primary, wait for the member to recover to the ARBITER state. To check the member's state, use the rs.status() method in mongosh.

  3. Downgrade the shard primary.

    1. Rebaixe o primário.

      In mongosh, use rs.stepDown() to step down the primary and start an election for a new primary:

      rs.stepDown()
    2. Verifique se o primário foi desativado.

      Execute o seguinte comando:

      rs.status()

      Verify that the primary has stepped down and another member has assumed the PRIMARY state.

    3. Shut down the former primary member.

      To shut down the former primary, connect to the deployment using mongosh and run the following command:

      db.adminCommand( { shutdown: 1 } )
    4. Restart the mongod with the 5.0 binary.

      Para iniciar um processo do mongod, execute o seguinte comando:

      mongod --dbpath </path-to-mongodb-datafiles>
    5. Repeat for the remaining shards.

6
  1. Downgrade the shard's secondary members of the config servers replica set (CSRS) one at a time:

    1. Desative o secundário.

      Connect to the secondary and run the following command:

      db.adminCommand( { shutdown: 1 } )
    2. Reinicie o membro.

      Para iniciar um processo do mongod, execute o seguinte comando:

      mongod --dbpath </path-to-data-folder>
    3. Aguarde o membro entrar no estado SECONDARY .

      Before downgrading the next secondary, wait for the member to recover to the SECONDARY state. To check the member's state, use the rs.status() method in mongosh.

    4. Repeat the previous steps to downgrade each secondary member.

  2. Downgrade the config server primary.

    1. Rebaixe o primário.

      In mongosh, run rs.stepDown() to step down the primary and start an election for a new primary:

      rs.stepDown()
    2. Verifique se o primário foi desativado.

      Execute o seguinte comando:

      rs.status()

      Verify that the primary has stepped down and another member has assumed the PRIMARY state.

    3. Shut down the former primary member.

      To shut down the former primary, connect to the deployment using mongosh and run the following command:

      db.adminCommand( { shutdown: 1 } )
    4. Restart the mongod with the 5.0 binary.

      Para iniciar um processo do mongod, execute o seguinte comando:

      mongod --dbpath </path-to-mongodb-datafiles>
7

After you downgrade all of the sharded cluster components, connect to a mongos and run the following command to re-enable the balancer:

sh.startBalancer()

The sh.startBalancer() method also enables auto-splitting for the sharded cluster.