Anteriormente, las principales actualizaciones de las bases de datos PostgreSQL con terabyte de capacidad exigían un downtime prolongado o requerían un gran volumen de trabajo. Con la decodificación lógica, se presentó un mundo totalmente nuevo de oportunidades para las actualizaciones que requieren una cantidad muy pequeña de downtime.
Este webinar proporcionó una panorámica exhaustiva sobre cómo realizar una actualización con downtime “casi” nulo utilizando pglogical. Abarcó también pequeños detalles que, de no ser considerados a tiempo, pueden llevar a una actualización prolongada o, peor aún, en una no realizada.
Con el fin de explorar más a fondo este tema, 2ndQuadrant organizó un webinar en vivo, “Highway to Zero Downtime PostgreSQL Upgrades”, que fue presentado por Martín Marqués, Jefe de Soporte Técnico para las Américas en 2ndQuadrant.
A continuación se muestra un avance del webinar. Todos aquellos que no pudieron asistir al webinar en vivo pueden acceder a la grabación que encontrarán aquí.
Debido a la limitada disponibilidad de tiempo, algunas de las preguntas no fueron contestadas durante el webinar en vivo, de modo que las respuestas del conductor se presentan a continuación:
Pregunta: ¿Es posible usar pglogical en AWS Aurora 9.6, para hacer una actualización a la versión 11?
Respuesta: No podría contestar a eso, ya que Aurora no utiliza el mismo sistema de almacenamiento que la comunidad PostgreSQL.
Pregunta: ¿Puedo actualizar un clúster de Postgres 10 a Postgres 13 usando un único comando pg_upgrade o debería realizar también las actualizaciones intermedias?
Respuesta: No es necesario realizar actualizaciones intermedias entre las dos versiones. No hay ningún problema en actualizar desde la versión 10 a la 13 con una sola ejecución de pg_upgrade.
Pregunta: ¿Existe algún método para calcular la cantidad de los max_wal_senders, maxwokers… max_parallel_worker…?
Respuesta: No existe una fórmula específica. En el caso de la replicación, depende de cuántas conexiones se hayan abierto en un momento dado. Se debe tener en cuenta que cada conexión de replicación (física o lógica) usará un wal_sender. max_worker_processes debería tener un valor sensiblemente mayor que los senders
Pregunta: Cuando habla de “Objetos Grandes”, ¿a qué se refiere? ¿A algo como los archivos bytea?
Respuesta: No, los objetos grandes suelen ser datos binarios que se introducen mediante las funciones lo_*. Estos datos se almacenan en una tabla de catálogo llamada pg_largeobjects que no se replica de forma lógica. Si por otro lado se usan los campos bytea en las tablas de uso, estos sí pueden ser replicados y por lo tanto es posible realizar actualizaciones mediante la replicación lógica o pglogical, tal como expliqué en el webinar
Pregunta: Pregunta sobre la replicación lógica: ¿Qué ocurre cuando se ejecuta un DDL en el Nodo Proveedor, antes de que el Nodo Suscriptor se haya actualizado?
Respuesta: En realidad, nada. El DDL será registrado en el archivo WAL, el cual será ignorado por el flujo de replicación lógica. El problema podría surgir si el DDL cambia el esquema de una manera que ocasione la interrupción de la replicación del DML desde la tabla implicada en dicho DDL
Pregunta: ¿La extensión pg_logical está disponible también para la versión 13 de PostgreSQL? (Esta extensión parece no estar incluida en los repositorios de Debian)
Respuesta: Muy pronto lanzaremos una versión para Postgres 13.
Pregunta: ¿Es posible utilizar la replicación en flujo y luego habilitar la replicación lógica (no pgógical) sin la necesidad de una sincronización inicial de los datos?
Respuesta: Sí, es posible aunque no está documentado. Debería hacerse algo similar a lo que hace pglogical_create_subscriber.
Pregunta: En concreto, ¿cómo es posible manejar las secuencias en la replicación lógica?
Respuesta: Es necesario sincronizarlas manualmente durante el proceso de switchover.
Pregunta: ¿Existen planes para añadir la replicación automática de DDL tanto a pglogical como a la replicación lógica nativa? replicate_ddl_command() es un procedimiento manual. La extensión pgl_ddl_deploy (de una fuente distinta) ofrece esta funcionalidad al ser utilizada con pglogical, aunque, según mi experiencia presenta problemas.
Respuesta: La versión 3 de pglogical contará con un sistema de replicación transparente de DDL.
Pregunta: El hecho de que se deba modificar el archivo de configuración de Postgres, ¿significa que, técnicamente, pglogical implicará cierto downtime si no se planifica durante el aprovisionamiento inicial de la base de datos original/principal?
Respuesta: En realidad, depende. Es posible cambiar la configuración en cualquier momento y reiniciar el nodo de destino. La replicación se reanudará desde donde se detuvo antes del apagado.
Pregunta: Quiero actualizar desde AWS RDS PG10 a una versión inferior a la 13. Necesito características avanzadas como el particionamiento y la replicación lógica. ¿Recomendaría la versión 12 o debería esperar a que la 13 esté disponible en AWS?
Respuesta: En realidad no podría contestar a eso, ya que desconozco el plan de desarrollo de PG13 en RDS. Depende también de si existen características introducidas en PG13 que le gustaría utilizar.
Pregunta: Un enfoque basado en múltiples bases de datos, ¿supone una mayor resiliencia?
Respuesta: No. Múltiples bases de datos no suponen un sistema más resiliente.
Pregunta: ¿Existe una notificación o algún tipo de consulta para determinar si se ha completado la sincronización inicial en la replicación lógica?
Respuesta: Es necesario utilizar las vistas de replicación lógica disponibles en Postgres. La documentación incluye una sección sobre el monitoreo de la replicación lógica.
Pregunta: Cuando afirma que los “Objetos Grandes no se replican”, ¿se refiere a las tablas TOAST? Contamos con centenares de GB de datos en JSONB almacenados en tablas TOAST.
Respuesta: No, los objetos grandes son aquellos creados usando las funciones lo_* de postgres. Los datos binarios de los objetos grandes se almacenan en una tabla de catálogo, por lo que no se replican. En cambio, los datos almacenados en las tablas TOAST se replican sin problemas.
Pregunta: Una pregunta sobre las “prácticas recomendadas”: ¿sería ideal, en el caso de actualizar un servidor y un standby, instalar un nuevo servidor con la replicación lógica, y un standby del mismo?
Respuesta: Sí, eso sería lo ideal
Pregunta: Cuando habla de clave primaria, ¿se refiere a un índice único o a una efectiva cláusula de clave primaria?
Respuesta: Se trata de una restricción de clave primaria. El índice único no es suficiente. pglogical 3 tendrá la capacidad de usar REPLICA IDENTITY FULL y también REPLICA IDENTITY INDEX en un índice que incluya campos NOT NULL.
Pregunta: Si queremos usar pg_upgrade y disponemos de pg_largeobject, ¿aumentará el tiempo requerido para la actualización?
Respuesta: Sí, la duración se extenderá considerablemente si el número de LO es elevado.
Pregunta: ¿Cómo se trasladan las conexiones activas desde el servidor antiguo al nuevo?
Respuesta: No es posible hacerlo. Esas conexiones deben ser eliminadas. Una opción, para que no se pierdan las conexiones del lado de la aplicación, es usar pgbouncer. Es posible redirigir las conexiones con pgbouncer (este proceso está documentado, si bien recuerdo).
Pregunta: Tras completar la actualización y copiar de nuevo las secuencias ¿cómo se reinician las mismas? ¿Se empezará desde 0?
Respuesta: Es necesario recorrer las secuencias en el nodo fuente consultando next_val y estableciendo el siguiente en el nodo destino.
Pregunta: ¿Es posible utilizar repmgr entre diferentes versiones para definir la réplica y configurar la replicación lógica?
Respuesta: No. Repmgr funciona únicamente con la replicación física
Si desea ser el primero en conocer los próximos webinars de 2ndQuadrant sobre PostgreSQL, visite la página web de nuestros Webinars.
Para cualquier pregunta, comentario o sugerencia, por favor visite nuestra página web o envíe un correo electrónico a webinar@2ndquadrant.com.