pgactive - extensión de replicación activo-activo para Postgres

• Una extensión de replicación activo-activo para PostgreSQL creada y publicada por AWS
• Cuando se necesita escribir y modificar datos en varias instancias de PostgreSQL, en lugar del modelo tradicional activo-en espera donde una sola instancia acepta cambios, permite construir una arquitectura con cambios simultáneos y replicación entre múltiples instancias
• Es adecuada para escenarios como bases de datos de alta disponibilidad en varias regiones, minimizar la latencia de escritura, actualizaciones blue/green de aplicaciones y migración bidireccional de datos
• Aprovecha la replicación lógica para admitir detección de conflictos, resolución de conflictos de escritura y conversión de formato de la base de datos de destino

Concepto de replicación activo-activo

• La replicación (Replication) es una tecnología para sincronizar cambios entre bases de datos
• La estructura tradicional activo-en espera de PostgreSQL permite que solo una instancia acepte cambios y las demás sean de solo lectura, por lo que un solo lugar actúa como fuente única de datos
• pgactive ofrece una topología de replicación activo-activo, lo que permite escribir datos simultáneamente en varias instancias
• Este enfoque es adecuado para entornos que requieren varios puntos de escritura, como despliegues multirregión o migraciones bidireccionales
• En el modelo activo-activo se requiere una gestión adicional de conflictos, latencia y ciertas limitaciones funcionales

Tecnología clave: replicación lógica

• La replicación lógica (Logical Replication) transmite los datos en un formato que puede ser interpretado por sistemas externos
• Mediante la replicación lógica se pueden implementar diversas funciones adicionales en la base de datos de destino, como detección de conflictos, resolución de conflictos de escritura y transformación de consultas
• PostgreSQL introdujo la replicación lógica básica en la versión 10 en 2017, pero la replicación activo-activo requiere capacidades adicionales
• Debido a las características de diseño de PostgreSQL, estas funciones pueden desarrollarse y aplicarse en forma de extensión (extension)
• La comunidad de desarrollo de PostgreSQL también está incorporando gradualmente estas capacidades al proyecto principal

[GN⁺]

Comentarios en Hacker News

• Hago un repaso de la evolución de BDR, pglogical, pgactive y Postgres Distributed (PGD) a partir de lo que escuché de colegas de los equipos de 2nd Quadrant y EDB
  Lo primero que salió, y que todavía sigue siendo open source, es BDR1 (enlace), y pgactive está basado en eso
  BDR2 fue una reescritura de BDR1 como software de código cerrado, y al final fue descartado
  Luego salieron pglogical v1 y v2 (ambos open source, enlace), y de esos, v1 fue ampliamente modificado e integrado en Postgres 10
  Basándose en la experiencia con la replicación lógica de Postgres 10, 2nd Quadrant empezó a desarrollar pglogical v2, y de ahí también salió pgEdge
  Después, 2nd Quadrant creó las versiones cerradas pglogical v3 y BDR v3, y al combinarlas nació BDR v4
  Más tarde, el nombre del producto BDR cambió a Postgres Distributed (PGD, enlace)
  Tras la adquisición de 2ndQuadrant por parte de EDB, EDB lanzó PGD v6
  • En PostgresPro también existe un sistema separado de replicación multi-master enlace a la documentación
  • Preguntan si PGDv6 sigue siendo de código cerrado
• Este sistema usa la replicación lógica de Postgres para transmitir los cambios de una instancia a otra
  Cuando ocurre un conflicto, se aplica finalmente el valor escrito más recientemente según la marca de tiempo
  El historial de conflictos queda registrado en una tabla especial llamada pgactive_conflict_history, así que es posible revisar el historial o resolverlos manualmente
  Para más detalles y documentación, ver aquí
  • Preguntan si esto cuenta como multi-master replication
    Sería interesante si esa funcionalidad pudiera aceptarse oficialmente en Postgres
  • Desde la perspectiva del usuario, quisiera saber si sus escrituras se aprueban de inmediato o si simplemente terminan convergiendo con el tiempo
