Fazer downgrade 4.4 Réplica definida para 4.2
Nesta página
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 4.4, faça o downgrade para a versão de correção mais recente do 4.2.
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 o downgrade de uma série 4.4 para uma implantação da série 4.2. No entanto, fazer outro downgrade da implantação da série 4.2 para uma implantação da série 4.0 não é suportado.
Aviso
Downgradefloor
Se você precisar fazer o downgrade da versão 4.4, faça o downgrade para a 4.2.6 ou uma versão posterior. Você não pode fazer o downgrade para a 4.2.5 ou uma versão anterior.
Criar cópia de segurança
Opcional, mas recomendado. Crie uma cópia de segurança do seu banco de dados.
Controle de acesso
Se o seu conjunto de réplicas tiver o controle de acesso ativado, os privilégios de usuário de downgrade deverão incluir privilégios para listar e gerenciar índices nos bancos de dados. Um usuário com papel do root
tem os privilégios exigidos.
Pré-requisitos
Para reduzir de 4.2 para 4.0, você deve remover feições incompatíveis que são persistentes e/ou atualizar configurações incompatíveis.
1. Comprimento do namespace
Começando no MongoDB 4.4:
O limite de comprimento do namespace para coleções e visualizações não fragmentadas é de 255 bytes e 235 bytes para coleções fragmentadas. Para uma coleção ou visualização, o namespace inclui o nome do banco de dados, o separador de ponto (.
) e o nome da coleção/visualização (por exemplo, <database>.<collection>
).
Antes de fazer o downgrade, resolva quaisquer collections ou visualizações com namespaces que excedam o limite de comprimento do namespace de 120 bytes para a versão de compatibilidade de recursos (fCV) 4.2.
Para determinar se você tem alguma collection ou visualização com namespace que excedem o limite de 120 bytes, conecte o shell mongo
ao primário e execute:
db.adminCommand("listDatabases").databases.forEach(function(d){ let mdb = db.getSiblingDB(d.name); mdb.getCollectionInfos( ).forEach(function(c){ namespace = d.name + "." + c.name namespacelenBytes = encodeURIComponent(namespace).length if (namespacelenBytes > 120) { print (c.type.toUpperCase() + " namespace exceeds 120 bytes:: " + namespace ) } } ) })
Se algum namespace de visualização ou collection exceder 120 bytes, antes de fazer o downgrade do FCV:
Renomeie a collection usando o comando
renameCollection
.Para visualizações, use
db.createView()
para recriar a visualização usando um nome mais curto e, em seguida, solte a visualização original.
2. Downgrade versão de compatibilidade do recurso (FCV)
Dica
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.Garanta que nenhum membro do conjunto de réplicas esteja no estado
ROLLBACK
ouRECOVERING
.Downgradeing to featureCompatibilityVersion (FCV): "4.2" executa implicitamente um
replSetReconfig
para remover o campoterm
do documento de configuração e bloqueia até que a nova configuração se propague para a maioria dos membros do conjunto de réplicas.
Para fazer downgrade do featureCompatibilityVersion
do seu conjunto de réplicas:
Conecte um shell
mongo
ao primary.Faça o downgrade de
featureCompatibilityVersion
para"4.2"
.db.adminCommand({setFeatureCompatibilityVersion: "4.2"}) 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.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 ofeatureCompatibilityVersion
:db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) Todos os membros devem retornar um resultado que inclua:
"featureCompatibilityVersion" : { "version" : "4.2" } Se algum membro retornar uma
featureCompatibilityVersion
de"4.4"
, aguarde até que o membro reflita a versão"4.2"
antes de prosseguir.
Para obter mais informações sobre o valor featureCompatibilityVersion
retornado, consulte Obter FeatureCompatibilityVersion.
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 árbitro em um cluster do MongoDB 4.4 tem um valor FCV de 4.2.
3. Remover as funcionalidades persistentes do FCV 4.4
As etapas a seguir serão necessárias somente se fCV tiver sido definido como "4.4"
.
Remova todas as funcionalidades persistentes do 4.4 que são incompatíveis com o 4.2. Esses incluem:
- Índices compostos com hash
Remova todos os índices compostos com hash.
Use
db.collection.getIndexes()
para identificar qualquer índice composto com hash em uma collection e usedb.collection.dropIndex()
para remover esses índices.
4. Remover os Recursos 4.4
Remova todas as feições persistentes que utilizam feições do 4.4. Isso inclui, mas não está limitado a:
Se houver definições de visualização que incluam operadores 4.4, como
$unionWith
ou$function
. Consulte também Novos Operadores de Agregação.
Procedimento
Aviso
Antes de prosseguir com o procedimento de downgrade, certifique-se de que todos os membros do conjunto de réplicas, incluindo os membros do conjunto de réplicas atrasadas, refletem 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.2 mais recentes.
Utilizando um gerenciador de pacotes ou um download manual, obtenha a versão mais recente na série 4.2. Se estiver usando um gerenciador de pacotes, adicione um novo repositório para os binários 4.2 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 4.4, faça o downgrade para a versão de correção mais recente do 4.2.
Faça downgrade dos membros secundários do conjunto de réplicas.
Faça o downgrade de cada membro secundário do conjunto de réplicas, um de cada vez:
Execute o seguinte comando 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 4.4 pelo binário 4.2 e reinicie.
Aguarde até que o membro se recupere para o estado
SECONDARY
antes de fazer downgrade do próximo secundário. Para verificar o estado do membro, use o métodors.status()
no shellmongo
.Quando o membro estiver no estágio
SECONDARY
, faça downgrade do próximo secundário.
Faça downgrade do membro do conjunto de réplicas de árbitros, se houver.
Pule esta etapa se o conjunto de réplicas não incluir um árbitro.
Faça downgrade do membro árbitro do conjunto de réplicas:
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 4.4 pelo binário 4.2 e reinicie.
Aguarde o membro se recuperar para o estado
ARBITER
. Para verificar o estado do membro, conecte um shellmongo
ao membro e execute o métodors.status()
.
Rebaixe o primário.
Use rs.stepDown()
no shell mongo
para reduzir o primário e forçar o procedimento normal de failover .
rs.stepDown()
rs.stepDown()
agiliza o procedimento de failover e é preferível desligar o primário diretamente.
Substituir e reiniciar o antigo primary mongod
.
Quando rs.status()
mostra que o primário foi desativado e outro membro assume o estado PRIMARY
:
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
mongod
pelo binário 4.2 e reinicie.