Síntomas comunes

  • La réplica está varios gigabytes o minutos por detrás del primario según el monitoreo
  • pg_stat_replication muestra write_lag, flush_lag o replay_lag distintos de cero y crecientes
  • pg_replication_slots muestra slots con wal_status = 'lost' o safe_wal_size negativo
  • La réplica sirve datos desactualizados a las aplicaciones de solo lectura
  • Alertas del sistema de monitoreo sobre replication delay superando el umbral
  • El disco del servidor primario se llena por retención de WAL (slot inactivo)

Riesgos para el negocio

  • Si el primario falla con la réplica atrasada, se pierde la diferencia de datos (supera el RPO)
  • Un slot de replicación inactivo puede llenar el disco del primario y causar caída total
  • Las aplicaciones de reportes y BI que leen de la réplica reciben datos inconsistentes
  • La réplica de DR no puede usarse como failover confiable si tiene minutos de atraso

Checklist técnico detallado

  • 1. Confirmar que el proceso WAL sender está activo en el primario Si pg_stat_replication no muestra la réplica o aparece con state = 'startup', el proceso de replicación no está establecido.
  • 2. Confirmar que walreceiver corre en la réplica Si el proceso no aparece, la réplica dejó de conectarse al primario.
  • 3. Detectar slots inactivos que acumulan WAL Un slot con active = false retiene WAL indefinidamente. Si safe_wal_size es negativo, el disco ya está en riesgo.
  • 4. Eliminar slot inactivo que ya no se necesita Solo si estás seguro de que el suscriptor no volverá. Esta acción es irreversible.
  • 5. Verificar conectividad de red y latencia entre nodos Si la latencia entre primario y réplica supera los 10-50ms, el lag puede acumularse en cargas altas.
  • 6. Revisar pg_hba.conf para permisos de replicación Debe existir una línea con el método de autenticación correcto para el usuario de replicación.
  • 7. Verificar límites de replicación en postgresql.conf Si hay más réplicas que max_wal_senders, las nuevas no podrán conectarse.
  • 8. Para replicación lógica: revisar estado de suscripciones srsubstate = 'r' indica que el worker está ejecutándose. 'd' significa que está inicializando datos.
  • 9. Revisar si hay apply delay intencional configurado recovery_min_apply_delay introduce un retraso deliberado en la réplica (para recuperación de errores humanos). Verifica que esté en 0 si no lo necesitas.
  • 10. Medir si la réplica puede alcanzar al primario sola Monitorea el lag cada 30 segundos durante 5 minutos. Si decrece, la réplica puede alcanzar sola. Si crece, hay un problema de capacidad.

Cuándo escalar el incidente a un DBA especialista

  • El slot de replicación tiene wal_status = 'lost' — el WAL ya no está disponible y la réplica debe reiniciarse desde cero
  • El disco del primario está lleno o por encima del 90% por retención de WAL de un slot inactivo
  • La réplica de DR lleva más tiempo de atraso que el RPO aprobado por el negocio
  • No hay forma de sincronizar sin un nuevo pg_basebackup (base completa desde el primario)
  • Hay un failover planificado próximo y la réplica no está en condiciones de asumir

Preguntas frecuentes

¿Por qué el replication lag aumenta durante el día y baja de noche?

Generalmente indica que la carga de escritura en el primario durante las horas pico supera la capacidad de la red o del proceso de aplicación en la réplica. La réplica no puede aplicar cambios tan rápido como llegan. Revisar max_wal_size, la latencia de red entre nodos y si el servidor de la réplica tiene suficiente I/O para el proceso de apply.

¿Un replication slot inactivo puede llenar el disco del primario?

Sí, y es uno de los riesgos más graves de PostgreSQL en producción. Un slot lógico o físico inactivo retiene todo el WAL generado desde el último punto de confirmación. Si la réplica o el suscriptor desaparece sin que se elimine el slot, el WAL se acumula hasta llenar el disco del primario, lo que puede causar una caída total del servidor. Monitorear safe_wal_size en pg_replication_slots debe ser parte del monitoreo diario.

¿La replicación lógica replica DDL (ALTER TABLE, CREATE INDEX)?

No. La replicación lógica de PostgreSQL replica DML (INSERT, UPDATE, DELETE, TRUNCATE desde v10) pero no DDL. Los cambios de esquema deben aplicarse manualmente en el suscriptor antes de que llegue el DML correspondiente. Si aplicas un ALTER TABLE en el primario sin hacerlo primero en el suscriptor, la replicación se romperá con un error. Esta es la diferencia crítica con la replicación física (streaming), que replica todo a nivel de bloque.

¿Puedo usar la réplica para lecturas mientras tiene lag?

Sí, la réplica sigue siendo legible mientras tiene lag. El problema es que las lecturas retornarán datos desactualizados por el tiempo del retraso. Si tu aplicación no tolera leer datos con minutos de atraso, debes medir el lag y decidir si redirigir lecturas al primario o bloquearlas temporalmente. No existe un mecanismo nativo en el protocolo de PostgreSQL para "no leer si lag > N"; debe implementarse en el pooler (PgBouncer) o en la capa de la aplicación.

Recursos relacionados