Mejores Prácticas de Replicación por Streaming

Un máximo de un socio síncrono a menos que comprendas la latencia. Estas reglas mantienen la replicación física confiable bajo failover y picos de carga.

Cómo Usar Esta Lista

• Aplica durante el diseño del clúster y cada adición de standby.
• Verifica cada elemento después de cambios de configuración de Patroni o actualizaciones del sistema operativo.
• Úsala como una lista de verificación para simulacros antes de un failover.
• Combínala con alertas de Grafana sobre el lag de bytes y slots inactivos.

A - Topología y Slots

• Un slot de replicación física por standby de larga duración. Los slots previenen la pérdida de WAL durante interrupciones.
• Nombra los slots con el nombre del host o miembro de Patroni. Los operadores saben qué consumidor arreglar.
• Establece max_slot_wal_keep_size como una válvula de seguridad de disco. Complementa, no reemplaza, la higiene de los slots.
• Limita la profundidad de cascada a dos saltos. Saltos adicionales multiplican el lag y los dominios de fallo.
• Dirige los standbys a candidatos de failover. Los enlaces en cascada permanecen de solo lectura a menos que el runbook diga lo contrario.

B - Sincronización y Durabilidad

• Como máximo un socio síncrono en producción. Más socios necesitan un presupuesto explícito de latencia WAN.
• Empareja application_name con synchronous_standby_names. Los standbys con nombres incorrectos nunca se unen al quórum.
• Documenta el comportamiento cuando el socio síncrono está caído. Patroni debería degradar el socio síncrono o las operaciones deberían relajar el quórum rápidamente.
• Evita synchronous_commit = off global. Limita las degradaciones de durabilidad solo a roles de batch.
• Prefiere remote_write sobre remote_apply a menos que las aplicaciones lean desde el standby después del commit. Menor latencia de commit.

C - Monitoreo y Alertas

• Alerta sobre el lag de bytes de pg_stat_replication, no solo el lag de tiempo. Las cargas de trabajo inactivas ocultan el retraso en el hueco LSN.
• Notifica cuando el último standby síncrono deja de hacer streaming. Las escrituras pueden detenerse en modo síncrono.
• Alerta sobre slots inactivos que retienen > 512 MiB de WAL. Los slots huérfanos llenan los discos.
• Monitorea la tasa de generación de WAL en el primario. Los picos predicen la presión de replicación.
• Rastrea el rol de líder de Patroni por separado del lag de replicación. Los clientes pueden estar en el host incorrecto mientras el lag parece normal.

D - Seguridad y Redes

• Usa scram-sha-256 para usuarios de replicación en pg_hba.conf. Sin contraseñas en texto plano en los archivos de configuración.
• TLS en la replicación (sslmode=verify-full en primary_conninfo). Cifra enlaces entre zonas y regiones.
• Usuario de replicación dedicado con privilegios mínimos. Solo login REPLICATION, sin superusuario.
• Rol de monitoreo separado para consultas de salud. Sin superusuario para verificaciones cron.

E - Operaciones y Simulacros

• Ensaya la promoción de standby trimestralmente. Mide el RTO con pruebas de reconexión de aplicaciones.
• Verifica que PgBouncer o HAProxy enruten al nuevo primario después de la promoción. El pool no arregla DNS por sí solo.
• Rellena el standby desde pg_basebackup después de wal_status = lost. La captura incremental no puede arreglar el WAL perdido.
• Mantén alineadas las versiones mayores del primario y standby. La replicación física no cruza versiones mayores.

Preguntas Frecuentes

Relacionados

• Conceptos Básicos de Replicación por Streaming - guía de configuración
• Síncrona vs. Asíncrona - compensaciones de RPO
• Slots de Replicación - mecánicas de retención
• Mejores Prácticas de Alta Disponibilidad - simulacros de failover

Versiones de la pila: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.