Cómo diseñar una arquitectura de alta disponibilidad para aplicaciones críticas utilizando Linux y PostgreSQL

Diseñar una arquitectura de alta disponibilidad para aplicaciones críticas con Linux y PostgreSQL no consiste solo en tener “dos servidores”. Una solución seria debe considerar replicación, failover automático, balanceo, respaldo, recuperación ante desastres, monitoreo, pruebas periódicas y procedimientos claros de operación.

PostgreSQL es una base de datos robusta, pero por sí sola no resuelve todos los componentes de alta disponibilidad. Para aplicaciones empresariales se recomienda combinar PostgreSQL con herramientas como Patroni, etcd o Consul, HAProxy, PgBouncer, Keepalived, pgBackRest, Barman, Prometheus, Grafana y monitoreo de logs.

1. Definir RTO y RPO antes de instalar nada

Antes de elegir herramientas, la empresa debe definir dos objetivos:

Si la empresa exige RPO cero, probablemente necesitará replicación síncrona o semisíncrona, con impacto en latencia. Si acepta perder algunos segundos de transacciones, la replicación asíncrona puede ofrecer mejor rendimiento y mayor flexibilidad.

2. Arquitectura base recomendada

Para una aplicación crítica, una arquitectura equilibrada puede tener esta forma:

3. Diseño mínimo recomendado

Para evitar puntos únicos de falla, una arquitectura empresarial debería considerar al menos:

4. Replicación en PostgreSQL: síncrona o asíncrona

PostgreSQL soporta mecanismos de alta disponibilidad, balanceo y replicación, incluyendo servidores standby, streaming replication y replicación síncrona. La decisión entre síncrona y asíncrona debe tomarse según el RPO, la latencia y la criticidad del dato.

5. Patroni: automatizar failover y switchover

Patroni es una de las soluciones open source más usadas para alta disponibilidad con PostgreSQL. Permite gestionar el líder del clúster, promover réplicas, ejecutar failover, realizar switchover planificado y exponer endpoints REST para monitoreo y balanceadores.

Patroni utiliza un almacén de configuración distribuida, como etcd, Consul, ZooKeeper o Kubernetes, para coordinar el estado del clúster. Esto es fundamental para evitar el problema más peligroso en una base de datos HA: que dos nodos crean ser primarios al mismo tiempo.

6. HAProxy y Keepalived: entrada estable al clúster

La aplicación no debería conectarse directamente a un nodo PostgreSQL específico. Lo recomendable es ofrecer una dirección estable que apunte siempre al nodo correcto.

Una combinación frecuente es:

También se pueden separar puertos: uno para escritura hacia el primario y otro para lecturas hacia réplicas. Pero esto requiere que la aplicación esté preparada para distinguir operaciones de lectura y escritura.

7. PgBouncer: controlar conexiones

PostgreSQL puede sufrir cuando una aplicación abre demasiadas conexiones simultáneas. PgBouncer funciona como pool de conexiones ligero: la aplicación se conecta a PgBouncer y PgBouncer reutiliza conexiones hacia PostgreSQL.

Esto es especialmente útil en aplicaciones web, microservicios, APIs y entornos donde muchos procesos intentan conectarse al mismo tiempo.

sudo apt update
sudo apt install -y pgbouncer

8. Backups: alta disponibilidad no reemplaza respaldo

Uno de los errores más graves es creer que tener réplicas reemplaza los backups. Si alguien borra una tabla, ejecuta una migración incorrecta o una aplicación corrompe datos, la réplica puede copiar el problema rápidamente.

Por eso se necesita una estrategia de backup con base backups, archivado continuo de WAL y recuperación a un punto en el tiempo. Herramientas como pgBackRest o Barman permiten construir una estrategia sólida de respaldo y recuperación.

9. Comandos útiles para validar estado

En PostgreSQL, puedes revisar si el nodo actual está en recuperación:

SELECT pg_is_in_recovery();

En el primario, puedes revisar réplicas conectadas:

SELECT
  application_name,
  client_addr,
  state,
  sync_state,
  write_lag,
  flush_lag,
  replay_lag
FROM pg_stat_replication;

Con Patroni, puedes consultar el estado del clúster:

patronictl list

10. Monitoreo indispensable

Un clúster HA sin monitoreo puede fallar silenciosamente. La empresa debe vigilar no solo si PostgreSQL responde, sino también si replica, si acumula WAL, si los backups terminan correctamente y si los nodos están sincronizados.

11. Pruebas obligatorias de alta disponibilidad

No basta con declarar que el sistema es HA. Hay que demostrarlo mediante pruebas controladas.

12. Seguridad de la arquitectura

Una arquitectura HA debe ser también segura. No se debe abrir PostgreSQL innecesariamente a Internet ni permitir conexiones sin cifrado o sin controles de acceso adecuados.

13. Errores comunes

Preguntas clave

Recomendamos

En resumen

Una arquitectura de alta disponibilidad con Linux y PostgreSQL debe diseñarse como un sistema completo, no como una instalación aislada. PostgreSQL aporta replicación y robustez; Patroni ayuda con failover; etcd o Consul aportan consenso; HAProxy y Keepalived ofrecen entrada estable; PgBouncer controla conexiones; pgBackRest o Barman aseguran recuperación; el monitoreo confirma que todo funciona.

La alta disponibilidad real se demuestra en pruebas: apagando nodos, restaurando backups, midiendo RTO, validando RPO y verificando que la aplicación sigue funcionando. Si no se prueba, no existe.