MongoDB rolling upgrade (7.0 → 8.0): replica set e sharded cluster

Atualiza um replica set ou sharded cluster MongoDB 7.0 em execução para 8.0 sem downtime (rolling): verificações prévias (versão, FCV, estado dos membros, compatibilidade de drivers), backup, primeiro os secondaries, depois stepDown e o antigo primary; no sharded cluster a ordem é parar o balancer, config servers, shards, mongos. O FCV 8.0 pode, opcionalmente, ficar para depois do burn-in; inclui as opções de rollback e seus limites. Para um patch dentro da mesma versão principal (8.0.x → 8.0.y) o repo não muda e a mesma ordem de membros é seguida; quem vem do 6.0 passa primeiro para o 7.0.

Topologia: Replica set (3+ membros) ou sharded cluster (config servers + shards + mongos)

Antes de começar

• Todos os …mongod (membros dos config servers e dos shards) e mongos…membros… executam 7.0.x com FCV 7.0. Se vier do 6.0, atualize primeiro para o 7.0 (não é possível pular uma versão principal).
• Nenhum membro está em ROLLBACK/RECOVERING/STARTUP2; os secondaries estão poucos segundos atrás do primary.
• A janela do oplog é bem maior que o tempo de manutenção (tempo fora do ar por membro), no mínimo várias horas. Se for curta, o membro que ficou parado precisa de initial sync ao voltar.
• Todos os drivers das aplicações estão em versão compatível com o MongoDB 8.0 (tabela de compatibilidade de drivers). Drivers antigos podem não conseguir se conectar ao 8.0 ou não suportar os novos comportamentos.
• A página de mudanças de compatibilidade do 8.0 foi lida; você não usa nenhum recurso removido ou alterado (parâmetro, comando, comportamento de consulta). Se possível, o upgrade foi ensaiado antes em um ambiente de teste.
• Existe um backup recente com restore testado (snapshot ou mongodump). A janela de manutenção está aprovada.
• Cada membro tem espaço livre suficiente no disco de dados e em /var/log, e acesso ao repo do 8.0 (repo.mongodb.org).
• Nos membros dos config servers e dos shards o mongod roda com o serviço systemd mongod e com /etc/mongod.conf; nos servidores mongos o nome do serviço é …. Cada servidor tem um único processo mongod/mongos.
• O balancer pode ser parado durante a janela de upgrade; não há migração de chunks, resharding ou index build em andamento. Nenhuma mudança de shard key ou de metadados de coleções está planejada durante a manutenção.

Fases do guia

• Verificações prévias — Versão, FCV e papel (todos os …mongod…membros…) · Estado dos membros e atraso de replicação · Estado do cluster, shards e balancer · Coleções system.buckets inválidas · Verificação de drivers e compatibilidade · Backup e ponto de retorno …
• Troca de repo (todos os membros) — Adicionar o repo do 8.0, desativar o repo do 7.0 · Adicionar o repo do 8.0, desativar o repo do 7.0
• Atualizar os secondaries um de cada vez — Secondary: verificar que … não é primary e pará-lo · Secondary: instalar os binários 8.0 em … · Secondary: ajustar o THP para o 8.0 em … · Secondary: iniciar … e aguardar SECONDARY · Secondary: verificar que … não é primary e pará-lo · Secondary: instalar os binários 8.0 em … …
• Rebaixar e atualizar o primary — Verificar que os secondaries estão no 8.0 e saudáveis · Rebaixar o primary (stepDown) · Antigo primary: verificar que … não é primary e pará-lo · Antigo primary: instalar os binários 8.0 em … · Antigo primary: ajustar o THP para o 8.0 em … · Antigo primary: iniciar … e aguardar SECONDARY
• Parar o balancer — Parar o balancer e verificar que as migrações terminaram
• Ligar o balancer e verificar as versões — Verificar que todos os componentes estão no 8.0 · Ligar o balancer novamente
• Verificação — Todos os membros no 8.0 · Verificação da aplicação e dos logs
• featureCompatibilityVersion 8.0 — Elevar o FCV para 8.0 · Verificar o FCV
• Rollback (só em caso de problema) — Escolher o caminho de rollback · Voltar os binários para o 7.0: … · Restaurar o backup · Ordem de rollback no sharded cluster