Operação diária e cenários de falha do MongoDB (replica set e sharded cluster)

Não é uma instalação: runbook por cenários para administrar no dia a dia um replica set e um sharded cluster MongoDB já instalados e recuperá-los quando quebram. Verificação de saúde, adição/remoção de membros, membro priority/hidden/delayed, substituição do arbiter por um membro com dados, ressincronização de um membro atrasado, force reconfig após perda da maioria, stepDown planejado, tamanho do oplog, FCV; adição/remoção de shards, balancer, jumbo chunk e reshardCollection. Se você não sabe o que fazer, comece pela verificação de saúde; restauração de backup, configurações de segurança e upgrade de versão principal estão em guias MongoDB separados.

Topologia: Replica set (3+ membros) ou sharded cluster (config server + replica sets dos shards + mongos)

Cenários

• Verificação de saúde: membros, atraso, janela do oplog (no sharded, shards e balancer) — Somente leitura: estados dos membros, atraso de replicação, janela do oplog, configuração; no sharded cluster, lista de shards, balancer e distribuição de chunks. Se você não tem certeza do que fazer, comece por aqui.
• Adicionar um novo membro ao replica set (initial sync) — Um novo servidor foi preparado (mesma versão, keyfile, replSetName); ele é adicionado com priority 0 / votes 0 e recebe voto e priority quando o initial sync termina e ele fica SECONDARY. Sem downtime.
• Remover o membro do replica set — O servidor está sendo desativado ou foi perdido de forma definitiva: o membro é removido da configuração e verifica-se que os votos restantes ainda formam maioria. Se for o primary, faça stepDown antes.
• Alterar o papel do membro: priority, hidden, delayed (com atraso) — Alterar a prioridade de um membro para se tornar primary, torná-lo um membro oculto (hidden) para relatórios/backup ou um membro com atraso (delayed) como proteção contra exclusões acidentais, ou voltá-lo ao normal.
• Substituir o arbiter por um membro com dados (PSA → PSS) — Replica set com primary + secondary + arbiter: quando um membro com dados cai, as escritas majority e a pressão no cache viram problema. Um novo membro com dados é adicionado e o arbiter é removido.
• Ressincronizar um membro atrasado ou corrompido (resync) — O membro está preso em RECOVERING e informa 'too stale to catch up', ou os arquivos de dados estão corrompidos: o diretório de dados do membro é esvaziado e ele é ressincronizado do zero com initial sync. Os outros membros continuam funcionando.
• Perda da maioria: reconfigurar à força com os membros restantes (force reconfig) — A maioria dos membros foi perdida de forma definitiva (perda de site/servidor) e os restantes não conseguem eleger um primary: rs.reconfig(cfg, {force: true}) com os membros restantes. Último recurso; usado de forma errada, há risco de perda de dados e split brain.
• Troca planejada do primary (rs.stepDown, tornar um membro específico primary) — Haverá manutenção/patch no servidor primary: o primary se retira e um secondary sincronizado se torna primary. A aplicação pode receber erros de escrita por alguns segundos.
• Alterar o tamanho do oplog (replSetResizeOplog) — A janela do oplog é curta: os secondaries ficam 'too stale' após manutenção, o backup não consegue capturar o oplog ou ela não basta para recuperação point-in-time. O oplog é aumentado em cada membro, sem downtime.
• Verificar e concluir a Feature Compatibility Version (FCV) — Após o upgrade, a FCV ficou na versão antiga ou há diferença de versão entre os membros: a versão do binário e a FCV de todos os membros são verificadas e a FCV é elevada para a nova versão.
• Adicionar um shard ao cluster (sh.addShard) — A capacidade não é suficiente: um novo replica set de shard (shardsvr) foi montado e é adicionado ao cluster; o balancer move os chunks gradualmente.
• Remover um shard (removeShard: drain e movePrimary) — Um shard está sendo desativado: seus chunks são esvaziados para os outros shards (drain), os bancos de dados dos quais ele é o primary shard são movidos (movePrimary) e depois ele é removido do cluster.
• Balancer: janela de horário, parar / iniciar, desativar por collection — As migrações de chunks geram carga no horário de pico, as migrações precisam parar para manutenção/backup ou uma única collection não deve ser balanceada.
• Distribuição desbalanceada ou jumbo chunk (diagnóstico e solução) — Um shard está muito mais cheio que os outros, o balancer não move chunks, há chunks marcados como 'jumbo' ou o moveChunk falha: a distribuição, os jumbo chunks e os erros do balancer são analisados.
• Alterar a shard key (reshardCollection) — A shard key atual gera shard quente, jumbo chunks ou consultas scatter-gather: a collection é redistribuída online com a nova shard key (5.0+). No final, as escritas ficam bloqueadas por ~2 s.

Antes de começar

