Cómo optimizar la replicación lógica de PostgreSQL

La replicación lógica o Pglogical es un mecanismo de replicación basado en WAL a nivel de tabla que replica los datos de tablas específicas entre dos instancias de PostgreSQL. Parece haber una confusión entre "pglogical" y "Replicación lógica". Ambos proporcionan el mismo tipo de mecanismo de replicación con algunas diferencias en características y capacidades. La replicación lógica se introduce en PostgreSQL-10 como una función integrada, a diferencia de pglogical, que es una extensión. “Pglogical”, con desarrollos continuos y continuos, sigue siendo la única opción para implementar Logical Replication para aquellos entornos que utilizan versiones de PostgreSQL anteriores a la 10. Eventualmente, todas las funciones que forman parte de pglogical serán parte de Logical Replication. En otras palabras, pglogical (extensión) se convirtió en Logical Replication (función integrada). La ventaja básica de la replicación lógica es que no necesita que se instale/cree ninguna extensión, lo que a su vez es beneficioso para aquellos entornos en los que la instalación de extensiones está restringida.

Este blog se centrará en optimizar la replicación lógica. Eso significa que los consejos y técnicas de optimización destacados en este blog se aplicarán tanto a la replicación lógica como a la lógica.

La replicación lógica es una replicación basada en WAL que es la primera de su tipo. Como DBA, este sería un mecanismo de replicación mucho más confiable y eficaz en comparación con otras soluciones de replicación basadas en activadores. Los cambios realizados en las tablas que forman parte de la replicación pglogical se replican en tiempo real a través de registros WAL, lo que lo hace altamente eficiente y no complejo. Todos los demás mecanismos de replicación en el mercado se basan en disparadores, lo que puede plantear desafíos de rendimiento y mantenimiento. Con la incorporación de la replicación lógica, la dependencia de la replicación basada en disparadores casi ha desaparecido.

Hay otros blogs que explican con bastante detalle cómo configurar la replicación lógica.

En este blog, la atención se centrará en cómo optimizar la replicación lógica.

Optimización de la replicación lógica

Para empezar, el comportamiento de la "Replicación lógica" es bastante similar al de la "Replicación de transmisión", la única diferencia es que la replicación de transmisión replica la base de datos completa, mientras que la Replicación lógica replica solo tablas individuales. Al elegir tablas individuales específicas para replicar, hay factores/desafíos que deben preverse.

Echemos un vistazo a los factores que influyen en la replicación lógica.

Factores que influyen en el rendimiento de la replicación lógica

La optimización de la replicación lógica es importante para garantizar que los datos se repliquen sin problemas y sin interrupciones. Hay factores a prever antes de ponerlo en marcha. Echemos un vistazo a ellos:

• El tipo de datos almacenados en las tablas que se van a replicar
• Cuán transaccionalmente activas son las tablas (parte de la replicación)
• Se debe prever la capacidad de la infraestructura
• La configuración de parámetros debe realizarse de manera óptima

Todos los factores anteriores influyen en mayor medida en la replicación lógica. Echemos un vistazo a ellos en detalle.

Tipos de datos de replicación lógica de PostgreSQL

Es importante comprender el tipo de datos almacenados en la tabla. Si la parte de la tabla de la replicación almacena objetos de texto grande o binarios y encuentra una gran cantidad de transacciones, entonces, la replicación puede ralentizarse debido al alto uso de los recursos de la infraestructura. La capacidad de la infraestructura debe ser adecuada para manejar una replicación de datos tan compleja y de gran tamaño.

Cómo las tablas activas son parte transaccional de la replicación

Al replicar tablas altamente activas desde el punto de vista transaccional, la replicación puede retrasarse en la sincronización debido a problemas de rendimiento de E/S, interbloqueos, etc., lo que debe tenerse en cuenta. Es posible que esto no haga que los entornos de bases de datos de producción se vean más saludables. Si la cantidad de tablas que se replican es alta y los datos se replican en varios sitios, es posible que haya un uso elevado de la CPU y se requiera una mayor cantidad de CPU (o núcleos de CPU).

Capacidad de infraestructura

Antes de considerar la replicación lógica como una solución, es importante asegurarse de que la capacidad de la infraestructura de los servidores de la base de datos sea lo suficientemente adecuada. Si se está replicando una gran cantidad de tablas, debe haber suficientes CPU disponibles para realizar el trabajo de replicación.

Al replicar una gran cantidad de tablas, considere dividirlas en grupos y replicar en paralelo. Nuevamente, esto requerirá que varias CPU estén disponibles para la replicación. Si los cambios de datos en las tablas que se replican son frecuentes y altos, esto también podría afectar el rendimiento de la replicación.

