Mejores prácticas de HA

Practique el failover trimestralmente; las aplicaciones deben reintentar errores transitorios. Estas reglas mantienen los clústeres de Patroni realmente disponibles durante fallos reales.

Cómo usar esta lista

• Aplique en el diseño del clúster y después de cada actualización de Patroni/etcd.
• Úselo como una lista de verificación para la preparación de simulacros.
• Comparta las secciones de enrutamiento y reintento con los equipos de aplicaciones.
• Almacene el RTO medido de los simulacros junto a cada elemento donde sea relevante.

A - Arquitectura

• Mínimo tres nodos PostgreSQL para HA en producción. Un líder más dos réplicas.
• Quórum de etcd o Consul de recuento impar (3 o 5). Nunca DCS de dos nodos.
• Separe etcd de los hosts de PostgreSQL cuando sea posible. Reduce fallos correlacionados.
• Habilite el watchdog de Linux de Patroni (mode: automatic). Reduce la ventana de split-brain.
• Establezca maximum_lag_on_failover a partir de la latencia medida en bytes de la SLA. Bloquee la promoción de datos obsoletos.

B - Enrutamiento y Pooling

• Las aplicaciones se conectan a través de un nombre de host de escritura estable a través de HAProxy + PgBouncer. Sin IP principal en la configuración.
• HAProxy verifica la salud de Patroni REST /primary, no solo TCP 5432. Evita el enrutamiento incorrecto de réplicas.
• Ejecute RECONNECT o recargue PgBouncer en el callback de failover de Patroni. Limpie backends obsoletos.
• Documente los puntos de conexión de lectura y escritura por separado. El "read-your-writes" necesita la ruta principal.
• Mantenga server_lifetime lo suficientemente bajo para el failover (300s o menos). Límite de conexión obsoleta.

C - Aplicaciones

• Reintente errores de conexión transitorios con retroceso exponencial. Durante la ventana de failover.
• Establezca connect_timeout en las cadenas de conexión. Falle rápido, reintente antes.
• Use claves de idempotencia para escrituras durante las ventanas de reintento. Evite efectos secundarios duplicados.
• Alerta sobre la tasa de error de la base de datos de la aplicación durante el cambio de líder. La base de datos puede estar activa mientras las aplicaciones no lo están.
• Pruebas de carga con ruta de proxy, no con conexiones directas a nodos. Coincide con el comportamiento de producción.

D - Operaciones

• Simulacro de failover no planificado trimestral en staging; anual en producción con aprobación. Registre el RTO.
• Ejecute patronictl switchover antes de los parches del SO en el principal. Migración de líder planificada.
• Nunca use pg_ctl promote fuera de Patroni. Evite la desincronización del estado de DCS.
• patronictl pause con límite de tiempo; documente el propietario. Reanude el failover automático con prontitud.
• Pagine ante el cambio de rol de líder de Patroni y la pérdida de quórum de etcd. El failover automatizado aún necesita conciencia humana.

E - Alineación de Replicación

• Ranura física por réplica; monitoree ranuras inactivas. Seguridad del disco WAL.
• Como máximo un socio de sincronización a menos que la latencia esté modelada. Consulte las mejores prácticas de replicación en streaming.
• La replicación y las copias de seguridad son complementarias. HA no reemplaza pg_dump o pgBackRest.
• Después de una actualización importante, reconstruya el clúster de Patroni en una única versión principal. Sin miembros mixtos de 17/18.

Preguntas frecuentes

Relacionado

• Conceptos básicos de HA - Introducción a RTO/RPO
• Patroni y etcd/Consul - configuración
• Proxies de conexión - HAProxy y PgBouncer
• Pruebas de HA - manual de simulacros

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+.