Saltar a contenido

Alta Disponibilidad PostgreSQL

PostgreSQL replica a través del WAL (Write-Ahead Log): todo lo que se modifica se escribe primero en el log de transacciones, y es ese log el que alimenta los standbys, el archivo de backup y la recuperación a un punto en el tiempo. Entender adónde va el WAL es entender toda la estrategia de disponibilidad de la base de datos.

Esta página trata de HA dentro del mismo centro de datos, que resuelve fallos de host, disco, rack y mantenimiento. Para reducir la latencia de aplicaciones en otra región y distribuir datos geográficamente, consulte PostgreSQL Multi-Región.

InteSys implementa la arquitectura en Kubernetes, con un operador PostgreSQL, o en máquinas virtuales, con un gestor de clúster apoyado en un store de consenso. Ambas se ejecutan en br-sp-1 (Cirion SAO1) y br-sp-2 (Equinix SP3).

Qué resuelve la HA — y qué no

Riesgo Alta disponibilidad Backup + WAL Standby en otra región
Fallo de host, disco o rack ✅ Resuelve ❌ ✅
Mantenimiento y actualización sin downtime ✅ Resuelve ❌ ✅
DELETE sin WHERE ❌ Replica el error ✅ Resuelve (PITR) ❌ Replica el error
Corrupción lógica ❌ ✅ Resuelve ❌
Pérdida del centro de datos completo ❌ ✅ Parcial ✅ Resuelve

Los dos números que definen el proyecto:

  • RPO — cuántos datos es aceptable perder. Con standby síncrono, cero.
  • RTO — cuánto tiempo hasta volver. Con promoción automática, decenas de segundos.

Topología en Kubernetes

Para aplicaciones que ya corren en Kubernetes, PostgreSQL vive en el propio clúster, bajo un operador PostgreSQL que trata el aprovisionamiento, la replicación, el failover, el archivado de WAL y el backup como estado declarativo.

Operador PostgreSQL, primario con standby síncrono y asíncrono, pooler de conexiones, volúmenes persistentes y archivado de WAL en almacenamiento de objetos

El operador reconcilia la topología; la aplicación usa los endpoints -rw y -ro, y el WAL se archiva fuera del clúster.

  • Services separados para lectura y escritura — el endpoint -rw siempre apunta al primario actual, el -ro distribuye la lectura entre los standbys. La aplicación no reconfigura nada durante un failover.
  • Pooler de conexiones integrado — PgBouncer en el camino, porque PostgreSQL usa un proceso por conexión y cientos de conexiones ociosas cuestan memoria real.
  • Anti-affinity obligatoria — un pod de base de datos por nodo físico.
  • Archivado continuo del WAL hacia almacenamiento de objetos, base del point-in-time recovery.
  • Volúmenes persistentes de baja latencia, con snapshot de volumen cifrado y retención definida.

Una base de datos en contenedor exige disciplina de almacenamiento

PostgreSQL en Kubernetes depende de almacenamiento persistente rápido y de una política de backup probada. Ejecutamos esta topología en la infraestructura InteSys, donde controlamos el storage y la red del clúster.

Topología en máquinas virtuales

Aplicación, par de HAProxy con VIP, primario con standby síncrono y asíncrono y un quórum de consenso responsable del leader lock, la promoción y el fencing

El gestor de clúster mantiene el leader lock en un store de consenso; el proxy sigue al líder y la aplicación conserva una única dirección.

  • Tres nodos de base de datos en hosts físicos distintos: primario, standby síncrono y standby asíncrono.
  • Store de consenso con número impar de miembros — es quien decide el líder, evitando que dos nodos se promuevan.
  • Proxy en par con VIP — HAProxy o equivalente, enrutando escritura al líder y lectura a los standbys.
  • Replicación por streaming con slots de replicación, para que el primario no descarte WAL que un standby aún no ha consumido.
  • Archivado de WAL y backup fuera de los nodos de base de datos.

¿Kubernetes o máquinas virtuales?

Criterio Kubernetes Máquinas virtuales
Aprovisionamiento de un clúster nuevo Minutos, declarativo Automatizado, pero más lento
Reconstrucción de standby Automática Automatizada con scripts
Extensiones y bibliotecas del sistema Limitadas a la imagen Instalación libre
Ajuste fino de kernel, I/O y huge pages Limitado por el nodo Total
Familiaridad del equipo del cliente Exige cultura Kubernetes Operación tradicional
Recomendado cuando La aplicación ya corre en Kubernetes Base legada, extensiones específicas, alto I/O

WAL, RPO y backup

Primario enviando WAL a un standby síncrono, un standby asíncrono y el archivo de WAL en almacenamiento de objetos, con prueba de restauración

El standby síncrono define el RPO; el archivo de WAL permite volver a cualquier punto en el tiempo; la prueba de restauración es lo que convierte el backup en garantía.

Configuración Confirmación del COMMIT RPO Coste
synchronous_commit = off Inmediata, sin esperar al disco Segundos Escritura más rápida, riesgo real
Asíncrona (predeterminada) Tras la escritura local del WAL Segundos en el standby Menor latencia
Standby síncrono Tras la confirmación de al menos un standby Cero Algunos milisegundos por transacción
Quórum síncrono (ANY 1 OF 2) Tras la confirmación del primer standby Cero, sin depender de un nodo específico Recomendado para bases críticas

