Decisión: ¿qué solución de HA/DR?
La elección de una solución de alta disponibilidad y recuperación ante desastres no empieza por la tecnología, sino por el equilibrio entre los requisitos de negocio (RTO/RPO), la necesidad de distribución geográfica y el costo. Partiendo de su tolerancia a la interrupción y a la pérdida de datos, este árbol le orienta hacia el enfoque adecuado entre réplicas síncronas, standby asíncronos, clústeres con failover automático y backup+PITR.
¿Cuál es su tolerancia a la pérdida de datos (RPO)?
Empiece por la restricción más dura: ante un desastre, ¿cuántos segundos de datos puede permitirse perder? Si se exige cero pérdida de datos (RPO=0), la replicación síncrona es obligatoria; si unos segundos/minutos son aceptables, se abren las soluciones asíncronas y enfoques más económicos. El objetivo de RPO suele condicionar todas las demás decisiones.
- Cero pérdida de datos es obligatorio (RPO = 0)
- Unos segundos/minutos de pérdida de datos son aceptables
¿También se requiere una toma de control automática y rápida (RTO bajo)?
Quiere cero pérdida de datos; pero ¿con qué rapidez debe volver a estar operativo cuando cae el primario? ¿Failover automático en segundos, o es aceptable una breve ventana de intervención manual? Esto marca la diferencia entre una simple réplica síncrona y un clúster totalmente automatizado.
- Se requiere failover automático en segundos
- Basta con una toma de control manual/planificada; lo primero es cero pérdida
¿Se requiere otra región/geografía (DR)?
Si cierta pérdida de datos es aceptable, la verdadera pregunta es el alcance de la resiliencia: ¿debe protegerse frente a la pérdida de un centro de datos/región completo, o basta con protegerse frente al fallo de un solo nodo en la misma región? Si se requiere distribución geográfica, cobra protagonismo un standby asíncrono; si no, se evalúan las opciones que priorizan el costo.
- Sí, es obligatoria una región separada frente a desastres geográficos
- No, lo primero son el presupuesto y la simplicidad
¿Puede aceptar un tiempo de recuperación largo (RTO alto)?
Se queda en una sola región y tolera cierta pérdida de datos. ¿Busca el costo más bajo, o quiere un nodo standby que tome el control rápidamente ante un fallo? Si es aceptable que la recuperación lleve horas, backup+PITR por sí solo es el camino más económico; de lo contrario, necesita un warm standby.
- Sí, es aceptable que la recuperación lleve horas (lo más barato)
- No, se requiere un warm standby que tome el control en minutos
Recomendación: réplica síncrona (cero pérdida de datos)
El primario no completa un commit hasta que al menos un standby lo confirma; así, aunque se pierda el primario, no se pierde ninguna transacción confirmada (RPO=0). La solución ideal dentro de una región con una red de baja latencia.
Recomendación: standby asíncrono (DR geográfico)
El standby aplica los cambios en streaming sin retrasar los commits del primario. Es la forma estándar de mantener una copia en otra región sin perjudicar el rendimiento de escritura; a cambio, se acepta una pequeña ventana de pérdida de datos (igual al retraso de replicación).
Recomendación: clúster con failover automático
Una solución de clúster que combina monitoreo de salud, elección de líder y toma de control automática; persigue tanto un RTO bajo (failover automático en segundos) como un RPO bajo/cero con una copia síncrona. La carga operativa es mayor, pero la intervención humana se minimiza.
Recomendación: backup + PITR (lo más económico)
En lugar de un standby en ejecución, solo se mantienen backups periódicos y la recuperación a un punto en el tiempo (PITR) mediante WAL/logs archivados. Es la solución de menor costo; el precio es que la recuperación puede llevar horas (RTO alto).