Optimización de parámetros para replicación lógica

Los parámetros configurados para el funcionamiento de la replicación lógica deben ajustarse de manera óptima para garantizar que la replicación no se interrumpa.

Primero echemos un vistazo a los parámetros necesarios para configurarlo:

wal_level=’logical’
max_wal_senders=10                     # greater than number of subscribers (or replicas)
max_replication_slots=10              # greater than number of subscribers (or replicas)
max_worker_processes=10           # greater than number of subscribers (or replicas)
max_logical_replication_workers  # greater than number of subscribers (or replicas)
max_sync_workers_per_subscription # depends on number of tables being replicated

Ajuste de max_wal_senders

max_wal_senders debe ser siempre mayor que el número de réplicas. Si los datos se replican en varios sitios, entran en juego múltiples max_wal_senders. Por lo tanto, es importante asegurarse de que este parámetro esté configurado en un número óptimo.

Ajuste de max_replication_slots

En general, todos los cambios de datos que ocurren en las tablas se escriben en archivos WAL en pg_xlog / pg_wal, que se denominan registros WAL. El proceso de remitente de Wal recogería esos registros de WAL (pertenecientes a las tablas que se replican) y los enviaría a las réplicas y el proceso de wal_receiver en el sitio de réplica aplicaría esos cambios en el nodo del suscriptor.

Los archivos WAL se eliminan de la ubicación pg_xlog/pg_wal cada vez que se produce un punto de control. Si los archivos WAL se eliminan incluso antes de que se apliquen los cambios al nodo del suscriptor, la replicación se interrumpiría y se retrasaría. En caso de que el nodo del suscriptor se retrase, una ranura de replicación garantizaría que se conserven todos los archivos WAL necesarios para que el suscriptor se sincronice con el proveedor. Se recomienda configurar una ranura de replicación para cada nodo de suscriptor.

Ajuste de max_worker_processes

Es importante tener una cantidad óptima de procesadores de trabajo configurados. Esto depende de la cantidad máxima de procesos que puede tener un servidor. Esto solo es posible en entornos de varias CPU. Max_worker_processes garantizará que se generen múltiples procesos para realizar el trabajo de una manera más rápida utilizando múltiples núcleos de CPU. Al replicar datos mediante la replicación lógica, este parámetro puede ayudar a generar varios procesos de trabajo para replicar los datos más rápido. Hay un parámetro específico llamado max_logical_worker_processes que garantizará que se utilicen múltiples procesos para copiar los datos.

Ajuste de max_logical_worker_processes

Este parámetro especifica el número máximo de procesos de trabajo lógicos necesarios para realizar la replicación y sincronización de datos de tablas. Este valor se toma de max_worker_processes, que debe ser mayor que el valor de este parámetro. Este parámetro es muy beneficioso cuando se replican datos en varios sitios en entornos de varias CPU. El valor predeterminado es 4. El valor máximo depende de cuántos procesos de trabajo admita el sistema.

Ajuste de max_sync_workers_per_subscription

Este parámetro especifica el número máximo de procesos de sincronización necesarios por suscripción. El proceso de sincronización se lleva a cabo durante la sincronización de datos inicial y, para garantizar que suceda más rápido, se puede usar este parámetro. Actualmente, solo se puede configurar un proceso de sincronización por tabla, lo que significa que varias tablas se pueden sincronizar inicialmente en paralelo. El valor predeterminado es 2. Este valor se selecciona del valor max_logical_worker_processes.

Esos son los parámetros que deben ajustarse para garantizar que la replicación lógica sea eficiente y más rápida. Los otros parámetros que también afectan la replicación lógica son los siguientes.

wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval.

Estos parámetros no tienen ningún efecto en el nodo proveedor.

Conclusión

La replicación de tablas específicas es un requisito común que surge en sistemas de bases de datos grandes y complejos. Esto podría ser para informes comerciales o fines de almacenamiento de datos. Como DBA, creo que Logical Replication satisface en gran medida estos propósitos debido a su fácil implementación con menos complejidad. Configurar y ajustar la replicación lógica requiere una buena cantidad de planificación, arquitectura y pruebas. La cantidad de datos que se replican en tiempo real debe evaluarse para garantizar que se implemente un sistema de replicación eficiente y sin problemas. Para concluir, las bases de datos que se ejecutan en PostgreSQL-10, la replicación lógica es el camino a seguir y para aquellas bases de datos que se ejecutan en versiones de PostgreSQL <10, pglogical es la opción.