Downgrade 6.0 Sharded Cluster to 5.0
Antes de tentar fazer um downgrade, familiarize-se com o conteúdo nesta página.
Caminho de downgrade
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.
Pré-requisitos
Antes de iniciar o procedimento de downgrade, você deve concluir as etapas de pré-requisito a seguir.
Criar cópia de segurança
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.
Remover recursos incompatíveis do Backward-Incompatible
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.
Ensure No Resharding Operations are in Progress
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.
Downgrade Feature Compatibility Version (fCV)
To downgrade the FCV of your sharded cluster:
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.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.Certifique-se de que nenhum membro do conjunto de réplicas esteja no estado
ROLLBACK
ouRECOVERING
.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
While
setFeatureCompatibilityVersion
is running on the sharded cluster, chunk migrations, splits, and merges can fail withConflictingOperationInProgress
.If
setFeatureCompatibilityVersion
fails with aManualInterventionRequired
error, and the cluster has recently undergone a resharding operation that had failed due to an election, you must run thecleanupReshardCollection
command before you attempt to runsetFeatureCompatibilityVersion
again.
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 ofeatureCompatibilityVersion
: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.
Procedimento de downgrade
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.
Baixe os binários 5.0 mais recentes.
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.
Desabilitar o Balanceador.
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.
Downgrade each shard, one at a time.
Downgrade the shard's secondary members, one at a time.
Desligue o membro.
To shut down the
mongod
process, usemongosh
to connect to the deployment and run the following command:db.adminCommand( { shutdown: 1 } ) Reinicie o membro.
Para iniciar um processo do
mongod
, execute o seguinte comando:mongod --dbpath </path-to-data-folder> 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 thers.status()
method inmongosh
.Repeat the previous steps to downgrade each secondary member.
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:
Desligue o membro.
To shut down the arbiter, use
mongosh
to connect to the arbiter and run the following command:db.adminCommand( { shutdown: 1 } ) 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 dostorage.dbPath
ou a opção de linha de comando--dbpath
.Execute o seguinte comando:
rm -rf /path/to/mongodb/datafiles/* Reinicie o árbitro.
Para iniciar um processo do
mongod
, execute o seguinte comando:mongod --dbpath </path-to-mongodb-datafiles> 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 thers.status()
method inmongosh
.
Downgrade the shard primary.
Rebaixe o primário.
In
mongosh
, users.stepDown()
to step down the primary and start an election for a new primary:rs.stepDown() 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.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 } ) Restart the
mongod
with the 5.0 binary.Para iniciar um processo do
mongod
, execute o seguinte comando:mongod --dbpath </path-to-mongodb-datafiles> Repeat for the remaining shards.
Downgrade the config servers.
Downgrade the shard's secondary members of the config servers replica set (CSRS) one at a time:
Desative o secundário.
Connect to the secondary and run the following command:
db.adminCommand( { shutdown: 1 } ) Reinicie o membro.
Para iniciar um processo do
mongod
, execute o seguinte comando:mongod --dbpath </path-to-data-folder> 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 thers.status()
method inmongosh
.Repeat the previous steps to downgrade each secondary member.
Downgrade the config server primary.
Rebaixe o primário.
In
mongosh
, runrs.stepDown()
to step down the primary and start an election for a new primary:rs.stepDown() 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.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 } ) Restart the
mongod
with the 5.0 binary.Para iniciar um processo do
mongod
, execute o seguinte comando:mongod --dbpath </path-to-mongodb-datafiles>
Reabilitar o balanceador.
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.