Streaming replication de PostgreSQL (primary + standby)

Añade uno o varios hot standby a un primary ya instalado con pg_basebackup (usuario de replicación, pg_hba, replication slot, modo asíncrono o síncrono ANY/FIRST, supervisión del retraso) y genera los runbooks de operación de este cluster sin Patroni: switchover planificado, failover manual (pg_promote), reincorporación del antiguo primary con pg_rewind, reconstrucción de un standby, standby en cascada y standby con retraso, limpieza de slots, cambio de la configuración síncrona. El failover no es automático, lo realiza el DBA; para failover automático, pg-patroni; para flujo de datos a nivel de tabla o entre versiones, pg-logical-repl.

Topología: 1 primary + 1..N standby

Escenarios

• Instalación: añadir standby al primary — Se añaden uno o varios hot standby a un primary ya instalado con pg_basebackup (slot, síncrono/asíncrono, supervisión). El primary sigue abierto; la copia inicial genera carga de disco y de red en el primary.
• Switchover planificado (cambio de rol, sin pérdida de datos) — Mantenimiento planificado: el primary se detiene de forma limpia, se promueve el primer standby y el antiguo primary vuelve como standby. Sin pérdida de datos; la interrupción de escrituras suele durar menos de un minuto.
• Failover manual (el primary ha caído, promover el standby) — El primary ha caído o no es accesible: se aísla el antiguo primary (fencing) y se promueve a mano el standby más actualizado. En modo asíncrono pueden perderse las últimas transacciones.
• Reincorporar el antiguo primary como standby con pg_rewind — Tras un failover, el antiguo primary se resincroniza con el nuevo primary mediante pg_rewind y se reincorpora como standby; es mucho más rápido que una copia completa.
• Añadir un nuevo standby alimentado por un standby (cascada) — El nuevo standby recibe el WAL del primer standby en lugar del primary: en un centro de datos remoto o en una topología con muchos standby se reduce la carga de red y de envío de WAL del primary. El primary no se ve afectado.
• Configurar un standby con retraso (delayed standby) — Standby que aplica el WAL horas después (recovery_min_apply_delay): sirve para recuperar datos borrados por error sin restaurar desde backup. No es candidato a failover.
• Reconstruir un standby desde cero — El standby se ha quedado atrás, su WAL se ha eliminado o está dañado: se aparta el directorio de datos y se vuelve a copiar desde el primary. El primary no se ve afectado.
• pg_wal crece, el disco se llena (limpieza de slots sin uso) — Se localiza la causa de la acumulación de WAL (slot inactivo, fallo de archivado, wal_keep_size); se elimina el replication slot que ya no se usa y se recupera el espacio de WAL. El primary sigue abierto.
• Añadir / quitar un standby síncrono (synchronous_standby_names) — Reescribe la lista síncrona según el modo del formulario (ANY/FIRST, k) o vuelve a modo asíncrono; se aplica con reload, sin restart. Un valor incorrecto puede dejar los commits en espera; por eso se comprueba antes.

Antes de empezar

