Alta Disponibilidade e Replicação

Olá, dev! Seja bem-vindo ao Dia 12 da sua preparação para a certificação MongoDB Associate Developer. Hoje nos aprofundaremos na espinha dorsal da resiliência do MongoDB: os Replica Sets, o funcionamento interno do log de operações (oplog), regras de quorum de eleição e como controlar o roteamento de consultas com Read Preferences.

1. Arquitetura de um Replica Set

Um Replica Set é um cluster composto por múltiplos processos mongod que mantêm o mesmo conjunto de dados sincronizado. Seu propósito principal é prover redundância de dados, alta disponibilidade (HA) e recuperação automática contra falhas de hardware.

• Nó Primário (Primary): O único nó do conjunto que recebe operações de escrita. Ele grava as alterações em seus arquivos de dados e registra as operações no oplog. Em qualquer instante, pode haver no máximo um Primary ativo.
• Nós Secundários (Secondaries): Replicam as operações do Primary de forma assíncrona lendo e aplicando o oplog. Mantêm cópias idênticas dos dados e participam de eleições para se tornarem o novo Primary caso o líder atual fique indisponível.

2. Configurações Especiais de Membros Secundários

O MongoDB permite configurar membros secundários para atender funções operacionais especializadas:

• Priority 0 (priority: 0): Membro que não pode se tornar Primary sob nenhuma circunstância. Útil para nós em datacenters remotos ou servidores dedicados exclusivamente a leitura de analytics. Continua votando em eleições.
• Hidden Member (hidden: true): Membro invisível para os drivers das aplicações clientes (o driver nunca envia consultas para ele). Deve obrigatoriamente ter priority: 0. Ideal para extração de relatórios analíticos pesados ou rotinas de backup isoladas.
• Delayed Member (secondaryDelaySecs: <segundos>): Mantém uma cópia dos dados com atraso programado (ex: 3600 segundos = 1 hora). Deve ser priority: 0 e hidden: true. Serve como proteção contra desastres humanos (ex: um comando drop() acidental pode ser revertido antes que o delay expire).
• Arbiter: Não armazena dados e não possui oplog. Participa apenas de eleições para desempate de votos. (A documentação oficial desencoraja seu uso em produção, preferindo nós de dados reais).

3. O Mecanismo do `oplog` (Operations Log)

O oplog.rs é uma capped collection (coleção circular de tamanho fixo) localizada no banco de dados reservado local.

• Idempotência: Todas as operações registradas no oplog são transformadas em operações idempotentes. Por exemplo, uma atualização { $inc: { views: 1 } } é registrada no oplog como { $set: { views: 42 } }, garantindo que aplicar a mesma entrada múltiplas vezes resulte exatamente no mesmo estado final.
• Replication Lag (Atraso de Replicação): É a diferença de tempo entre a última operação registrada no Primary e a última aplicada pelo Secondary. Se o volume de escrita for tão alto que o oplog sobrescreva dados antes que um Secondary consiga ler, esse Secondary entrará no estado RECOVERING e exigirá uma ressincronização inicial (Initial Sync).

4. Estratégias de Leitura com `Read Preferences`

O Read Preference define como o driver cliente roteia as consultas de leitura (find, aggregate) entre os membros do Replica Set:

// Exemplo no mongosh / Driver configurando Read Preference
db.pedidos.find({ status: "ENTREGUE" }).readPref("secondaryPreferred")

• "primary" (Padrão): Lê exclusivamente do nó Primary. Garante consistência estrita com dados em tempo real.
• "primaryPreferred": Lê do Primary; se estiver indisponível (durante uma eleição/failover), lê de um Secondary.
• "secondary": Lê exclusivamente dos Secondaries (nunca do Primary). Útil para tirar carga do nó principal, mas pode retornar dados ligeiramente defasados (stale reads).
• "secondaryPreferred": Lê preferencialmente dos Secondaries; se nenhum estiver acessível, consulta o Primary.
• "nearest": Lê do nó com a menor latência de rede (seja Primary ou Secondary), medido por pings periódicos do driver. Ideal para aplicações com distribuição geográfica multi-região.

5. Diagnóstico e Gestão no `mongosh`

// 1. Obter o status completo do Replica Set (estado de cada nó, latência, lag)
rs.status()

// 2. Visualizar a configuração atual (prioridades, delays, tags)
rs.conf()

// 3. Forçar o Primary atual a abdicar e iniciar uma nova eleição
rs.stepDown(60) // Fica impedido de ser eleito por 60 segundos

// 4. Verificar se a conexão atual está no nó Primary
db.hello() // (Substituto moderno do antigo db.isMaster())

6. Questões no Estilo Exame de Certificação

Questão 1: Um Replica Set possui 5 membros votantes distribuídos igualmente entre três zonas de disponibilidade. Um corte de rede isola 2 membros do restante do cluster. O que acontece com o grupo minoritário de 2 membros que continha o Primary original?

A) O Primary continua aceitando leituras e escritas normalmente.
B) O Primary detecta que perdeu a comunicação com a maioria (3 nós) e abdica (step down) para o estado SECONDARY, rejeitando novas escritas.
C) Os 2 membros elegem um novo Primary imediatamente.
D) O cluster entra em travamento permanente até intervenção manual do administrador.

Resposta Correta: B. O MongoDB requer a maioria estrita dos nós votantes (3 de 5) para manter um Primary. Sem a maioria, o Primary abdica para proteger a integridade dos dados e evitar escrita divergente.

Questão 2: Uma equipe de engenharia precisa rodar rotinas diárias pesadas de BI/Analytics sem degradar a performance das transações da aplicação no Primary e sem correr o risco de a aplicação principal ler dados defasados por engano. Qual é a configuração de membro recomendada para o nó de BI?

A) Um membro Arbiter.
B) Um membro com priority: 1 e slaveDelay: 3600.
C) Um membro com priority: 0 e hidden: true.
D) Um membro Standalone sincronizado manualmente.

Resposta Correta: C. Membros hidden não recebem tráfego dos drivers de aplicação normal e com priority: 0 nunca se tornam Primary, permitindo que as consultas de BI se conectem diretamente a ele de forma isolada.