• Preguntan si alguien ha usado recientemente la base de datos de Bloomberg (comdb2) directamente
• Como tema relacionado pero algo tangencial, preguntan si existe alguna forma de hacer "replicación con escritura local habilitada (basada en read replicas)"
  Por ejemplo, quieren usar una base de datos secundaria que lea datos de producción o staging, pero que solo pueda modificarse localmente y cuyos resultados no se reflejen de vuelta hacia upstream
  Actualmente, lo común es crear snapshots enviando periódicamente dumps de datos o consultas con scripts (como cron), guardarlos en S3 y luego descargarlos localmente para restaurar los datos
  Este método suele funcionar bien, pero a veces la construcción de índices tarda demasiado
  • Como referencia, por temas de información personal u otros datos sensibles, puede ser riesgoso que datos así entren directamente a entornos de staging o desarrollo
    Por sus implicaciones legales y éticas, la mayoría de las empresas no recomienda este enfoque
  • Si se usa la replicación lógica de Postgres con filtros, es posible hacer replicación unidireccional, y al liberar el replication slot se pueden hacer cambios locales libremente
    Así se pueden modificar tablas locales sin afectar al primary
  • También recomiendan mantener una base de datos local "limpia" como respaldo, y clonar esa copia cada vez que se necesite para una base de datos de desarrollo; así la copia es muy rápida sin reconstruir índices
    Recomiendan el comando createdb --template
  • Preguntan cómo se manejan los conflictos entre escrituras locales y actualizaciones remotas
    No se les ocurre una estrategia de merge que funcione para todos los casos
  • Hasta donde saben, en una configuración de replicación lógica de Postgres este es el comportamiento estándar
    No es que se bloquee la escritura en la réplica, sino que simplemente el resultado no se propaga a otros lugares
• Siempre hay que recordar que el término "conflict resolution" al final significa "romper la durabilidad al descartar datos ya confirmados y aprobados"
  Lo mejor es diseñar la arquitectura para que no haya superposición en las áreas de datos que se escriben entre todas las instancias activas
  En esos casos, herramientas como pgactive pueden ser útiles
  O bien, lo correcto es usar desde el inicio una base de datos distribuida (como Yugabyte)
  • La documentación oficial también recomienda, como método para evitar conflictos, dividir el schema por master para que "cada master sea el único writer de cada schema"
    Proponen que todos los master puedan leer todos los schemas, pero que al escribir cada uno se encargue solo del suyo
    Preguntan si, además del schema, también podría usarse algo como particiones para distribuir responsabilidades
• Esto hace pensar por qué AWS construyó esto
  No se les ocurre que usen directamente esta funcionalidad en sus propios productos
  RDS usa block replication, y Aurora usa su propia replicación SAN
  Suponen que tal vez la intención era usarlo en algo como DMS
  • Tal vez tenga que ver con Aurora DSQL, lanzado recientemente
  • En realidad no les queda muy clara su gran utilidad
    Se preguntan por qué habría que hacer esto en una base de datos relacional fuerte en ACID
  • Según entienden, la replicación SAN de Aurora no se usa para cross region replication
  • En el readme de ese repositorio también se indica que el "caso de uso principal es construir clústeres de base de datos de alta disponibilidad Multi-Region"
  • En realidad, dicen que ya era una funcionalidad disponible en RDS Postgres desde hace 2 años (enlace relacionado)
    Pero hace 1 mes hubo noticias de que se publicó oficialmente como open source para la comunidad (anuncio oficial)
• Han operado varios clústeres con repmgr y patroni para lograr entornos completamente sin downtime, y dicen que este plugin realmente sería lo último que querrían instalar
  Para poder dormir tranquilos por la noche, preferirían evitarlo al máximo
• Casualmente, hace poco estaban buscando una forma sencilla de crear un clúster Postgres de alta disponibilidad con "failover automático, recuperación de nodos y point-in-time recovery"
  Parece que la combinación patroni+etcd+haproxy se recomienda mucho, y viendo a quienes ya la usaron hablar con tanto entusiasmo, debe haber buenas razones
  Aun así, al ver archivos de ejemplo con docker compose, les pareció un poco intimidante
  pgpool parece más simple porque solo hay que ponerlo delante de cada postgres
  Quieren recomendaciones o experiencias reales de gente que use Postgres en producción
  Su objetivo es montar, con docker compose y de la forma más simple posible, un clúster con alta disponibilidad, (como mínimo) sin pérdida de datos y con point-in-time recovery
  • Preguntan si lo que buscan es una herramienta como Barman
  • Están usando cloudnativepg, y con eso la mayoría de las funciones necesarias ya les funciona directamente
• Comparten por si hubiera más material sobre pgactive o casos relacionados
  <i>Pgactive: Active-Active Replication Extension for PostgreSQL on Amazon RDS</i>
  Post de Hacker News (post de octubre de 2023, 1 comentario)
• Parece ser asíncrono, y probablemente haya problemas importantes con el aislamiento de transacciones
  • La postura final es que, en última instancia, todo es un trade-off
    Es decir, según cada situación, hay que aceptar sus ventajas y desventajas