Existen varias formas de realizar una actualización mayor de PostgreSQL, cada una con sus pros y sus contras, y cada una limitada por la versión de origen y de destino de PostgreSQL (normalmente la última versión estable). Este artículo presenta los métodos recomendados por SystemGuards.

Al realizar una actualización mayor de PostgreSQL, nos enfrentamos a dos importantes dilemas:

• ¿Debería realizar la actualización en el mismo servidor o en otro diferente?
• ¿Debería realizar la actualización cuando la base de datos está en línea o cuando está off-line?

Todo el mundo elegiría instintivamente actualizar en línea, en la misma máquina, y sin ningún tiempo de inactividad.

Sin embargo, según nuestra experiencia, el enfoque recomendado es una actualización en línea en un servidor diferente, utilizando la replicación lógica para transferir los datos del servidor de origen al de destino en la versión mayor.

Por qué preferimos la migración a un servidor diferente

Tanto si se utilizan máquinas físicas como máquinas virtuales, existen muchas ventajas con la actualización en un nuevo servidor. Si se siguen los conceptos principales de DevOps, como el paradigma de la infraestructura inmutable con los contenedores de Linux y Kubernetes (que todavía no forman parte del soporte de producción), esa es realmente la única opción viable.

En el caso de las máquinas físicas, se cuenta con hardware nuevo, con un período de mantenimiento, garantía y soporte extendido.

También es posible aprovechar las ventajas de una nueva distribución de Linux, con (incluso en este caso) un periodo de soporte prolongado, que incluye correcciones de seguridad y de errores.

Al tratarse de un servidor diferente y separado, se puede aprovechar el entorno de preproducción para realizar pruebas, incluyendo (en el caso de las máquinas físicas) un benchmarking exhaustivo, pruebas de resistencia y procesos de validación. Para conocer los límites del sistema, es importante medir el rendimiento máximo del sistema operativo y del almacenamiento antes de utilizarlo de forma efectiva para la base de datos.

Una vez hecho esto, es posible instalar la versión deseada de PostgreSQL, preferiblemente la última versión estable disponible.

Como siguiente paso, es necesario probar las aplicaciones y asegurarse de que funcionen con la versión de PostgreSQL elegida para la actualización.

Por último, medir el tiempo requerido en sincronizar el contenido de la base de datos desde el servidor de origen al nuevo entorno, y simular la transición. Esta operación puede repetirse varias veces y automatizarse, con el fin de obtener una estimación fiable del tiempo necesario para realizarla. Esto es sumamente importante, ya que permite a los técnicos proporcionar planes y calendarios al departamento comercial y reducir los riesgos de fallos y abortos de la operación.

Existen esencialmente tres formas de migrar el contenido de la base de datos del servidor de origen al de destino:

• usando pg_dump y pg_restore (off-line)
• usando PgLogical (en línea)
• usando pg_upgrade (off-line)

Actualización off-line mediante dump y restore

La idea general es realizar un respaldo del servidor de origen (por ejemplo, PostgreSQL 9.5) utilizando pg_dump ejecutado desde el servidor de destino (por ejemplo, PostgreSQL 12). Posteriormente utilizar pg_restore para restaurar el contenido en el nuevo servidor PostgreSQL.

Mientras que durante las pruebas y antes de la producción, es posible realizar un dump con el sistema en línea, la migración final debe ejecutarse cuando el sistema está off-line (al menos en lo que concierne a las operaciones de escritura).

En preproducción, es importante medir el tiempo que tarda pg_dump en exportar la base de datos, y el que tarda pg_restore en restaurar la base de datos, ya que el tiempo global representa el tiempo total de inactividad de la aplicación. En base a esto se puede decidir si esta operación extraordinaria resulta conveniente para la empresa o no (en ese caso, conviene proceder a la actualización en línea, como se sugiere más adelante).

El proceso debe ser automatizado (con bash o Ansible, por ejemplo) y debidamente versionado en el repositorio Git (al final, terminaremos reutilizando estos scripts dentro de unos años al realizar las siguientes actualizaciones).

Debido a la sencillez de este procedimiento, siempre recomendamos empezar con una actualización off-line y evaluar más adelante en función de los resultados anteriores. Además, es importante recordar que no estamos solos al tomar esta decisión, ya que requiere la colaboración de otros departamentos (infraestructura y aplicaciones, por ejemplo). Disponer de un entorno de este tipo, permitirá al equipo ampliado realizar pruebas a nivel de aplicación y evaluaciones comparativas antes de la actualización.

Incluso se podría pensar en entornos basados en Docker para la creación de prototipos y pruebas iniciales, de forma que se involucre en el proceso a operaciones y desarrolladores, antes de pasar al entorno de preproducción con máquinas físicas o virtuales.

El procedimiento para las actualizaciones off-line se describe detalladamente en el artículo "Major PostgreSQL upgrades offline". Dicho procedimiento es aplicable a todas las versiones de PostgreSQL.

Actualización en línea con pglogical

Si el tiempo necesario para la actualización off-line, descrito anteriormente, no es conveniente para una empresa, se puede optar por reducir el tiempo de inactividad al llamado tiempo de transición (cut over time), es decir, el tiempo que necesitan las aplicaciones para ser redirigidas a la nueva base de datos.

La idea principal es que, una vez realizadas todas las pruebas, se reinicie el clúster de destino, se vuelvan a crear los objetos globales de PostgreSQL y el esquema de la base de datos y se instale pglogical. Pglogical sincronizará el contenido y cuando todas las tablas estén replicadas y sincronizadas, la empresa podrá decidir cuándo pasar al nuevo servidor (cutover).

El proceso de transición suele ser casi instantáneo (normalmente menos de un minuto, si no unos segundos).

Pglogical requiere que el servidor de la base de datos de origen cuente con PostgreSQL 9.4 o una versión superior. Además, si existen varias bases de datos en el mismo clúster, será necesario realizar el proceso de replicación para cada una de las bases de datos.

Actualización off-line con pg_upgrade

Otro enfoque es utilizar pg_upgrade para convertir los archivos de bloque de la base de datos a nivel físico (no lógico como los métodos descritos anteriormente).

Existen varios métodos que se pueden adoptar aunque, por las mismas razones expuestas anteriormente, sugerimos realizar la operación en un servidor independiente. Para probar el procedimiento y las aplicaciones, se podría utilizar un respaldo físico disponible y ejecutar en el mismo pg_upgrade.

Por ejemplo, si se dispone de Barman, se puede recuperar el último respaldo en la nueva máquina, iniciar PostgreSQL (utilizando los binarios de las versiones anteriores) y detener la instancia una vez que se haya verificado que la recuperación fue exitosa.

Tras instalar los binarios de la nueva versión de PostgreSQL en esa máquina, ejecutaremos pg_upgrade.

Para más información, consulten la documentación de PostgreSQL sobre pg_upgrade.

¿Soporte o consultoría?

Es importante tener en cuenta que, debido a la especificidad y amplitud del procedimiento para realizar una actualización mayor, este tipo de actividades deben realizarse al margen del soporte como parte de un compromiso de consultoría. Pueden estar seguros de que SystemGuards cuenta con más de una década de experiencia en actualizaciones principales en línea de entornos empresariales y de misión crítica, y ha estado liderando e innovando en esta área con soluciones de vanguardia como BDR, pglogical y Londiste.