Downgrade do cluster fragmentado 5.0 para 4.4
Antes de tentar qualquer downgrade, familiarize-se com o conteúdo deste documento.
Caminho de downgrade
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.
Criar cópia de segurança
Opcional, mas recomendado. Crie uma cópia de segurança do seu banco de dados.
Pré-requisitos
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:
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
oureplication.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. Downgrade versão de compatibilidade do recurso (FCV)
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
ouRECOVERING
.
Em seguida, para fazer downgrade do featureCompatibilityVersion
do seu cluster fragmentado:
Conecte uma shell do
mongo
à instância domongos
.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 comConflictingOperationInProgress
.Se
setFeatureCompatibilityVersion
falhar com um erroManualInterventionRequired
e o cluster tiver passado recentemente por uma operação de refragmentação que falhou devido a uma eleição, você deverá executar o comandocleanupReshardCollection
antes de tentarsetFeatureCompatibilityVersion
novamente.
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 ofeatureCompatibilityVersion
: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.
6. 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
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.
Procedimento
Fazer downgrade de um cluster fragmentado
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.
Baixe os binários 4.4 mais recentes.
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.
Desabilitar o Balanceador.
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.
Faça o downgrade de cada shard, um de cada vez.
Faça downgrade dos shards um de cada vez.
Faça o downgrade dos membros secundários do fragmento, um de cada vez:
Execute o comando a seguir em
mongosh
para executar um desligamento limpo ou consulte Interromper processosmongod
para obter mais maneiras de encerrar com segurança o processomongod
:db.adminCommand( { shutdown: 1 } ) Substitua o binário 5.0 pelo binário 4.4 e reinicie.
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, conectemongosh
ao fragmento e execute o métodors.status()
.Repita para fazer o downgrade para cada membro secundário.
Faça o downgrade do árbitro de shard, se houver.
Pule esta etapa se o conjunto de réplicas não incluir um árbitro.
Execute o comando a seguir em
mongosh
para executar um desligamento limpo ou consulte Interromper processosmongod
para obter mais maneiras de encerrar com segurança o processomongod
:db.adminCommand( { shutdown: 1 } ) 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 árbitromongod
.rm -rf /path/to/mongodb/datafiles/* Substitua o binário 5.0 pelo binário 4.4 e reinicie.
Aguarde até que o membro se recupere para o estado
ARBITER
. Para verificar o estado do membro, conectemongosh
ao membro e execute o métodors.status()
.
Faça downgrade do primary do shard.
Reduza o conjunto de réplicas primário. Conecte
mongosh
à primária e users.stepDown()
para reduzir a primária e forçar a eleição de uma nova primária:rs.stepDown() Execute
rs.status()
.rs.status() Quando o status mostrar que o primary foi desativado e outro membro assume o estado
PRIMARY
, continue.Execute o seguinte comando a partir de
mongosh
para executar um desligamento limpo do primário desativado ou consulte Interromper processosmongod
para obter outras maneiras de encerrar com segurança o processomongod
:db.adminCommand( { shutdown: 1 } ) Substitua o binário 5.0 pelo binário 4.4 e reinicie.
Repita para os shards restantes.
Faça downgrade dos servidores de configuração.
Faça o downgrade dos membros secundários do conjunto de réplicas dos servidores de configuração (CSRS), um de cada vez:
Execute o comando a seguir em
mongosh
para executar um desligamento limpo ou consulte Interromper processosmongod
para obter mais maneiras de encerrar com segurança o processomongod
:db.adminCommand( { shutdown: 1 } ) Substitua o binário 5.0 pelo binário 4.4 e reinicie.
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, conectemongosh
ao fragmento e execute o métodors.status()
.Repita para fazer o downgrade para cada membro secundário.
Reduza o servidor de configuração primário.
Conecte
mongosh
ao primário e users.stepDown()
para reduzir o primário e forçar a eleição de um novo primário:rs.stepDown() Execute
rs.status()
.rs.status() Quando o status mostrar que o primary foi desativado e outro membro assume o estado
PRIMARY
, continue.Execute o seguinte comando a partir de
mongosh
para executar um desligamento limpo do primário desativado ou consulte Interromper processosmongod
para obter outras maneiras de encerrar com segurança o processomongod
:db.adminCommand( { shutdown: 1 } ) Substitua o binário 5.0 pelo binário 4.4 e reinicie.
Reabilitar o balanceador.
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.