Los principales objetivos de una configuración de múltiples centros de datos (o múltiples DC), independientemente de si el ecosistema de la base de datos es SQL (PostgreSQL, MySQL) o NoSQL (MongoDB, Cassandra), por nombrar solo algunos, son baja latencia para los usuarios finales, Alta disponibilidad y recuperación ante desastres. En el corazón de dicho entorno se encuentra la capacidad de replicar datos, de manera que garantice su durabilidad (como nota al margen, los parámetros de configuración de durabilidad de Cassandra son similares a los utilizados por PostgreSQL). Los diversos requisitos de replicación se discutirán a continuación, sin embargo, los casos extremos se dejarán a los curiosos para futuras investigaciones.
La replicación mediante el envío de registros asincrónico ha estado disponible en PostgreSQL durante mucho tiempo, y la replicación sincrónica introducida en la versión 9.1 abrió un nuevo conjunto de opciones para los desarrolladores de herramientas de administración de PostgreSQL.
Cosas a considerar
Una forma de comprender la complejidad de una implementación de múltiples DC de PostgreSQL es aprender de las soluciones implementadas para otros sistemas de bases de datos, teniendo en cuenta que PostgreSQL insiste en ser compatible con ACID.
Una configuración de varios centros de datos incluye, en la mayoría de los casos, al menos un centro de datos en la nube. Si bien los proveedores de la nube asumen la carga de administrar la replicación de la base de datos en nombre de sus clientes, generalmente no coinciden con las funciones disponibles en las herramientas de administración especializadas. Por ejemplo, con muchas empresas que adoptan soluciones de nube híbrida o multinube, además de su infraestructura local existente, una herramienta de múltiples centros de distribución debería ser capaz de manejar un entorno mixto de este tipo.
Además, para minimizar el tiempo de inactividad durante una conmutación por error, el sistema de administración de PostgreSQL debe poder solicitar (a través de una llamada API) una actualización de DNS, de modo que las solicitudes de la base de datos se enruten al nuevo clúster maestro.
Las redes que abarcan grandes áreas geográficas son conexiones de alta latencia y todas las soluciones deben comprometerse:olvídese de la replicación síncrona y use una principal con muchas réplicas de lectura. Consulte los estudios de clúster de AWS MongoDB y Variousnines/Galera para obtener un análisis detallado de los efectos de la red en la replicación. En una nota relacionada, una herramienta ingeniosa para probar la latencia entre ubicaciones es Wonder Network Ping Statistics.
Si bien la naturaleza de alta latencia de la WAN no se puede cambiar, la experiencia del usuario se puede mejorar drásticamente al garantizar que las lecturas se realicen desde una réplica de lectura cercana a la ubicación del usuario, aunque con algunas advertencias. Al alejar las réplicas del principal, las escrituras se retrasan y, por lo tanto, debemos eliminar la replicación síncrona. La solución también debe ser capaz de solucionar otros problemas, como la coherencia de lectura tras escritura y las lecturas secundarias obsoletas debido a la pérdida de conexión.
Para minimizar el RTO, los datos deben replicarse en un almacenamiento duradero que también pueda proporcionar un alto rendimiento de lectura y, según Citus Data, una opción que cumple con esos requisitos es AWS S3.
La noción misma de múltiples centros de datos implica que el sistema de administración de bases de datos debe poder presentar al DBA una vista global de todos los centros de datos y los diversos clústeres de PostgreSQL dentro de ellos, administrar múltiples versiones de PostgreSQL y configurar la replicación entre ellos.
Al replicar escrituras en centros de datos regionales, se debe monitorear el retraso de propagación. Si el retraso supera un umbral, debe activarse una alarma que indique que la réplica contiene datos obsoletos. El mismo principio se aplica a la replicación multimaestro asíncrona.
En una configuración síncrona, la alta latencia o las interrupciones de la red pueden provocar retrasos en el servicio de las solicitudes de los clientes mientras se espera que se complete la confirmación, mientras que en las configuraciones asíncronas existen riesgos de división del cerebro o rendimiento degradado durante un período prolongado. El cerebro dividido y los retrasos en las confirmaciones sincrónicas son inevitables, incluso con soluciones de replicación bien establecidas, como se explica en el artículo Clústeres de bases de datos distribuidas geográficamente con Galera.
Otra consideración es la compatibilidad con el proveedor:en el momento de redactar este documento, AWS no admite réplicas entre regiones de PostgreSQL.
Los sistemas de gestión inteligente deben monitorear la latencia de la red entre los centros de datos y recomendar o ajustar cambios, p. la replicación síncrona está perfectamente bien entre las zonas de disponibilidad de AWS donde los centros de datos están conectados mediante redes de fibra. De esa manera, una solución puede lograr una pérdida de datos cero y también puede implementar la replicación maestro-maestro junto con el equilibrio de carga. Tenga en cuenta que AWS Aurora PostgreSQL no ofrece actualmente una opción de replicación maestro-maestro.
Decida el nivel de replicación:clúster, base de datos, tabla. Los criterios de decisión deben incluir los costos de ancho de banda.
Implemente la replicación en cascada para solucionar las interrupciones de la red que pueden evitar que las réplicas reciban actualizaciones del maestro debido a la distancia geográfica.
Soluciones
Teniendo en cuenta todos los requisitos, identifique los productos que mejor se adapten al trabajo. Sin embargo, una nota de precaución:cada solución viene con sus propias advertencias que deben abordarse siguiendo las recomendaciones en la documentación del producto. Consulte, por ejemplo, el requisito de supervisión de BDR.
La documentación oficial de PostgreSQL contiene una lista de aplicaciones de código abierto no comerciales, y se puede encontrar una lista ampliada que incluye soluciones comerciales de código cerrado en la página wiki de replicación, agrupación en clústeres y agrupación de conexiones. Algunas de esas herramientas se revisaron con más detalle en el artículo Principales soluciones HA de clústeres de PG para PostgreSQL.
No existe una solución llave en mano, pero algunos productos pueden proporcionar la mayoría de las funciones, especialmente cuando se trabaja con el proveedor.
Aquí hay una lista no exhaustiva:
- Citus Data proporciona su propia compilación de PostgreSQL, mejorada con características empresariales impresionantes y una integración profunda con AWS.
- EnterpriseDB ofrece un amplio conjunto de servicios que se pueden combinar para cumplir con la mayoría de los requisitos. La mayor parte de la información se encuentra en Documentación del producto.
- Postgres-BDR es una poderosa herramienta de replicación diseñada específicamente para clústeres distribuidos geográficamente, sin embargo, no se integra con ningún proveedor de nube.
- ClusterControl viene con un impresionante conjunto de características para administrar PostgreSQL. También tiene una integración limitada en la nube.
- ElephantSQL funciona en muchos proveedores de nube. Sin embargo, no hay opción para una configuración local.
- Crunchy PostgreSQL para Kubernetes es un producto agnóstico de la nube creado en el nivel superior de PostgreSQL.
Conclusión
Como hemos visto, cuando se trata de elegir una solución de centro de datos múltiple de PostgreSQL, no existe una solución única para todos. A menudo, comprometerse es imprescindible. Sin embargo, una buena comprensión de los requisitos y las implicaciones puede ser de gran ayuda para tomar una decisión informada.
En comparación con los datos estáticos (solo lectura), una solución para bases de datos debe considerar la replicación de actualizaciones (escrituras). La bibliografía que describe las soluciones de replicación de SQL y NoSQL insiste en utilizar una única fuente de verdad para las escrituras con muchas réplicas a fin de evitar problemas como el cerebro dividido y la consistencia de lectura tras escritura.
Por último, la interoperabilidad es un requisito clave teniendo en cuenta que las configuraciones de varios centros de datos pueden abarcar centros de datos ubicados en las instalaciones y varios proveedores de nube.
