Cómo replicar datos de PostgreSQL en sitios remotos

En un entorno de base de datos ocupado con bases de datos de mayor tamaño, la necesidad de replicación de datos en tiempo real es algo común. Las aplicaciones a menudo necesitan que los datos de producción se repliquen en tiempo real en sitios remotos para análisis y otras necesidades críticas de operaciones comerciales.

Los DBA también deben asegurarse de que los datos se repliquen continuamente en los sitios remotos para cumplir con varios requisitos. Sin embargo, es posible que estos requisitos no siempre sean replicar toda la base de datos; también puede ser necesario replicar solo un subconjunto de los datos (como una tabla o un conjunto de tablas o datos de varias tablas usando un SQL para análisis, informes, etc.)

En este blog, nos centraremos en cómo replicar tablas en bases de datos remotas en tiempo real.

¿Qué es la replicación a nivel de tabla?

La replicación a nivel de tabla es el mecanismo de replicar los datos de una tabla específica o un conjunto de tablas desde una base de datos (origen) a otra base de datos (destino) alojada de forma remota en un entorno distribuido. La replicación a nivel de tabla garantiza que los datos de la tabla se distribuyan continuamente y se mantengan consistentes en los sitios replicados (objetivo).

¿Por qué utilizar la replicación a nivel de tabla?

La replicación a nivel de tabla es una necesidad esencial en entornos más grandes, complejos y altamente distribuidos. Según mi experiencia, siempre hubo la necesidad de replicar un conjunto de tablas de una base de datos de producción a un almacenamiento de datos para generar informes. Los datos deben replicarse continuamente para garantizar que los informes obtengan los datos más recientes. En entornos críticos, no se puede tolerar la obsolescencia de los datos, por lo que los cambios de datos que se producen en la producción deben replicarse inmediatamente en el sitio de destino. Esto puede ser un verdadero desafío para los DBA que tienen que pronosticar varios factores para garantizar una replicación de tablas eficiente y sin problemas.

Veamos algunos requisitos que resuelve la replicación a nivel de tabla:

• Los informes pueden ejecutarse en una base de datos en un entorno que no sea el de producción, como el almacenamiento de datos
• Un entorno de base de datos distribuida con aplicaciones distribuidas que extraen datos de varios sitios. En el caso de aplicaciones web o móviles distribuidas, la copia de los mismos datos debe estar disponible en varias ubicaciones para satisfacer las distintas necesidades de las aplicaciones, para las cuales la replicación a nivel de tabla podría ser una buena solución.
• Aplicaciones de nómina que necesitan que los datos de varias bases de datos ubicadas en diferentes centros de datos distribuidos geográficamente o instancias en la nube estén disponibles en una base de datos centralizada

Diversos factores que afectan la replicación a nivel de tabla:qué buscar

Como mencionamos anteriormente, los administradores de bases de datos deben tener en cuenta una variedad de componentes y factores en tiempo real para diseñar e implementar un sistema efectivo de replicación a nivel de tabla.

Estructura de la tabla

El tipo de tabla de datos que se adapta tiene un gran impacto en el rendimiento de la replicación. Si la tabla admite una columna BYTEA con datos binarios de mayor tamaño, el rendimiento de la replicación puede verse afectado. El impacto de la replicación en la red, la CPU y el disco debe evaluarse cuidadosamente.

Tamaño de datos

Si la tabla que se va a migrar es demasiado grande, la migración de datos inicial consumiría recursos y tiempo, los administradores de bases de datos deben asegurarse de que la base de datos de producción no se vea afectada.

Recursos de infraestructura

La infraestructura debe contar con los recursos adecuados para garantizar que se pueda construir un sistema de replicación confiable y estable. ¿Qué componentes de infraestructura se deben considerar?

CPU

La replicación de datos depende en gran medida de las CPU. Al replicar desde producción, las CPU no deben agotarse, lo que puede afectar el rendimiento de producción.

Red

Es fundamental para el rendimiento de la replicación. La latencia de la red entre las bases de datos de origen y de destino debe evaluarse mediante pruebas de estrés para garantizar que haya suficiente ancho de banda para que la replicación sea más rápida. Además, la misma red podría ser utilizada por otros procesos o aplicaciones. Por lo tanto, la planificación de la capacidad debe realizarse aquí.