• O mongosh está instalado no servidor de gerenciamento, que tem resolução de nomes e acesso à porta …do mongos (…)…de todos os membros (…)…. Os nomes na conexão devem ser iguais aos nomes dos membros em rs.conf().
• Você tem a senha do usuário …; o papel dele é root ou no mínimo clusterAdmin + readAnyDatabase.… Ao conectar diretamente a um replica set de shard ou de config server, é necessário o administrador local do shard (criado no guia mongo-sharded).…
• Foi aberto o registro de mudança / janela de manutenção e a equipe da aplicação foi informada. Reconfig, stepDown e operações de shard podem causar uma eleição (election) ou atraso de roteamento de alguns segundos.
• O novo membro … foi preparado com as fases de sistema operacional, instalação, keyfile e configuração do guia de instalação do replica set: mesma versão do MongoDB (…), mesmo keyfile, replication.replSetName: …, mongod em execução mas rs.initiate NÃO executado. Há resolução de nomes e acesso às portas nos dois sentidos com os outros membros; o disco de dados tem espaço livre pelo menos igual aos dados atuais.
• Durante o initial sync, todos os dados são regravados no disco do membro…; como o diretório antigo é movido para o lado, é necessário espaço livre de duas vezes o tamanho dos dados…. Os membros restantes mantêm a maioria, e a janela do oplog do membro de origem é mais longa do que o tempo que o initial sync vai levar.

Fases do guia

• Estado: membros, atraso e oplog (somente leitura) — Mostrar o estado e o atraso dos membros · Mostrar a configuração (priority, votes, hidden, delay) · Interpretar o resultado e escolher o cenário certo
• Estado: shards, balancer e distribuição de chunks (somente leitura) — Mostrar o resumo do cluster · Distribuição de chunks e jumbo chunks · Verificar o estado dos replica sets dos shards
• 1. Diagnóstico: o novo membro está pronto? — Verificar o serviço e a versão do novo membro · Ver o estado do set atual e o tamanho dos dados · Validar o acesso ao novo membro
• 2. Rede de segurança — Salvar a configuração atual do replica set
• 3. Aplicação: adicionar o membro e aguardar a sincronização — Adicionar o membro com priority 0 / votes 0 · Aguardar o término do initial sync · Dar voto e priority ao membro
• 4. Verificação e acompanhamento — Verificar o estado · Atualizar a connection string da aplicação e o monitoramento
• 1. Diagnóstico: o membro a remover é o primary? A maioria se mantém? — Calcular o papel do membro e o número de votos restantes
• 2. Rede de segurança — Salvar a configuração atual do replica set
• 3. Aplicação: remover o membro — Remover o membro da configuração (rs.remove) · Parar o mongod no servidor removido
• 4. Verificação e acompanhamento — Verificar o estado · Atualizar as connection strings, o monitoramento e o firewall
• 1. Diagnóstico — Ver as configurações atuais do membro e a janela do oplog
• 2. Rede de segurança — Salvar a configuração atual do replica set
• 3. Aplicação — Alterar a configuração do membro (rs.reconfig)
• 4. Verificação — Verificar o resultado
• 1. Diagnóstico: arbiter e novo membro — Ver o arbiter e o write concern · Validar que o novo membro está pronto
• 2. Rede de segurança — Salvar a configuração atual do replica set
• 3. Aplicação: adicionar o membro com dados, remover o arbiter — Adicionar o novo membro com priority 0 / votes 0 · Aguardar o término do initial sync · Dar voto e priority ao novo membro · Remover o arbiter · Parar o mongod no servidor do arbiter
• 4. Verificação e acompanhamento — Verificar o estado e o write concern
• 1. Diagnóstico: o membro realmente precisa ser ressincronizado? — Ver o estado e a última mensagem do membro · Ver o erro no log do membro
• 2. Rede de segurança — Salvar a configuração atual do replica set
• 3. Aplicação: esvaziar o diretório de dados e executar o initial sync — Parar o mongod · …Mover o diretório de dados para o lado…Esvaziar o diretório de dados… · Iniciar o mongod (o initial sync começa) · Aguardar o término do initial sync
• 4. Verificação e acompanhamento — Verificar o estado · Excluir o diretório de dados antigo
• 1. Diagnóstico: a maioria foi realmente perdida de forma definitiva? — Ver o estado e os optimes a partir de um membro restante · Validar que os membros perdidos estão desligados
• 2. Rede de segurança — Salvar a configuração do membro restante
• 3. Aplicação: force reconfig — Reconfigurar à força apenas com os membros restantes · Validar que um primary foi eleito
• 4. Verificação e acompanhamento — Testar uma escrita majority · Readicionar os membros perdidos e eliminar a causa raiz
• 1. Diagnóstico: os secondaries estão sincronizados? — Ver o primary e os atrasos
• 2. Aplicação — Congelar os outros secondaries (para que o membro alvo seja eleito) · Retirar o primary (rs.stepDown)
• 3. Verificação — Verificar o novo estado
• 1. Diagnóstico: tamanho e janela atuais do oplog — Tamanho e janela do oplog em cada membro