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

Atualizar um cluster fragmentado para 5.0

Nesta página

  • Recomendações de upgrade e listas de verificação
  • Pré-requisitos
  • Baixar binários 5.0
  • Processo de atualização
  • Procedimentos de atualização adicionais

Use este tutorial para atualizar do MongoDB 4.4 para o MongoDB 5.0. Para atualizar para uma nova versão de patch dentro da mesma série de lançamentos, consulte Atualizar para a versão de patch autogerenciada mais recente do MongoDB.

Familiarize-se com o conteúdo deste documento, incluindo a revisão minuciosa dos pré-requisitos, antes de atualizar para MongoDB 5.0.

As etapas a seguir descrevem o procedimento de atualização de um mongod que é um membro do shard da versão 4.4 para a 5.0.

Se você precisar de orientação sobre como atualizar para a versão 5.0, os serviços profissionais do MongoDB oferecem suporte de atualização da versão principal para ajudar a garantir uma transição tranquila, sem interrupção para seu aplicativo MongoDB.

Ao atualizar, considere o seguinte:

Para atualizar uma implantação MongoDB existente para 5,0, você deve estar executando uma versão da série 4,4.

Para atualizar de uma versão anterior à série 4.4, você deve atualizar sucessivamente as principais versões até que você tenha atualizado para a série 4.4. Por exemplo, se estiver executando uma série 4.2, você deverá atualizar primeiro para 4.4 antes de atualizar para 5.0.

Antes de fazer upgrade do MongoDB, verifique se você está usando um driver compatível com o MongoDB 5.0. Consulte a documentação do driver para seu driver específico para verificar a compatibilidade com o MongoDB 5.0.

As implementações atualizadas que são executadas em drivers incompatíveis podem encontrar comportamentos inesperados ou indefinidos.

Antes de iniciar sua atualização, consulte o documento Alterações de compatibilidade no MongoDB 5.0 para garantir que seus aplicativos e implantações sejam compatíveis com o MongoDB 5.0. Resolva as incompatibilidades em sua implantação antes de iniciar a atualização.

Antes de atualizar o MongoDB, sempre teste seu aplicativo em um ambiente de preparação antes de implantar a atualização em seu ambiente de produção.

Você não pode fazer downgrade da versão binária do seu sistema sem assistência do suporte.

Para saber mais, consulte Downgrade 8.0 para 7.0.

Antes de atualizar seu cluster fragmentado, verifique o Considerações de desempenho da 5.0 para quaisquer impactos potenciais no desempenho ao atualizar para 5.0.

Verifique se a configuração de TTL é válida. Antes de atualizar, remova ou corrija quaisquer índices TTL que tenham o expireAfterSeconds configurado para NaN. No MongoDB 5.0 e posterior, a configuração expireAfterSeconds para NaN tem o mesmo efeito que a configuração expireAfterSeconds para 0. Para obter detalhes, consulte Comportamento do expireAfterSeconds TTL quando definido como NaN.

Para fazer upgrade de um cluster fragmentado para a versão 5.0, todos os nós do cluster deverão ter pelo menos a versão 4.4. O processo de atualização verifica todos os componentes do cluster e produzirá avisos se algum componente estiver executando uma versão anterior à 4.4.

Antes de atualizar um nó do cluster fragmentado, confirme se o nó foi desligado corretamente.

O cluster fragmentado 4.4 deve ter featureCompatibilityVersion definido como "4.4".

Para garantir que todos os nós do cluster fragmentado tenham featureCompatibilityVersion configurado como "4.4", conecte-se a cada nó do conjunto de réplicas do fragmento e a cada nó do conjunto de réplicas do servidor de configuração e marque a opção featureCompatibilityVersion:

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

Para configurar ou atualizar featureCompatibilityVersion, execute o seguinte comando no mongos:

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

Para mais informações, consulte setFeatureCompatibilityVersion.

Para fragmentos e servidores de configuração, certifique-se de que nenhum membro do conjunto de réplicas esteja no estado ROLLBACK ou RECOVERING.

Opcional, mas recomendado. Como precaução, faça uma cópia de segurança do banco de dados config antes de atualizar o cluster fragmentado.

