Menu Docs

Página inicial do DocsDesenvolver aplicaçõesManual do MongoDB

Faça o downgrade de 4.4 Conjunto de Réplicas como 4.2

Nesta página

  • Caminho de downgrade
  • Criar cópia de segurança
  • Controle de acesso
  • 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 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 downgrade de um 4.4- série a 4. Sistema 2-série. No entanto, desatualizando ainda mais 4.2sistema -série em um 4.0-series não é suportada.

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.

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

Se o seu conjunto de réplicas tiver o controle de acesso habilitado, o privilégio de downgrade de usuário deverá incluir privilégio para managed índices em reconhecimento de data center. Um usuário com role root tem os privilégios necessários.

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.

Começando no MongoDB 4.4:

O limite de comprimento do namespace para collection e visualizações não fragmentadas é de 255 bytes e 235 bytes para collection fragmentadas. Para uma collection ou visualização, o namespace inclui o nome do banco de dados, o separador do ponto (.) e o nome da collection/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.

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 ou RECOVERING.

  • Downgradeing to featureCompatibilityVersion (FCV): "4.2" executa implicitamente um replSetReconfig para remover o campo term 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:

  1. Conecte um shell mongo ao primary.

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

  3. 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 o featureCompatibilityVersion:

    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.

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 use db.collection.dropIndex() para remover esses índices.

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

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.

1

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.

2

Faça o downgrade de cada membro secundário do conjunto de réplicas, um de cada vez:

  1. Execute o seguinte comando 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 4.4 pelo binário 4.2 e reinicie.

  3. 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étodo rs.status() no shell mongo .

  4. Quando o membro estiver no estágio SECONDARY , faça downgrade do próximo secundário.

3

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:

  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 4.4 pelo binário 4.2 e reinicie.

  4. Aguarde o membro se recuperar para o estado ARBITER . Para verificar o estado do membro, conecte um shell mongo ao membro e execute o método rs.status() .

4

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.

5

Quando rs.status() mostra que o primário foi desativado e outro membro assume o estado PRIMARY :

  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 mongod pelo binário 4.2 e reinicie.

← Faça o downgrade de 4.4 autônomo para 4.2