Módulo 13 · Resiliencia y recuperación/Lección 83
Failover, failback y split-brain
Pasar a la región de respaldo sin perder datos ni quedar con dos bases primarias, y volver cuando todo pase.
Tienes datos replicados en otra región. Falta lo más difícil: cambiar a ella sin perder más datos de los necesarios, sin terminar con dos bases que aceptan escrituras y sin que el regreso sea peor que la falla.
Pasa el mouse para ver qué es cada pieza; haz clic para abrir su ficha. En el celular, usa los botones de abajo.
Amazon Aurora
Aurora Global Database
AnalogíaLa bóveda principal y una copia en otra ciudad que se actualiza casi al instante.
La región primaria escribe y la secundaria recibe los cambios por replicación asíncrona a nivel de almacenamiento. Ese retraso se mide con una métrica de CloudWatch y es tu RPO efectivo en un desastre.
En el failover, la secundaria se promueve a primaria. Antes hay que asegurar que la antigua primaria no siga aceptando escrituras, para no quedar con dos bases que divergen (split-brain).
Failover, switchover y failback
| Criterio | Failover | Switchover | Failback |
|---|---|---|---|
| Qué es | Pasar al secundario porque el primario falló | Cambiar de primario de forma planeada, con todo sano | Volver al sitio original cuando se recupera |
| Cuándo | Durante el incidente | Mantenimiento, simulacros, rotación de región | Días o semanas después, en una ventana elegida |
| Pérdida de datos | Posible: lo que no alcanzó a replicarse | Ninguna: espera la sincronización | Ninguna si se hace como switchover |
| En Aurora Global Database | Failover administrado (permite pérdida de datos) | Switchover | Switchover de vuelta, cuando la región vieja ya es secundaria |
Automático o manual
Dentro de una región, el failover debe ser automático: RDS Multi-AZ cambia de instancia, el balanceador deja de enviar tráfico a destinos que fallan y ARC zonal autoshift aleja el tráfico de una zona con problemas (ver alta disponibilidad). Son cambios baratos, frecuentes y reversibles.
Entre regiones, lo habitual es decisión humana con ejecución automatizada. Las razones:
- La mayoría de los incidentes afectan solo algunos servicios. La guía de Aurora pide evaluar el alcance real antes de cambiar de región.
- Con replicación asíncrona, cada failover pierde datos. No quieres que un chequeo de salud nervioso lo decida.
- El failback cuesta horas de trabajo. Un falso positivo te deja con un proyecto que no pediste.
La persona decide con un criterio escrito; la ejecución es un plan que corre solo, paso a paso, sin comandos tecleados a mano en medio de la crisis. Quién decide y cómo se declara el desastre va en el runbook: runbooks y simulacros.
Split-brain y cómo evitarlo
Split-brain es tener dos primarios aceptando escrituras al mismo tiempo. Cada uno diverge del otro y reconciliarlos después es manual, lento y a veces imposible. Las defensas:
- 1
Una sola fuente de verdad para escribir
En todo momento hay un único primario para cada dato. Con Aurora Global Database, conecta la aplicación al endpoint de escritura global, que sigue al primario tras un cambio. - 2
Congela las escrituras antes de promover
Pon la aplicación en modo solo lectura o detén los procesos que escriben. Mejor rechazar escrituras unos minutos que aceptarlas en dos lugares. - 3
Aísla al primario viejo (fencing)
Quítale el tráfico, revoca o rota las credenciales que usa la aplicación y bloquea su red. Aurora intenta detener las escrituras en el almacenamiento viejo, pero lo hace como mejor esfuerzo, sin garantía. - 4
Decide por mayoría
Con un testigo o quórum de tres participantes, una región aislada no puede declararse primaria sola. DynamoDB global tables en modo de consistencia fuerte usa esta idea: tres regiones, o dos réplicas y un testigo.
Redirigir el tráfico: Route 53 y ARC
Route 53, el directorio de la ciudad, tiene enrutamiento de failover: responde con el registro principal mientras su chequeo de salud pasa y con el secundario si falla. Los chequeadores corren desde varias ubicaciones cada 10 o 30 segundos, y Route 53 considera sano un endpoint si más del 18 % de ellos lo reporta sano. Ten en cuenta sus límites:
- TTL: los resolvedores guardan la respuesta durante el TTL del registro. Con 24 horas, tus usuarios siguen yendo a la región caída todo el día.
- Cachés de los clientes: algunos runtimes y pools de conexiones guardan direcciones o conexiones abiertas más allá del TTL. AWS recomienda bajar a unos 5 segundos la caché de DNS de las aplicaciones que usan el endpoint global de Aurora.
- Un chequeo mide alcance, no corrección: que el endpoint responda 200 no prueba que la base esté al día ni que la región entera esté sana.
ARC routing control
Interruptores de encendido y apagado, conectados a chequeos de salud de Route 53, para mover el tráfico entre regiones a voluntad. Tienen un plano de datos muy disponible, pensado para usarse durante el incidente.ARC safety rules
Reglas sobre los interruptores, por ejemplo «siempre debe haber exactamente una región activa». Evitan apagar todo por error o encender las dos.ARC Region switch
Planes de recuperación con pasos y bloques de ejecución (promover Aurora, escalar capacidad, cambiar DNS, aprobación manual). Se ejecutan a mano o con alarmas de CloudWatch, desde un plano de datos en cada región.Aurora Global Database
Switchover y failover administrados. Tras un failover, agrega de nuevo la región vieja como secundaria cuando se recupera.
Amazon Application Recovery Controller (ARC) también incluye zonal shift y zonal autoshift para fallas de una zona. La función readiness check, que vigilaba si la región de respaldo estaba lista, ya no acepta clientes nuevos; AWS recomienda Region switch, cuya evaluación de planes revisa de forma periódica que el plan se pueda ejecutar.
El orden de las operaciones
- 1
Decide y declara
Con el criterio del runbook. Avisa a todos que empieza un failover y quién lo dirige. - 2
Protege los datos
Congela las escrituras, aísla al primario viejo y elige el secundario con menos retraso (por ejemplo, el menor AuroraGlobalDBRPOLag). - 3
Promueve
Failover administrado de Aurora, promoción de la réplica de RDS o, con global tables, nada que promover: ya aceptan escrituras. - 4
Redirige el tráfico
Routing controls de ARC, registros de failover de Route 53 o el plan de Region switch. - 5
Valida
Transacciones de prueba de punta a punta, conteos de datos, colas que se vacían, pagos que pasan. - 6
Reabre las escrituras
Solo cuando la validación pasa. Luego anota qué datos pudieron perderse para reconciliarlos.
El failback es un proyecto planeado
Volver no es apretar el mismo botón al revés. La región original estuvo caída; sus datos están viejos o divergentes. El failback sigue estos pasos:
- Espera estabilidad: que la región original lleve un tiempo sana, no cinco minutos.
- Resincroniza en sentido inverso: la región original pasa a ser la copia de la nueva primaria. Aurora Global Database lo hace solo tras un failover administrado; con una réplica de RDS promovida, creas una réplica nueva en la región original.
- Reconcilia: recupera lo que no alcanzó a cruzar, por ejemplo desde el snapshot que Aurora toma del volumen viejo.
- Cambia como switchover: en una ventana de poco tráfico, sin pérdida de datos, con el mismo runbook y un plan para revertir.
Quiz
Pon a prueba lo que aprendiste
0 de 5 correctas · 5 sin responder
1.Una alarma detecta errores elevados en una región. Un script promueve la base de otra región en cuanto falla un chequeo de salud. ¿Cuál es el riesgo principal?
2.Durante un failover, la región vieja recupera la red y la aplicación de esa región sigue escribiendo en su base. ¿Qué pasó?
3.Cambiaste el registro de failover en Route 53, pero una hora después muchos usuarios siguen llegando a la región caída. ¿Qué revisas primero?
4.Necesitas apagar el tráfico de una región y encender el de otra con una garantía de que nunca queden las dos activas. ¿Qué usas?
5.Tras un failover administrado de Aurora Global Database, la región original ya está sana. ¿Cómo haces el failback sin perder datos?