Qué es PostgreSQL Streaming Replication (WAL) y cómo configurarlo

• Streaming Replication de PostgreSQL es una forma eficiente de mantener una réplica casi en tiempo real de la DB primaria en uno o más servidores en espera
• El servidor primario transmite continuamente los registros de Write-Ahead Log (WAL) a los servidores en espera a medida que se generan, minimizando la latencia del proceso de replicación
• Está diseñada para mejorar la alta disponibilidad y la escalabilidad, permitiendo descargar consultas de lectura a los servidores en espera para reducir la carga del servidor primario
• Soporta tanto modo síncrono como asíncrono, lo que permite ajustar con flexibilidad el equilibrio entre consistencia de datos y rendimiento
• Incluye el proceso en el que el servidor en espera se conecta al primario para solicitar el streaming de WAL y aplica los registros recibidos a su propia copia de la DB
• En comparación con el envío de logs basado en archivos, ofrece failover más rápido y menor riesgo de pérdida de datos, por lo que es ideal para entornos geográficamente distribuidos

¿Cómo funciona Streaming Replication?

• El servidor primario envía continuamente datos WAL en tiempo real al servidor en espera, manteniendo la DB del standby casi idéntica a la del primario
• Esto permite usar la réplica para failover del maestro o para manejar cargas de lectura, lo que permite que el sistema escale varias veces

Archivos de configuración de PostgreSQL y sus ubicaciones

• Los archivos de configuración de PostgreSQL cumplen un papel importante en la administración de la configuración y el comportamiento del servidor de base de datos.
  • postgresql.conf: el archivo principal de configuración que contiene la mayoría de los ajustes del servidor. Según el sistema operativo, puede estar en distintas ubicaciones como /etc/postgresql/<version>/main/postgresql.conf (Debian/Ubuntu) o /var/lib/pgsql/<version>/data/postgresql.conf (Red Hat/CentOS)
  • pg_hba.conf: controla la autenticación de clientes y define cómo pueden conectarse al servidor. Generalmente se encuentra en el mismo directorio que postgresql.conf
  • pg_ident.conf: se usa para mapear nombres de usuario, aunque se utiliza con menos frecuencia
  • recovery.conf: se usaba para configurar servidores en espera en versiones anteriores a PostgreSQL 12, pero en versiones posteriores su contenido se trasladó a postgresql.conf y postgresql.auto.conf
• La ubicación exacta puede variar según el sistema operativo, el método de instalación y la versión de PostgreSQL
  • Puedes encontrar la ubicación de estos archivos desde una instancia de PostgreSQL usando el comando SQL SHOW config_file;

Ejemplo y estructura de WAL (Write Ahead Logs)

• Puedes ver WAL con el comando pg_waldump
• Cada línea representa un registro WAL que contiene información sobre una operación de la DB
• Componentes de cada registro:
  • rmgr: administrador de recursos (por ejemplo, Heap, Btree, Transaction)
  • len: longitud del registro
  • tx: ID de transacción
  • lsn: número de secuencia del log
  • prev: LSN anterior
  • desc: descripción de la operación
• Tipos de operaciones visibles:
  • operaciones INSERT (Heap y Btree)
  • operaciones MULTI_INSERT (Heap2)
  • transacciones COMMIT
  • operaciones sobre archivos (CREATE)
  • Full Page Writes (FPW)
• La salida de WAL muestra en detalle el flujo de transacciones, modificaciones de datos y actividad del sistema, por lo que resulta útil para analizar el comportamiento de la DB, resolver problemas y hacer recuperación a un punto en el tiempo

Cómo trabajar con Docker

• Ajustes importantes relacionados con Streaming Replication en postgresql.conf:
  • wal_level, max_wal_senders, max_replication_slots, hot_standby, etc.
