Atualizar um cluster fragmentado para 6.0
Nesta página
Aviso
Devido àsatualizações da política de 6.0.3 de no MongoDB , o balanceador pode iniciar imediatamente após a atualização, mesmo que o número de blocos permaneça o mesmo.
Familiarize-se com o conteúdo deste documento, incluindo a revisão minuciosa dos pré-requisitos, antes de atualizar para MongoDB 6.0.
As etapas a seguir descrevem o procedimento de upgrade de um mongod
que é um membro do shard da versão 5.0 para a 6.0.
Se você precisar de orientação sobre como atualizar para a versão 6.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 6,0, você deve estar executando uma versão da série 5,0.
Para atualizar de uma versão anterior à série 5.0, você deve atualizar sucessivamente as principais versões até ter atualizado para a série 5.0. Por exemplo, se você estiver executando uma série 4.4, deverá atualizar primeiro para a série 5.0 antes de poder atualizar para a 6.0.
Verifique a compatibilidade do driver
Antes de fazer upgrade do MongoDB, verifique se você está usando um driver compatível com o MongoDB 6.0. Consulte a documentação do driver para seu driver específico para verificar a compatibilidade com o MongoDB 6.0.
As implementações atualizadas que são executadas em drivers incompatíveis podem encontrar comportamentos inesperados ou indefinidos.
Aviso
Se seus drivers usam opcodes legados que foram preteridos na v3.6, atualize seus drivers para uma versão que use opcodes compatíveis. Drivers que usam opcodes legados não são mais suportados.
Preparação
Antes de iniciar sua atualização, consulte o documento Alterações de compatibilidade no MongoDB 6.0 para garantir que seus aplicativos e sistemas sejam compatíveis com o MongoDB 6.0. Resolva as incompatibilidades em seus sistema 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
Após atualizar para o 6.0, se você precisar fazer o downgrade, recomendamos fazer o downgrade para a versão de correção mais recente do 5.0.
Pré-requisitos
Versão de todos os membros
Para fazer upgrade de um cluster fragmentado para a versão 6.0, todos os nós do cluster deverão ter pelo menos a versão 5.0. O processo de atualização verifica todos os componentes do cluster e produzirá avisos se algum componente estiver executando uma versão anterior à 5.0.
Versão de compatibilidade de recursos
O cluster fragmentado 5.0 deve ter featureCompatibilityVersion
definido como "5.0"
.
Para garantir que todos os nós do cluster fragmentado tenham featureCompatibilityVersion
configurado como "5.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" : "5.0" }
.
Para configurar ou atualizar featureCompatibilityVersion
, execute o seguinte comando no mongos
:
db.adminCommand( { setFeatureCompatibilityVersion: "5.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
.
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.
Baixe binários 6.0
Usar o gerenciador de pacotes
Se você instalou MongoDB a partir dos repositórios MongoDB apt
, yum
, dnf
ou zypper
, você deverá atualizar para 6.0 utilizando seu gerenciador de pacote.
Siga as instruções de instalação do 6.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 real.
Baixe manualmente os binários 6.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 do 6.0 para mais informações.
Procedimento de atualização
Aviso
Se você atualizar uma instância existente do MongoDB para o MongoDB 6.0.5, essa instância poderá falhar ao iniciar se fork: true
estiver definido no arquivo mongod.conf
.
O problema de atualização afeta todas as instâncias MongoDB que utilizam pacotes de instalação do .deb
ou .rpm
. As instalações que usam a versão tarball (.tgz
) ou outros tipos de pacote não são afetadas. Para obter mais informações, consulte SERVER-74345.
Para remover a configuração fork: true
, execute estes comandos a partir de um terminal do sistema:
systemctl stop mongod.service sed -i.bak '/fork: true/d' /etc/mongod.conf systemctl start mongod.service
O segundo comando systemctl
inicia a instância atualizada após a configuração ser removida.
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 a tabela de roteamento em cache para cada mongos
.
Para cada mongos
no cluster, conecte mongosh
à instância mongos
e execute flushRouterConfig
para atualizar a tabela de roteamento em cache:
db.adminCommand("flushRouterConfig") db.adminCommand( { flushRouterConfig: 1 } )
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 binário 5.0 pelo binário 6.0.
Iniciar o binário 6.0.
Inicie o binário 6.0 com o
--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 binário 6.0: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 6.0 .Iniciar o binário 6.0.
Inicie o 6.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 binário 6.0: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 de shard, atualize os membros 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 binário 5.0 pelo binário 6.0.
Inicie o binário 6.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 6.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
pelo binário 6.0 .Iniciar o binário 6.0.
Inicie o binário 6.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 binário 6.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.
Atualize as mongos
instâncias de.
Substitua cada instância mongos
pelo 6.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()
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. Para obter detalhes, consulte Alterações na política de balanceamento.
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.
Ative recursos 6.0 incompatíveis com versões anteriores.
Neste ponto, você pode executar os binários do 6.0 sem as funcionalidades do 6.0 que são incompatíveis com 5.0.
Para habilitar estes recursos do 6.0, defina a versão de compatibilidade de recursos (fCV
) para 6.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: "6.0" } )
Definindo featureCompatibilityVersion (fCV) : "6.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 6.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.
Observação
Consideração adicional
O binário mongos
falhará ao tentar se conectar a instâncias mongod
cuja versão de compatibilidade do recurso (FCV) é maior que a do mongos
. Por exemplo, você não pode conectar um MongoDB 5.0 versão mongos
a um cluster fragmentado 6.0 com FCV definido como 6.0. No entanto, você pode conectar um MongoDB 5.0 versão mongos
a um cluster fragmentado 6.0 com FCV definido como 5.0.
Procedimentos de atualização adicionais
Para atualizar um standalone, consulte Atualizar um standalone para 6.0.
Para atualizar um conjunto de réplicas, consulte Atualizar um conjunto de réplicas para 6.0.