Un único standby síncrono puede detener la escritura

Si la base exige confirmación de un standby específico y ese nodo cae, el primario deja de aceptar escritura. Por eso configuramos quórum (ANY 1 OF 2): basta con que uno de los dos standbys confirme.

Cómo funciona el failover

Secuencia de failover: expiración del leader lock, fencing del primario antiguo, promoción del standby síncrono, redirección del pooler y reincorporación del nodo antiguo

  1. Detección — el leader lock expira en el store de consenso; la decisión es del quórum, no de un observador aislado.
  2. Fencing — el primario antiguo se degrada y se aísla antes de cualquier promoción, evitando el split-brain.
  3. Promoción — el standby síncrono asume; como ya confirmó las transacciones, no hay pérdida de datos.
  4. Redirección — el pooler pasa a apuntar al nuevo primario, sin cambios en la aplicación.
  5. Reincorporación — el nodo antiguo vuelve como standby tras alinearse con la nueva línea de tiempo del WAL.

Monitorización que acompaña al clúster

  • replication lag en bytes y en segundos, por standby;
  • estado del leader lock e histórico de promociones;
  • slots de replicación inactivos — la causa más común de disco lleno en el primario;
  • transacciones largas, bloat y progreso del autovacuum;
  • conexiones en uso frente al límite del pooler;
  • éxito del backup y de la restauración de prueba.

Soberanía de datos

Todo el dato de este clúster permanece en Brasil. Las dos regiones de InteSys son brasileñas — br-sp-1 (Cirion SAO1), en Cotia/SP, y br-sp-2 (Equinix SP3), en el área metropolitana de São Paulo — y el dato solo sale del país si el cliente lo pide.

  • Residencia de datos en Brasil — nodos primarios, réplicas, archivos de log de transacciones y backups permanecen en datacenter brasileño, sobre infraestructura operada por InteSys.
  • LGPD sin transferencia internacional — en la configuración estándar no existe transferencia internacional de datos personales que documentar, ni base legal adicional que construir.
  • Jurisdicción única — infraestructura brasileña, contrato brasileño y operación por equipo brasileño, sin la exposición a legislación extranjera de acceso a datos que alcanza a proveedores con sede fuera del país.
  • Latencia como consecuencia — mantener el dato cerca del usuario brasileño es, a la vez, requisito de cumplimiento y ganancia de rendimiento.
  • Sacar datos del país es una decisión explícita del cliente — cualquier copia fuera de Brasil existe solo cuando se solicita, y solo en volumen cifrado.

Snapshot de volumen cifrado

Además del backup base con archivado continuo de WAL, el clúster en Kubernetes puede usar snapshots de volumen (VolumeSnapshot vía CSI): una copia del volumen entero, tomada en segundos, sin recorrer la base.

  • Snapshot consistente — el operador coordina el flush y congela la escritura antes de disparar el snapshot, para que la restauración no dependa de recuperación tras fallo.
  • Siempre en volumen cifrado — el dato está cifrado en reposo y el snapshot hereda ese cifrado; la clave la gestiona InteSys o la aporta el cliente.
  • Copia cifrada en tránsito — la replicación del snapshot hacia otro destino viaja cifrada y se almacena cifrada en el destino.
  • Retención y restauración probada — política de retención definida y restauración ejercitada periódicamente; un snapshot que nunca se restauró es una hipótesis, no un backup.
  • Recuperación rápida — el snapshot devuelve el volumen entero en minutos; el backup base más el archivo de WAL sigue siendo lo que permite volver a cualquier punto en el tiempo.
Destino del snapshot Cuándo elegirlo
br-sp-1 y br-sp-2 (Brasil) Estándar. Mantiene la residencia de los datos y el tratamiento íntegramente bajo la LGPD.
Otro país Aislamiento geográfico del backup, exigencia corporativa o plan de continuidad que pide la copia fuera del territorio brasileño. Pasa a existir transferencia internacional, documentada en el diseño de la solución.

El destino es elección del cliente, no un valor por defecto de la plataforma

Ningún snapshot sale de Brasil por iniciativa nuestra. La copia en otro país se configura solo a pedido, con la base legal de la transferencia registrada junto al diseño del clúster.

Cómo lo implementa InteSys

  1. Dimensionamiento — volumen, perfil de escritura, extensiones en uso, requisitos de RPO/RTO.
  2. Topología — Kubernetes o VMs, número de standbys y modo de replicación.
  3. Aprovisionamiento — nodos en hosts físicos distintos, almacenamiento dedicado, parámetros de PostgreSQL ajustados a la carga.
  4. Capa de acceso — pooler y endpoints separados de lectura y escritura.
  5. Archivado y backup — WAL continuo y backup completo en almacenamiento de objetos, fuera de los nodos.
  6. Prueba de fallo — tumbamos el primario en un entorno controlado y medimos el RTO real.
  7. Observabilidad y alertas — métricas, paneles y alertas conectados al equipo de operación.
  8. Runbook — procedimiento documentado para la intervención humana cuando sea necesaria.

Punto de partida recomendado

Tres nodos, quórum síncrono ANY 1 OF 2, pooler con endpoints -rw/-ro y WAL archivado fuera del clúster. RPO cero, promoción automática y capacidad de volver a cualquier punto en el tiempo. Hable con nuestro equipo para dimensionar el clúster.

Próximos Pasos