Se você instalou o MongoDB a partir dos repositórios MongoDB apt, yum, dnf ou zypper, deve atualizar para a versão 5.0 usando o gerenciador de pacotes.

Siga as instruções de instalação do 5.0 apropriadas para seu sistema Linux. Isso envolverá a adição de um repositório para a nova versão e, em seguida, a execução do processo de atualização atual.

Se você não tiver instalado o MongoDB usando um gerenciador de pacotes, poderá fazer o download manual dos binários do MongoDB no MongoDB Download Center.

Consulte as instruções de instalação do 5.0 para mais informações.

1

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.

2
  1. Atualize os membros secundários da réplicas para definir um de cada vez:

    1. Encerre a instância mongod secundária e substitua o binário 4.4 pelo binário 5.0.

    2. Inicie o binário 5.0 com o --configsvr, --replSete --port. Inclua quaisquer outras opções conforme usado pela implantação.

      mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address>

      Se estiver usando um arquivo de configuração, atualize o arquivo para especificar sharding.clusterRole: configsvr, replication.replSetName, net.port e net.bindIp e, em seguida, inicie o 5.0 binário:

      sharding:
      clusterRole: configsvr
      replication:
      replSetName: <string>
      net:
      port: <port>
      bindIp: localhost,<ip address>
      storage:
      dbpath: <path>

      Inclua quaisquer outras configurações conforme adequado para sua implantação.

    3. Aguarde até que o membro se recupere com o estado SECONDARY antes de atualizar o próximo membro secundário. Para verificar o estado do membro, emita rs.status() em mongosh.

      Repita para cada membro secundário.

  2. Reduza o conjunto de réplicas primário.

    1. Conecte mongosh ao primário e use rs.stepDown() para reduzir o primário e forçar a eleição de um novo primário:

      rs.stepDown()
    2. Quando rs.status() indicar que o primário foi desativado e outro membro tiver assumido o estado PRIMARY, encerre o primário desativado e substitua o binário mongod pelo binário 5.0.

    3. Inicie o binário 5.0 com as opções--configsvr, --replSet --port e opções --bind_ip. Inclua quaisquer opções de linha de comando opcionais usadas pela implantação anterior:

      mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address>

      Se estiver usando um arquivo de configuração, atualize o arquivo para especificar sharding.clusterRole: configsvr, replication.replSetName, net.port e net.bindIp e, em seguida, inicie o 5.0 binário:

      sharding:
      clusterRole: configsvr
      replication:
      replSetName: <string>
      net:
      port: <port>
      bindIp: localhost,<ip address>
      storage:
      dbpath: <path>

      Inclua qualquer outra configuração conforme adequado para sua implantação.

3

Atualize os fragmentos um de cada vez.

Para cada conjunto de réplicas do fragmento:

  1. Atualize os membros secundários da réplicas para definir um de cada vez:

    1. Desligue a instância mongod e substitua o binário 4.4 pelo binário 5.0.

    2. Inicie o binário 5.0 com as opções --shardsvr, --replSet, --port e --bind_ip. Inclua opções de linha de comando adicionais, conforme adequado, para sua implantação:

      mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address>

      Se estiver usando um arquivo de configuração, atualize-o para incluir sharding.clusterRole: shardsvr, replication.replSetName, net.port e net.bindIp, então inicie o binário 5.0 :

      sharding:
      clusterRole: shardsvr
      replication:
      replSetName: <string>
      net:
      port: <port>
      bindIp: localhost,<ip address>
      storage:
      dbpath: <path>

      Inclua qualquer outra configuração conforme adequado para sua implantação.

    3. Aguarde até que o membro se recupere para o estado SECONDARY antes de atualizar o próximo membro secundário. Para verificar o estado do membro, você pode emitir rs.status() em mongosh.

      Repita para cada membro secundário.

  2. Reduza o conjunto de réplicas primário.

    Conecte mongosh ao primário e use rs.stepDown() para reduzir o primário e forçar a eleição de um novo primário:

    rs.stepDown()
  3. Quando rs.status() indicar que o primário foi desativado e outro membro tiver assumido o estado PRIMARY, faça upgrade do primário desativado:

    1. Desligue o principal passo a passo e substitua o binário mongod pelo binário 5,0.

    2. Inicie o binário 5.0 com as opções --shardsvr, --replSet, --port e --bind_ip. Inclua opções de linha de comando adicionais, conforme adequado, para sua implantação:

      mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address>

      Se estiver usando um arquivo de configuração, atualize o arquivo para especificar sharding.clusterRole: shardsvr, replication.replSetName, net.port e net.bindIp e, em seguida, inicie o 5.0 binário:

      sharding:
      clusterRole: shardsvr
      replication:
      replSetName: <string>
      net:
      port: <port>
      bindIp: localhost,<ip address>
      storage:
      dbpath: <path>

      Inclua qualquer outra configuração conforme adequado para sua implantação.

