Simulacro de failover / transición de rol planificada
Un árbol de decisión que identifica el tipo de cambio de rol (switchover planificado, failover de emergencia o un simulacro que no toca producción) y ofrece la secuencia de comandos y los pasos de verificación correctos para cada escenario. Objetivo: estar listo para la transición sin pérdida de datos cuando es planificada, con pérdida mínima en una emergencia y sin ninguna interrupción en un simulacro.
¿Qué quiere hacer?
Elija el contexto del cambio de rol. ¿Está haciendo una transición planificada con el primario sano (mantenimiento/migración), ha caído realmente el primario y se necesita una transición de emergencia, o está ejecutando un simulacro/validación de preparación sin tocar producción?
- Switchover planificado (el primario está sano)
- Failover de emergencia (el primario ha caído)
- Simulacro / prueba de preparación (no tocar producción)
Transición planificada: ¿está todo listo?
El objetivo de un switchover planificado es CERO pérdida de datos. Para ello, antes de la transición debe asegurarse de que la réplica se ha puesto al día con el primario (retraso ~0) y está sana. Compruebe el retraso con los comandos siguientes; si el retraso es cercano a cero, pase a los pasos de transición.
SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#; -- DG: SELECT name, value FROM v$dataguard_stats WHERE name LIKE '%lag%';- El retraso es cercano a cero, listo para la transición
- El retraso es alto, espere primero a la sincronización
Switchover planificado (transición controlada sin pérdida de datos)
Mientras el primario y el standby están sanos y sincronizados, intercambie los roles de forma controlada. El orden importa: detenga las escrituras, asegúrese de que los cambios restantes han llegado al standby, luego transfiera el rol y redirija la aplicación al nuevo primario.
Transición de emergencia: ¿el primario está realmente caído?
Antes de forzar un failover, verifique que el primario es realmente inaccesible y evalúe el riesgo de split-brain. Si el primario sigue vivo (p. ej. un corte de red transitorio), una transición forzada da lugar a dos copias escribibles separadas (split-brain). Compare también el retraso para elegir el standby más actualizado.
-- try to reach the primary: tnsping primary_db; and on the standby: SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;- Sí, el primario ha caído: forzar la transición
- No estoy seguro / el primario podría volver
Failover de emergencia (el primario ha caído, transición con riesgo de pérdida de datos)
El primario es inaccesible y no puede esperar a que vuelva. Debe promover el standby de forma forzada; con replicación asíncrona pueden perderse algunas de las últimas transacciones. Su prioridad es restablecer el servicio; después, identifique la ventana de pérdida y recupere de forma segura el antiguo primario.
Simulacro / prueba de preparación (validar sin tocar producción)
Demuestre que está listo para un failover sin realizar una transición real. Verifique la salud de la réplica, que el retraso es aceptable y que la aplicación puede redirigirse, sin afectar a producción. Opcionalmente, ensaye un switchover real en una copia aislada.