Atualizar um cluster fragmentado para 7.0
Nesta página
Use este tutorial para atualizar do MongoDB 6.0 para o MongoDB 7.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 com o MongoDB 7.0.
As etapas a seguir descrevem o procedimento de upgrade de um mongod
que é um membro do shard da versão 6.0 para a 7.0.
Se você precisar de orientação sobre como atualizar para a versão 7.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.
Recomendações de upgrade e listas de verificação
Ao atualizar, considere o seguinte:
Atualizar caminho da versão
Para atualizar uma implantação MongoDB existente para 7.0, você deve estar executando uma versão da série 6.0.
Para atualizar de uma versão anterior à série 6.0, é preciso atualizar sucessivamente as principais versões até fazer o upgrade para a série 6.0. Por exemplo, se estiver executando a série 5.0, você deve atualizar para a 6.0 antes de fazer o upgrade para 7.0.
Verifique a compatibilidade do driver
Antes de fazer upgrade do MongoDB, verifique se você está usando um driver compatível com o MongoDB 7.0. Consulte a documentação do driver para seu driver específico para verificar a compatibilidade com o MongoDB 7.0.
As implementações atualizadas que são executadas em drivers incompatíveis podem encontrar comportamentos inesperados ou indefinidos.
Preparação
Antes de iniciar sua atualização, consulte o documento Alterações de compatibilidade no MongoDB 7.0 para garantir que seus aplicativos e sistemas sejam compatíveis com o MongoDB 7.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.
Consideração de rebaixamento
A partir do MongoDB 7.0, você não pode fazer downgrade da versão binária do seu lançamento sem assistência do suporte.
Para saber mais, consulte Downgrade 7.0 para 6.0.
Pré-requisitos
Versão de todos os membros
Para fazer upgrade de um cluster fragmentado para a versão 7.0, todos os nós do cluster deverão ter pelo menos a versão 6.0. O processo de atualização verifica todos os componentes do cluster e produzirá avisos se algum componente estiver executando uma versão anterior à 6.0.
Versão de compatibilidade de recursos
O cluster fragmentado 6.0 deve ter featureCompatibilityVersion
definido como "6.0"
.
Para garantir que todos os nós do cluster fragmentado tenham featureCompatibilityVersion
configurado como "6.0"
, 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" : "6.0" }
.
Para configurar ou atualizar featureCompatibilityVersion
, execute o seguinte comando no mongos
:
db.adminCommand( { setFeatureCompatibilityVersion: "6.0" } )
Para mais informações, consulte setFeatureCompatibilityVersion
.
Estado do membro do conjunto de réplicas
Para fragmentos e servidores de configuração, certifique-se de que nenhum nó do conjunto de réplicas esteja no estado ROLLBACK
ou RECOVERING
.
db.adminCommand( { replSetGetStatus: 1 } )
Faça config
backup do banco de dados
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.
Download 7.0 Binários
Usar o gerenciador de pacotes
Se você instalou o MongoDB a partir dos repositórios MongoDB apt
, yum
, dnf
ou zypper
, deverá atualizar para a versão 7.0 utilizando seu gerenciador de pacotes.
Siga as instruções de instalação do 7.0 apropriado 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 real.
Baixe manualmente os binários 7.0
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 da versão 7.0 para obter mais informações.
Procedimento de atualização
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.
Atualize os servidores de configuração.
Atualize os nós secundários do conjunto de réplicas, um de cada vez.
Desligue a instância secundária.
Para desligar o processo do
mongod
, utilizemongosh
para se conectar ao membro do cluster e execute o seguinte comando:db.adminCommand( { shutdown: 1 } ) Substitua o 6.0 binário pelo 7.0 binário.
Iniciar o binário 7.0.
Inicie o binário 7.0 com
--configsvr
,--replSet
e--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
enet.bindIp
e, em seguida, inicie o 7.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.
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, emita
rs.status()
emmongosh
.Repita para cada membro secundário.
Reduza o conjunto de réplicas primário.
Rebaixe 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() Encerrar o primário de redução
Quando
rs.status()
mostrar que o primário foi desativado e outro nó assumiu o estadoPRIMARY
, encerre o primário desativado.Para encerrar o primário desativado, utilize
mongosh
para se conectar ao primário e executar o seguinte comando:db.adminCommand( { shutdown: 1 } ) Substitua o binário
mongod
pelo binário 7.0 .Iniciar o binário 7.0.
Inicie o 7.0 com as opções
--configsvr
,--replSet
,--port
e--bind_ip
. Inclua quaisquer opções de linha de comando opcionais utilizadas 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
enet.bindIp
e, em seguida, inicie o 7.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.
Atualize os fragmentos.
Atualize os fragmentos um de cada vez.
Para cada conjunto de réplicas do fragmento:
Atualize os nós secundários do conjunto de réplicas, um de cada vez.
Desligue a instância secundária.
Para desligar o processo do
mongod
, utilizemongosh
para se conectar ao membro do cluster e execute o seguinte comando:db.adminCommand( { shutdown: 1 } ) Substitua o 6.0 binário pelo 7.0 binário.
Inicie o binário 7.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
enet.bindIp
, então inicie o binário 7.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.
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()
emmongosh
.Repita para cada membro secundário.
Reduza o conjunto de réplicas 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() Atualize o primário desativado.
Quando
rs.status()
mostrar que o primário foi desativado e outro membro assumiu o estadoPRIMARY
, faça upgrade do primário desativado:Encerrar o primário de redução
Para encerrar o primário desativado, utilize
mongosh
para conectar ao membro do conjunto de réplicas e executar o seguinte comando:db.adminCommand( { shutdown: 1 } ) Substitua o binário
mongod
. com o binário 7.0 .Iniciar o binário 7.0.
Inicie o binário 7.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
enet.bindIp
e, em seguida, inicie o 7.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.
Atualize as mongos
instâncias de.
Substitua cada instância mongos
pelo 7.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>
Reabilitar o balanceador.
Utilizando mongosh
, conecte-se a um mongos
no cluster e execute sh.startBalancer()
para reativar o balanceador:
sh.startBalancer()
Para obter mais informações sobre como reativar o balanceador, consulte a página Habilitar o balanceador.
Habilite recursos 7.0 incompatíveis com versões anteriores.
Neste ponto, você pode executar o 7.0 binários sem os recursos recursos do 7.0 que são incompatíveis com 6.0.
Para habilitar esses recursos da versão 7.0, defina a versão de compatibilidade do recurso (fCV
) como 7.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: "7.0", confirm: true } )
Definindo featureCompatibilityVersion (fCV) : "7.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 7.0. O processo de limpeza:
Não bloqueia a conclusão da atualização e
Tem limitação de taxa. Para mitigar o possível efeito no desempenho durante a limpeza de documentos órfãos, consulte Ajuste de desempenho de exclusão de intervalo.
Aviso
Compatibilidade mongos fCV
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, não é possível conectar uma versão mongos
do MongoDB 6.0 a um cluster fragmentado 7.0 com fCV definido como 7.0. No entanto, você pode conectar um mongos
de versão MongoDB 6.0 a um cluster fragmentado 7.0 com fCV definido como 6.0.
Procedimentos de atualização adicionais
Para atualizar um standalone, consulte a página Atualizar um standalone para a versão 7.0.
Para atualizar um conjunto de réplicas, consulte Atualizar um conjunto de réplicas para 7.0.