Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ / /

Downgrade do conjunto de réplicas 5.0 para 4.4

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

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

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:

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 write concern 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 ou replication.enableMajorityReadConcern: false depois de fazer o downgrade.

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.

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.

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

  • Garanta que nenhum membro do conjunto de réplicas esteja no estado ROLLBACK ou RECOVERING.

Em seguida, para fazer o featureCompatibilityVersion do seu conjunto de réplicas:

  1. Conecte um shell mongo ao primary.

  2. Faça o downgrade de featureCompatibilityVersion para "4.4".

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

    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.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. Por esse motivo, os arbiters sempre têm uma versão de compatibilidade do recurso igual à versão de downgrade do binário, independentemente do valor FCV do conjunto de admin.system.version réplicas.

Por exemplo, um árbitro 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.

As etapas a seguir serão necessárias somente se o 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

  • Redefina os padrões no servidor primário no grupo com db.admin.runCommand. O primário deve ser o último servidor de configuração do grupo a ser atualizado.

    db.admin.runCommand(
    {
    setAuditConfig: 1,
    filter: {},
    auditAuthorizationSuccess: false
    }
    )

    O documento de configuração também pode ser removido após o downgrade:

    config.settings.remove({_id: 'audit'});
  • Desative o Gerenciamento de Filtros de Auditoria do Runtime em cada nó definindo auditLog.runtimeConfiguration como false no arquivo de configuração do nó.

  • Atualize os filtros de auditoria para esta instância no arquivo de configuração local.

Remova todas as feições persistentes que utilizam feições do 5.0. 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.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.

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

  3. Aguarde até que o membro se recupere para o estado SECONDARY antes de fazer o downgrade do próximo secundário. Para verificar o estado do membro, use o método rs.status() em mongosh.

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

  4. Aguarde até que o membro se recupere para o estado ARBITER . Para verificar o estado do membro, conecte mongosh ao membro e execute o método rs.status() .

4

Use rs.stepDown() em mongosh para reduzir o primário e forçar o procedimento de failover normal.

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.4 e reinicie.

Voltar

Autônomo