Memoria

Debe haber suficiente memoria disponible para garantizar que se almacenen suficientes datos en caché para una replicación más rápida.

Actualizaciones de la tabla de origen

Si los cambios de datos en la tabla de origen son grandes, el sistema de replicación debe tener la capacidad de sincronizar los cambios con los sitios remotos lo antes posible. La replicación terminará enviando una gran cantidad de solicitudes de sincronización a la base de datos de destino, lo que puede consumir muchos recursos.

El tipo de infraestructura (centros de datos o nube) también puede afectar el rendimiento de la replicación y puede plantear desafíos. La implementación del monitoreo también podría ser un desafío. Si hay un retraso y faltan ciertos datos en la base de datos de destino, entonces podría ser difícil de monitorear y no puede ser sincrónico

Cómo implementar la replicación de tablas

La replicación a nivel de tabla en PostgreSQL se puede implementar usando una variedad de herramientas externas (comerciales o de código abierto) que están disponibles en el mercado o usando flujos de datos personalizados.

Echemos un vistazo a algunas de estas herramientas, sus características y capacidades...

Slony

Slony es una de las herramientas más populares que se utiliza para replicar de forma asíncrona tablas individuales específicas en tiempo real de una base de datos PostgreSQL a otra. Esta es una herramienta basada en Perl que realiza una replicación basada en activadores de cambios de datos de una tabla (o conjunto de tablas) desde una base de datos en un sitio a otro. Es bastante confiable y tiene años de historia de desarrollo. Aunque es altamente confiable, al ser una herramienta basada en disparadores, puede resultar complejo administrar las configuraciones de replicación.

Veamos algunas capacidades de Slony...

Ventajas de usar Slony

• Admite la metodología de replicación de maestro a esclavo o múltiples esclavos, lo que ayuda a mejorar la escalabilidad de lectura horizontal. En otras palabras, los esclavos no se pueden escribir
• Es posible configurar varios esclavos en un solo maestro y también es compatible con la metodología de replicación en cascada
• Admite mecanismos de conmutación y conmutación por error
• Se puede replicar un gran número de tablas en grupos, en paralelo
• Podemos replicar entre diferentes versiones principales de instancias de PostgreSQL, lo que convierte a Slony en una excelente opción para actualizaciones de bases de datos
• Fácil de instalar

Desventajas de usar Slony

• No es compatible con la replicación DDL
• Ciertos cambios en el esquema pueden interrumpir la replicación
• Los eventos de replicación se registran en la base de datos en tablas de registro específicas de Slony, lo que puede suponer una sobrecarga de mantenimiento.
• Si se va a replicar una gran cantidad de tablas con grandes conjuntos de datos, el rendimiento y el mantenimiento podrían plantear serios desafíos
• Al ser una replicación basada en disparadores, el rendimiento puede verse afectado

Bucardo

Bucardo es otro sistema de replicación de código abierto basado en Perl para PostgreSQL que admite la replicación asincrónica de datos de tabla específicos entre dos o más instancias de PostgreSQL. Lo que diferencia a Bucardo de Slony es que también es compatible con la replicación multimaestro.

Veamos los diferentes tipos de mecanismos de replicación que bucardo ayuda a implementar...

• Replicación multimaestro:las tablas se pueden replicar en ambas direcciones entre dos o más instancias de PostgreSQL y los datos transaccionales se sincronizarán bidireccionalmente
• Maestro-esclavo:los datos de las tablas en el maestro se replicarán en el esclavo de forma asincrónica y el esclavo estará disponible para operaciones de lectura
• Modo de copia completa (maestro-esclavo):Bucardo -/replica todos los datos del nodo maestro al esclavo eliminando todos los datos del esclavo

Ventajas de usar Bucardo

• Fácil de instalar
• Admite modos de replicación multimaestro, maestro-esclavo y de copia completa
• Se puede usar para actualizar bases de datos
• La replicación se puede realizar entre diferentes versiones de PostgreSQL

Desventajas de usar Bucardo

• Al ser una replicación basada en disparadores, el rendimiento puede ser un desafío
• Los cambios de esquema como los DDL pueden interrumpir la replicación
• Replicar una gran cantidad de tablas puede generar una sobrecarga de mantenimiento
• Los recursos de la infraestructura deben optimizarse para lograr un buen desempeño de la replicación; de lo contrario, no se podrá lograr la consistencia.