• Lo necesario para un ejemplo con Docker Compose:
  • init-master.sh: configura el maestro de PostgreSQL para replicación. Crea el usuario de replicación y el slot, y actualiza la configuración relacionada con WAL
  • init-replica.sh: prepara la réplica de PostgreSQL para conectarse al maestro e iniciar la replicación. Espera a que el maestro esté listo, luego realiza un respaldo base y configura la réplica
  • start-replica.sh: inicia la réplica de PostgreSQL dentro del contenedor Docker. Ejecuta el script init-replica.sh y luego arranca PostgreSQL
  • docker-compose.yml: define los servicios de maestro y réplica y configura las variables de entorno, volúmenes, comandos y demás elementos necesarios
• Después de dar permisos de ejecución a los scripts y ejecutar docker-compose up -d, se iniciarán el maestro y la réplica
• Puedes conectarte al maestro y verificar el estado de la replicación con pg_stat_replication
• Puedes conectarte a la réplica y confirmar si está en modo de recuperación con pg_is_in_recovery()

Opinión de GN⁺

• Streaming Replication puede mejorar en gran medida el rendimiento y la resiliencia de la infraestructura de base de datos. Ya sea para prepararse para escenarios de failover o para distribuir la carga de lectura hacia las réplicas, esto puede ayudar a que la DB escale y mantenga un rendimiento estable
• Mostrar el proceso completo de configuración y la salida es importante. Esto ofrece una visión integral de muchas piezas móviles y ayuda a entender mejor qué está ocurriendo
• Entender cómo funciona Streaming Replication y configurarlo correctamente es muy importante. Ojalá este artículo haya ayudado a aclarar el proceso y a ofrecer una mejor visión de cómo funciona la replicación
• Otros productos o proyectos con funciones similares incluyen Replication de MySQL y Data Guard de Oracle. Estas soluciones también funcionan transmitiendo cambios desde el maestro hacia las réplicas, aunque los detalles de implementación pueden variar
• Al usar Streaming Replication, hay que considerar el ancho de banda y la latencia de red. La transferencia de datos entre el maestro y las réplicas puede consumir una cantidad importante de recursos de red. La escalabilidad del número de réplicas también es un punto importante a evaluar
• También deben evaluarse los requisitos de consistencia de datos. La replicación síncrona puede afectar el rendimiento de escritura, pero ofrece una consistencia más fuerte. La replicación asíncrona brinda mejor rendimiento, aunque con una ligera posibilidad de pérdida de datos

[GN⁺]

Opiniones en Hacker News

• Hay una opinión de que este artículo es excelente, pero que, desde la perspectiva de alguien que intenta administrar bases de datos como desarrollador full-stack, le faltan casos de uso reales

  • Hay una pregunta sobre cómo verificar cuánto retraso lleva la réplica respecto al maestro
  • Se propone como forma de monitorear la réplica un trabajo simple de cron para revisar el estado
  • Como problema más complejo, hay una pregunta sobre cómo cambiar a la réplica si el servidor principal se cae
  • Existe la duda de si conviene hacer el cambio automáticamente o manualmente
  • Hay una inquietud sobre si se necesitan dos réplicas para evitar un escenario de split-brain
  • Hay una pregunta sobre cómo volver al estado original después del cambio

• Se afirma que la solución más sencilla para la replicación de PostgreSQL es un operador de Kubernetes

  • Se menciona CloudnativePG como ejemplo
  • Se explica que no solo se necesita replicación, sino también failover, recuperación, monitoreo, autorrecuperación y respaldos
  • Hay una pregunta sobre si existe alguna otra implementación gratuita/de código abierto fuera de Kubernetes

• Se considera que una de las razones para usar Kubernetes y Helm es que pueden resolver este problema

  • Se explica que con el paquete Bitnami PostgreSQL se puede configurar casi todo sin ajustes adicionales
  • Se explica que Postgres-ha crea un proxy y maneja las fallas de forma especializada para permitir failover sin interrupciones

• Se recomienda StackGres para usuarios de Kubernetes

• Finalmente, hay una opinión escéptica de que este artículo parece haber sido escrito por IA