PostgreSQL
Alta disponibilidad y disaster recovery
Diseño de alta disponibilidad y disaster recovery con réplicas, failover, fencing, RPO, RTO, runbooks y pruebas de recuperación.
- Última actualización
- Actualizada
- Nivel
- Profundización
PostgreSQL
Diseño de alta disponibilidad y disaster recovery con réplicas, failover, fencing, RPO, RTO, runbooks y pruebas de recuperación.
Alta disponibilidad reduce interrupciones; disaster recovery recupera el servicio después de una pérdida mayor. Ninguna de las dos aparece por tener una réplica: necesita decisiones, automatización, fencing, backups y pruebas.
HA
→ fallos frecuentes/locales
→ failover rápido
→ menor RTO
DR
→ pérdida de región, corrupción, error humano o ataque
→ restauración independiente
→ RPO/RTO definidosUna arquitectura puede tener HA sin DR y seguir perdiendo todos los datos ante una corrupción replicada.
No todo timeout significa que el primary murió. Puede ser:
Una promoción demasiado rápida puede crear split brain. Usa múltiples señales y quorum/witness cuando la herramienta lo requiera.
Antes o durante promoción, el antiguo primary debe perder capacidad de aceptar writes:
Sin fencing, dos primaries pueden divergir.
El standby más cercano o disponible no siempre es el más actualizado. Evalúa:
Promover uno atrasado aumenta RPO real.
Clientes no deberían codificar IP del primary. Usa:
El pool debe descartar conexiones rotas y reintentar conexión, no repetir transacciones inciertas ciegamente.
Después de promoción pueden ocurrir:
Necesitas idempotencia y reconciliación.
No lo vuelvas a conectar como standby sin asegurar que su timeline diverged está resuelta. Opciones:
pg_rewind si prerequisites se cumplen.Nunca lo promociones de vuelta solo por volver a estar disponible.
Protege contra fallo de host/zona, pero puede compartir región, cuenta, configuración y errores lógicos. Para DR necesitas separación mayor y backups independientes.
PITR a antes del DELETE, restaurar cluster aislado y extraer datos.
Detener propagación, identificar punto sano, restaurar y validar.
Activar réplica cross-region o restaurar backups en región alternativa.
Usar backups inmutables con acceso separado.
Un runbook debe ser ejecutable bajo presión:
Prueba periódicamente:
Mide RTO real y pérdida real, no solo tiempos teóricos.
Un standby usado solo para DR puede no tener CPU/IO suficiente para asumir producción. Evalúa:
Puede reducir pérdida ante failover, pero si el standby requerido no está disponible, los commits pueden bloquear. Configura quorum y timeouts según prioridad entre consistencia y disponibilidad.
La réplica no sustituye estos elementos.
Alertas:
host failure → standby local
zone failure → multi-AZ
region failure → cross-region/restore
logical delete → PITR
ransomware → immutable off-account backupMonitoreo y observabilidad convierte síntomas de PostgreSQL en señales accionables.