Replicación lógica de PostgreSQL

La replicación lógica es una función integrada revolucionaria de PostgreSQL que ayuda a replicar tablas individuales a través de registros WAL. Al ser una replicación basada en WAL (similar a Streaming Replication), pg logical se destaca en comparación con otras herramientas de replicación de tablas. La replicación de datos a través de registros WAL siempre es la forma más confiable y eficaz de replicar datos en la red. Casi todas las herramientas del mercado ofrecen replicación basada en activadores, excepto la replicación lógica.

Ventajas de usar la replicación lógica de PostgreSQL

• La mejor opción cuando desea replicar una sola tabla o un conjunto de tablas
• Es una buena opción si el requisito es migrar tablas específicas de varias bases de datos a una única base de datos (como almacenamiento de datos o bases de datos de informes) con fines analíticos o de informes
• Sin problemas de factores desencadenantes

Desventajas de usar la replicación lógica de PostgreSQL

• La mala gestión de archivos WAL/archivos WAL puede plantear desafíos para la replicación lógica
• No podemos replicar tablas sin claves primarias o únicas
• Los DDL y TRUNCATE no se replican
• El retraso de la replicación podría aumentar si se eliminan los WAL. Esto significa que la replicación y la administración de WAL deben complementarse entre sí para garantizar que la replicación no se interrumpa.
• Los objetos grandes no se pueden replicar

Aquí hay algunos recursos más para ayudarlo a comprender mejor la replicación lógica de PostgreSQL y las diferencias entre esta y la replicación de transmisión.

Contenedores de datos extranjeros

Si bien los contenedores de datos externos en realidad no replican los datos, quería resaltar esta característica de PostgreSQL porque puede ayudar a los administradores de bases de datos a lograr algo similar a la replicación sin replicar realmente los datos. Esto significa que los datos no se replican del origen al destino y las aplicaciones pueden acceder a los datos desde la base de datos de destino. La base de datos de destino solo tiene una estructura de tabla con un enlace que contiene los detalles del host y la base de datos de la tabla de origen y cuando la aplicación consulta la tabla de destino, los datos se extraen de la base de datos de origen a la base de datos de destino de forma similar a los enlaces de base de datos. Si los FDW pueden ayudar, entonces puede evitar por completo la sobrecarga de replicar los datos a través de la red. Muchas veces nos encontramos en una situación en la que los informes se pueden ejecutar en una base de datos de destino remota sin necesidad de que los datos estén presentes físicamente.

Los FDW son una gran opción en las siguientes situaciones -

• Si tiene tablas pequeñas y estáticas en la base de datos de origen, entonces no vale la pena replicar los datos
• Puede ser realmente beneficioso, si tiene tablas realmente grandes en la base de datos de origen y está ejecutando consultas agregadas en la base de datos de destino.

Ventajas de usar contenedores de datos externos

• Se puede evitar por completo la replicación de datos, lo que puede ahorrar tiempo y recursos
• Fácil de implementar
• Los datos extraídos son siempre los más recientes
• Sin gastos generales de mantenimiento

Desventajas de usar envoltorios de datos extranjeros

• Los cambios estructurales en la tabla de origen pueden afectar la funcionalidad de la aplicación en la base de datos de destino
• Depende en gran medida de la red y puede tener una sobrecarga de red significativa según el tipo de informes que se ejecuten
• Se espera una sobrecarga de rendimiento cuando las consultas se ejecutan varias veces, ya que cada vez que se ejecuta una consulta, los datos deben extraerse a través de la red desde la base de datos de origen y también pueden generar una sobrecarga de rendimiento en la base de datos de origen
• Cualquier carga en el origen puede afectar el rendimiento de las aplicaciones en la base de datos de destino

Conclusión

• La replicación de tablas puede servir para varios propósitos críticos para el negocio
• Puede admitir consultas paralelas distribuidas en entornos distribuidos
• Implementar sincrónico es casi imposible
• La infraestructura debe estar adecuadamente capacitada, lo que implica costos
• Una excelente opción para crear una base de datos centralizada e integrada con fines analíticos y de generación de informes