4

Substitua cada instância mongos pelo 5.0 binário e reinicie. Inclua qualquer outra configuração conforme adequado para sua implantação.

Observação

A opção --bind_ip deve ser especificada quando os nós do cluster fragmentado são executados em hosts diferentes ou se clientes remotos se conectarem ao cluster fragmentado.

mongos --configdb csReplSet/<rsconfigsver1:port1>,<rsconfigsver2:port2>,<rsconfigsver3:port3> --bind_ip localhost,<ip address>
5

Utilizando mongosh, conecte-se a um mongos no cluster e execute sh.startBalancer() para reativar o balanceador:

sh.startBalancer()

A partir do MongoDB 6.0.3, a divisão automática de partes não é executada. Isso se deve a melhorias na política de balanceamento. Os comandos de divisão automática ainda existem, mas não executam uma operação.

Nas versões MongoDB anteriores a 6.0.3, o sh.startBalancer() também habilita a divisão automática para o cluster fragmentado.

Se não desejar ativar a divisão automática enquanto o balanceador estiver ativado, você também deverá executar sh.disableAutoSplit().

Para obter mais informações sobre como reativar o balanceador, consulte a página Habilitar o balanceador.

6

Neste ponto, você pode executar os binários do 5.0 sem as feições do 5,0 que são incompatíveis com 4.4.

Para habilitar essas funcionalidades do 5.0, defina feature compatibility version (fCV) para 5.0.

Dica

Habilitar essas recursos funcionalidades com versões anteriores pode complicar o processo de downgrade, pois você deve remover todos as funcionalidades persistentes incompatíveis com versões anteriores antes de fazer o downgrade.

É recomendável que, após a atualização, você permita que seu sistema seja executado sem habilitar essas funcionalidades por um período de burn-in para garantir que a probabilidade de downgrade seja mínima. Quando você estiver confiante de que a probabilidade de downgrade é mínima, habilite essas funcionalidades.

Em uma instância do mongos, execute o comando setFeatureCompatibilityVersion no banco de dados admin:

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

Definindo featureCompatibilityVersion (fCV) : "5.0" executa implicitamente um replSetReconfig em cada shard para adicionar o campo term ao documento de configuração de réplica do shard.

O comando não é concluído até que a nova configuração se propague para a maioria dos membros do conjunto de réplicas.

Esse comando deve executar gravações em uma coleção interna do sistema. Se, por algum motivo, o comando não for concluído com êxito, você poderá tentar novamente o comando no mongos com segurança, pois a operação é idempotente.

Observação

Enquanto setFeatureCompatibilityVersion estiver em execução no cluster fragmentado, migrações, divisões e mesclagens de partes podem apresentar falhas com ConflictingOperationInProgress.

Quaisquer documentos órfãos que existam em seus fragmentos serão limpos quando você definir o setFeatureCompatibilityVersion como 5.0. O processo de limpeza:

Observação

Consideração adicional

O binário mongos não pode se conectar a instâncias mongod cuja versão de compatibilidade do recurso (fCV) seja maior que a do mongos. Por exemplo, você não pode conectar um MongoDB 4.4 versão mongos a um 5.0 cluster fragmentado com fCV definido como 5.0. Entretanto, você pode conectar um MongoDB versão 4.4 mongos a um cluster fragmentado 5.0 com fCV definido como 4.4.

Voltar

Conjunto de réplicas