Exercício de failover / transição de papel planejada

Uma árvore de decisão que identifica o tipo de troca de papel (switchover planejado, failover de emergência ou um exercício que não toca a produção) e fornece a sequência correta de comandos e as etapas de verificação para cada cenário. Objetivo: estar pronto para fazer a transição sem perda de dados quando planejada, com perda mínima em uma emergência e sem nenhuma indisponibilidade em um exercício.

O que você quer fazer?

Escolha o contexto da troca de papel. Você está fazendo uma transição planejada com o primário saudável (manutenção/migração), o primário realmente caiu e é necessária uma transição de emergência, ou você está executando um exercício/validação de prontidão sem tocar a produção?

• Switchover planejado (primário saudável)
• Failover de emergência (primário caiu)
• Exercício / teste de prontidão (não tocar a produção)

Transição planejada — você está pronto?

O objetivo de um switchover planejado é ZERO perda de dados. Para isso, antes da transição você deve garantir que a réplica alcançou o primário (lag ~0) e está saudável. Verifique o lag com os comandos abaixo; se o lag estiver próximo de zero, siga para as etapas de transição.

SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;   -- DG: SELECT name, value FROM v$dataguard_stats WHERE name LIKE '%lag%';

• O lag está próximo de zero, pronto para a transição
• O lag está alto, aguarde a sincronização primeiro

Switchover planejado (transição controlada sem perda de dados)

Com o primário e o standby saudáveis e sincronizados, troque os papéis de forma controlada. A ordem importa: pare as gravações, garanta que as alterações restantes chegaram ao standby, depois transfira o papel e redirecione a aplicação para o novo primário.

Transição de emergência — o primário realmente caiu?

Antes de forçar um failover, verifique se o primário está de fato inacessível e avalie o risco de split-brain. Se o primário estiver na verdade ativo (ex.: uma queda de rede transitória), uma transição forçada leva a duas cópias graváveis separadas (split-brain). Compare também o lag para escolher o standby mais atualizado.

-- try to reach the primary: tnsping primary_db; and on the standby: SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;

• Sim, o primário caiu — forçar a transição
• Não tenho certeza / o primário pode voltar

Failover de emergência (primário caiu, transição com risco de perda de dados)

O primário está inacessível e você não pode esperar que ele volte. É preciso forçar a promoção do standby; com replicação assíncrona, algumas das últimas transações podem ser perdidas. Sua prioridade é restabelecer o serviço, depois identificar a janela de perda e trazer o antigo primário de volta com segurança.

Exercício / teste de prontidão (validar sem tocar a produção)

Comprove que você está pronto para o failover sem executar uma transição real. Verifique a saúde da réplica, se o lag é aceitável e se a aplicação pode ser redirecionada, sem afetar a produção. Opcionalmente, ensaie um switchover real em uma cópia isolada.