• El primary … está instalado con la guía pg-install y en funcionamiento (PostgreSQL …, PGDATA …, puerto …).
• En los servidores standby solo se ha hecho la fase de preparación del sistema operativo de la guía pg-install (hostname, chrony, sysctl, THP). El cluster no se ha creado; el software se instala en esta guía.
• La misma familia de sistema operativo, la misma arquitectura (x86_64/aarch64) y la misma versión principal de PostgreSQL (…) en todos los servidores. El standby es una copia física exacta del primary.
• En el standby hay para … al menos un 20 % más de espacio libre que el tamaño de los datos del primary.
• Los servidores se alcanzan entre sí por el puerto …; los hostnames se resuelven y los relojes están sincronizados por NTP.
• El puerto … está abierto entre los servidores en el firewall (si pg-install solo abrió la red de aplicación, añada también las IP de replicación).
• En Debian/Ubuntu los ficheros de configuración están fuera del directorio de datos (/etc/postgresql), por lo que pg_basebackup no los copia; dispone de acceso scp como root (o con un usuario con sudo) desde el standby al primary, o moverá los ficheros a mano.
• El directorio de datos del antiguo primary está intacto y el servidor puede arrancar (tras una avería de disco hay que reconstruir con pg_basebackup, no con pg_rewind).
• …Se ha elegido un momento adecuado para la copia inicial (pg_basebackup), que genera carga en el primary.…La ventana de mantenimiento está abierta; los equipos de aplicación conocen la breve interrupción de escrituras.…Se ha comprobado que el primary es realmente inaccesible y está garantizado que no volverá a aceptar escrituras como un segundo primary (fencing).…El nuevo primary está sano y acepta escrituras.…El nuevo servidor (…) está listo: la preparación del sistema operativo está hecha, … está vacío y tiene espacio suficiente; la copia inicial generará carga en el origen (…).…Mientras se reconstruye …, su carga de lectura puede pasarse a los demás servidores; la copia generará carga en el primary.…Se vigila la ocupación del disco; antes de eliminar el slot se ha hablado con el responsable del standby que lo usa.…El cambio síncrono se hace en una ventana de mantenimiento; los equipos de aplicación están avisados porque cambiará la latencia de commit.…

Fases de la guía

• Preparación (todos los servidores) — Añadir los nombres de los servidores a /etc/hosts · Añadir el repositorio PGDG · Añadir el repositorio PGDG · Instalar el software de servidor PostgreSQL · Preparar el directorio de datos · Crear la configuración del cluster y vaciar el directorio de datos
• Preparación de la replicación en el primary — Comprobar el requisito previo de pg_rewind · Escribir el fichero de configuración de replicación · Cargar la configuración · Crear el usuario de replicación · Asignar la contraseña del usuario de replicación · Añadir las reglas de replicación a pg_hba.conf …
• Instalación del standby (pg_basebackup) — Probar la conexión de replicación con el primary · Copiar el primary: … · Copiar los ficheros de configuración desde el primary · Arrancar el standby
• Verificación — Comprobar el estado de la replicación en el primary · Comprobar el receptor de WAL en el standby · Escribir datos de prueba en el primary · Leer los datos de prueba en el standby · Eliminar la tabla de prueba
• Activar la replicación síncrona — Escribir el fichero de configuración síncrona · Cargar el parámetro en todos los servidores · Verificar el estado síncrono
• Supervisión y tareas posteriores a la instalación — Consulta de supervisión del retraso (primary) · Consulta de supervisión del retraso (standby) · Supervisión de la ocupación de los slots · Cadena de conexión de la aplicación · Adaptar el backup al standby
• Comprobaciones previas al switchover — Comprobar el estado de los standby · Verificar que el nuevo primary está preparado · Comprobar .pgpass y pg_hba en el antiguo primary
• Switchover — Detener el antiguo primary de forma limpia · Verificar que el nuevo primary recibió el último WAL · Promover … · Crear los slots en el nuevo primary · Configurar el antiguo primary como standby · Arrancar el antiguo primary como standby …
• Failover manual — Detener y deshabilitar el antiguo primary (fencing) · Identificar el standby más actualizado · Promover … · Quitar temporalmente la espera síncrona · Crear los slots en el nuevo primary · Apuntar los demás standby al nuevo primary: … …
• Reincorporar el antiguo primary con pg_rewind — Comprobar el slot y la regla de conexión en el nuevo primary · Verificar que el antiguo primary está detenido · Ejecución de prueba de pg_rewind · Ejecutar pg_rewind · Completar la configuración del standby · Arrancar el antiguo primary como standby …
• Acumulación de WAL en pg_wal y limpieza de slots — ¿Por qué crece pg_wal? · Encontrar el propietario del slot · Eliminar el slot sin uso: … · Eliminar un slot: rellene el formulario · Verificar que se ha recuperado el espacio de WAL · Evitar que se repita: límite superior y supervisión
• Cambio de standby síncrono — Estado síncrono actual · Comprobación de seguridad: ¿hay suficientes standby conectados? · Escribir el fichero de configuración síncrona · Quitar la configuración síncrona (volver a asíncrono) · Cargar el parámetro en todos los servidores · Verificar el nuevo estado