Concepto clave

La replicación y alta disponibilidad en PostgreSQL son estrategias fundamentales para mantener aplicaciones funcionando sin interrupciones, incluso durante fallos de hardware o mantenimiento. Imagina una cadena de restaurantes: si la cocina principal se incendia, tener sucursales con menús idénticos permite seguir sirviendo a los clientes sin pausa. En PostgreSQL, esto se logra replicando datos desde un servidor principal (primary) a uno o más servidores secundarios (standbys), usando métodos como replicación física (streaming) o lógica.

La alta disponibilidad va más allá de la simple copia de datos; implica mecanismos automáticos de detección de fallos y conmutación (failover), asegurando que los usuarios no perciban interrupciones. Para aplicaciones de alta concurrencia, donde miles de transacciones ocurren simultáneamente, una configuración robusta de HA es crítica para evitar cuellos de botella y pérdida de datos, manteniendo la consistencia y el rendimiento.

Cómo funciona en la práctica

Configurar replicación en PostgreSQL implica varios pasos clave. Primero, en el servidor primary, se habilita la replicación modificando postgresql.conf y pg_hba.conf para permitir conexiones desde los standbys. Luego, se crea un usuario de replicación y se toma un backup base usando pg_basebackup en el standby. Finalmente, se configura recovery.conf (o postgresql.auto.conf en versiones recientes) en el standby para iniciar la replicación streaming.

Por ejemplo, para una aplicación de comercio electrónico con alta concurrencia, podrías tener un primary manejando escrituras y dos standbys en diferentes zonas geográficas para lecturas y failover. Usando herramientas como Patroni o pgpool-II, se automatiza la detección de fallos: si el primary se cae, un standby es promovido automáticamente a nuevo primary, minimizando el tiempo de inactividad (downtime).

Codigo en accion

Configuración básica de replicación streaming en PostgreSQL 14:

-- En el servidor primary (postgresql.conf)
wal_level = replica
max_wal_senders = 10
wal_keep_size = 1GB

-- En pg_hba.conf del primary
host replication replicador 192.168.1.100/32 md5

-- Crear usuario de replicación en primary
CREATE USER replicador WITH REPLICATION ENCRYPTED PASSWORD 'securepass';

-- En el servidor standby, tomar backup base
pg_basebackup -h primary_ip -D /var/lib/postgresql/14/main -U replicador -P -R

-- Configurar standby (recovery.conf en versiones antiguas, o postgresql.auto.conf)
primary_conninfo = 'host=primary_ip port=5432 user=replicador password=securepass'
standby_mode = 'on'

Mejora para alta disponibilidad con Patroni (configuración YAML):

scope: postgres_cluster
name: node1

restapi:
  listen: 0.0.0.0:8008
  connect_address: 192.168.1.101:8008

etcd:
  hosts: 192.168.1.50:2379

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576
    postgresql:
      use_pg_rewind: true
      parameters:
        wal_level: replica
        hot_standby: "on"
        max_wal_senders: 10
        wal_keep_size: 1GB

  initdb:
  - encoding: UTF8
  - data-checksums

  pg_hba:
  - host replication replicador 192.168.1.0/24 md5
  - host all all 0.0.0.0/0 md5

Errores comunes

No monitorear el lag de replicación: En alta concurrencia, si el standby se retrasa demasiado en recibir WALs, puede causar inconsistencia de datos. Usa pg_stat_replication para verificar.
Configurar insuficientes max_wal_senders: Esto limita conexiones concurrentes de replicación, causando cuellos de botella. Ajusta según el número de standbys.
Olvidar la autenticación en pg_hba.conf: Sin reglas correctas, los standbys no pueden conectarse, rompiendo la replicación.
Usar replicación asíncrona sin entender los riesgos: En modos asíncronos, puede haber pérdida de datos en failover; considera síncrona para críticos.
Ignorar la capacidad de almacenamiento en standbys: Si se llenan, la replicación se detiene; monitorea espacio en disco proactivamente.

Checklist de dominio

¿Puedes configurar replicación streaming entre un primary y al menos un standby desde cero?
¿Entiendes la diferencia entre replicación síncrona y asíncrona y cuándo usar cada una?
¿Sabes monitorear el estado de replicación usando vistas como pg_stat_replication?
¿Puedes ejecutar un failover manual y promover un standby a primary?
¿Has implementado una herramienta de HA como Patroni o repmgr en un entorno de prueba?
¿Comprendes cómo afecta la replicación al rendimiento de queries en alta concurrencia?
¿Puedes recuperar un standby desincronizado usando pg_rewind?

Configura un entorno de replicación con failover automático

En este ejercicio, configurarás un clúster de PostgreSQL con alta disponibilidad usando Patroni y etcd, simulando un entorno de alta concurrencia. Sigue estos pasos:

Prepara tres servidores virtuales (o contenedores) con PostgreSQL 14 instalado. Nómbralos como node1, node2, y node3.
En node1, instala y configura etcd como almacén de configuración distribuido. Asegúrate de que esté accesible desde todos los nodos.
Instala Patroni en los tres nodos y configura archivos YAML según el ejemplo de código proporcionado, ajustando direcciones IP y puertos.
Inicia Patroni en node1 para bootstrap el clúster, luego inicia en node2 y node3 para unirse como standbys.
Verifica la replicación conectándote a cada nodo y ejecutando SELECT * FROM pg_stat_replication; en el primary.
Simula un fallo deteniendo el servicio PostgreSQL en el primary (node1) y observa cómo Patroni promueve automáticamente un standby a nuevo primary.
Recupera el nodo caído y reintegra al clúster como standby usando pg_rewind si es necesario.

Pistas

Asegúrate de que la red entre nodos permita comunicación en puertos 5432 (PostgreSQL), 2379 (etcd), y 8008 (Patroni API).
Usa patronictl list para monitorear el estado del clúster durante el failover.
Si pg_rewind falla, considera restaurar desde un backup base en lugar de reintegrar.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.

Quiz de Replicación y HA

Quiz Interactivo