Actualizando a PostgreSQL13

En un blog reciente sobre las novedades de PostgreSQL 13, revisamos algunas de las nuevas características de esta versión, pero ahora, veamos cómo actualizar para poder aprovechar todas estas funcionalidades mencionadas. .

Actualización a PostgreSQL 13

Si desea actualizar su versión actual de PostgreSQL a esta nueva, tiene tres opciones nativas principales para realizar esta tarea.

Pg_dump/pg_dumpall:es una herramienta de copia de seguridad lógica que le permite volcar sus datos y restaurarlos en el nueva versión de PostgreSQL. Aquí tendrá un período de inactividad que variará según el tamaño de sus datos. Debe detener el sistema o evitar nuevos datos en el nodo principal, ejecutar pg_dump, mover el volcado generado al nuevo nodo de la base de datos y restaurarlo. Durante este tiempo, no puede escribir en su base de datos principal de PostgreSQL para evitar inconsistencias en los datos.
Pg_upgrade:es una herramienta de PostgreSQL para actualizar su versión de PostgreSQL en el lugar. Podría ser peligroso en un entorno de producción y no recomendamos este método en ese caso. Con este método, también tendrá tiempo de inactividad, pero probablemente será considerablemente menor que con el método pg_dump anterior.
Replicación lógica:desde PostgreSQL 10, puede usar este método de replicación que le permite realizar actualizaciones de versiones principales con cero (o casi cero) tiempo de inactividad. De esta forma, puede agregar un nodo en espera en la última versión de PostgreSQL, y cuando la replicación esté actualizada, puede realizar un proceso de conmutación por error para promover el nuevo nodo de PostgreSQL.

Entonces, veamos estos métodos uno por uno.

Uso de pg_dump/pg_dumpall

En caso de que el tiempo de inactividad no sea un problema para usted, este método es una manera fácil de actualizar.

Para crear el volcado, puede ejecutar:

$ pg_dumpall > dump_pg12.out

O para crear un volcado de una única base de datos:

$ pg_dump world > dump_world_pg12.out

Luego, puede copiar este volcado al servidor con la nueva versión de PostgreSQL y restaurarlo:

$ psql -f dump_pg12.out postgres

Tenga en cuenta que deberá detener su aplicación o evitar escribir en su base de datos durante este proceso, de lo contrario, tendrá inconsistencias en los datos o una posible pérdida de datos.

Usando pg_upgrade

Primero, deberá tener instaladas en el servidor las versiones nueva y antigua de PostgreSQL.

$ rpm -qa |grep postgres
postgresql13-contrib-13.3-2PGDG.rhel8.x86_64
postgresql13-server-13.3-2PGDG.rhel8.x86_64
postgresql13-libs-13.3-2PGDG.rhel8.x86_64
postgresql13-13.3-2PGDG.rhel8.x86_64
postgresql12-libs-12.7-2PGDG.rhel8.x86_64
postgresql12-server-12.7-2PGDG.rhel8.x86_64
postgresql12-12.7-2PGDG.rhel8.x86_64
postgresql12-contrib-12.7-2PGDG.rhel8.x86_64

Luego, primero, puede ejecutar pg_upgrade para probar la actualización agregando el indicador -c:

$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data -c

Performing Consistency Checks on Old Live Server

------------------------------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok
Checking for new cluster tablespace directories             ok

*Clusters are compatible*

Las banderas significan:

-b:El antiguo directorio ejecutable de PostgreSQL
-B:El nuevo directorio ejecutable de PostgreSQL
-d:El antiguo directorio de configuración del clúster de la base de datos
-D:El nuevo directorio de configuración del clúster de base de datos
-c:Comprobar solo clústeres. No cambia ningún dato

Si todo se ve bien, puede ejecutar el mismo comando sin el indicador -c y actualizará su servidor PostgreSQL. Para esto, primero debe detener su versión actual y ejecutar el comando mencionado.

$ systemctl stop postgresql-12
$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data
...

Upgrade Complete

----------------

Optimizer statistics are not transferred by pg_upgrade so, once you start the new server, consider running:

    ./analyze_new_cluster.sh

Running this script will delete the old cluster's data files:

    ./delete_old_cluster.sh

Cuando se complete, como sugiere el mensaje, puede usar esos scripts para analizar el nuevo servidor PostgreSQL y eliminar el antiguo cuando sea seguro.

Uso de la replicación lógica

La replicación lógica es un método para replicar objetos de datos y sus cambios, en función de su identidad de replicación. Se basa en un modo de publicación y suscripción, donde uno o más suscriptores se suscriben a una o más publicaciones en un nodo de publicación.

Basándonos en esto, configuremos el editor, en este caso el servidor PostgreSQL 12, de la siguiente manera.

Edite el archivo de configuración postgresql.conf:

listen_addresses = '*'
wal_level = logical
max_wal_senders = 8
max_replication_slots = 4

Edite el archivo de configuración pg_hba.conf:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host     all     rep1     10.10.10.141/32     md5

Use la dirección IP del suscriptor allí.

Ahora, debe configurar el suscriptor, en este caso el servidor PostgreSQL 13, de la siguiente manera.

Edite el archivo de configuración postgresql.conf:

listen_addresses = '*'
max_replication_slots = 4
max_logical_replication_workers = 4
max_worker_processes = 8

Como este PostgreSQL 13 será el nuevo nodo principal pronto, debería considerar agregar los parámetros wal_level y archive_mode en este paso, para evitar un nuevo reinicio del servicio más tarde.

wal_level = logical
archive_mode = on

Estos parámetros serán útiles si desea agregar una nueva réplica o para usar copias de seguridad de PITR.

Algunos de estos cambios requieren reiniciar el servidor, así que reinicie tanto el publicador como el suscriptor.

Ahora, en el editor, debe crear el usuario que utilizará el suscriptor para acceder a él. El rol utilizado para la conexión de replicación debe tener el atributo REPLICACIÓN y, para poder copiar los datos iniciales, también necesita el privilegio SELECT en la tabla publicada:

world=# CREATE ROLE rep1 WITH LOGIN PASSWORD '********' REPLICATION;
CREATE ROLE
world=# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep1;
GRANT

Vamos a crear la publicación pub1 en el nodo editor, para todas las tablas:

world=# CREATE PUBLICATION pub1 FOR ALL TABLES;
CREATE PUBLICATION

Como el esquema no se replica, debe realizar una copia de seguridad en su PostgreSQL 12 y restaurarla en su PostgreSQL 13. La copia de seguridad solo se realizará para el esquema, ya que la información se replicará en la inicial. transferencia.

En PostgreSQL 12, ejecute:

$ pg_dumpall -s > schema.sql

En PostgreSQL 13, ejecute:

$ psql -d postgres -f schema.sql

Una vez que tenga su esquema en PostgreSQL 13, debe crear la suscripción, reemplazando los valores de host, dbname, usuario y contraseña con los que correspondan a su entorno.

world=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=10.10.10.140 dbname=world user=rep1 password=********' PUBLICATION pub1; 
NOTICE:  created replication slot "sub1" on publisher
CREATE SUBSCRIPTION

Lo anterior iniciará el proceso de replicación, que sincroniza el contenido de la tabla inicial de las tablas en la publicación y luego comienza a replicar los cambios incrementales en esas tablas.

Para verificar la suscripción creada puede utilizar el catálogo pg_stat_subscription. Esta vista contendrá una fila por suscripción para el trabajador principal (con PID nulo si el trabajador no se está ejecutando) y filas adicionales para los trabajadores que manejan la copia de datos inicial de las tablas suscritas.

world=# SELECT * FROM pg_stat_subscription;
-[ RECORD 1 ]---------+------------------------------
subid                 | 16421
subname               | sub1
pid                   | 464
relid                 |
received_lsn          | 0/23A8490
last_msg_send_time    | 2021-07-23 22:42:26.358605+00
last_msg_receipt_time | 2021-07-23 22:42:26.358842+00
latest_end_lsn        | 0/23A8490
latest_end_time       | 2021-07-23 22:42:26.358605+00

Para verificar cuándo finaliza la transferencia inicial, puede verificar la variable srsubstate en el catálogo pg_subscription_rel. Este catálogo contiene el estado de cada relación replicada en cada suscripción.

world=# SELECT * FROM pg_subscription_rel;
 srsubid | srrelid | srsubstate | srsublsn
---------+---------+------------+-----------
   16421 |   16408 | r          | 0/23B1738
   16421 |   16411 | r          | 0/23B17A8
   16421 |   16405 | r          | 0/23B17E0
   16421 |   16402 | r          | 0/23B17E0
(4 rows)

Descripciones de columnas:

srsubid:Referencia a suscripción.
srrelid:Referencia a la relación.
srsubstate:Código de estado:i =inicializar, d =los datos se están copiando, s =sincronizados, r =listo (replicación normal).
srsublsn:finaliza el LSN para los estados s y r.

Cuando finaliza la transferencia inicial, tiene todo listo para apuntar su aplicación a su nuevo servidor PostgreSQL 13.

Conclusión

Como puede ver, PostgreSQL tiene diferentes opciones para actualizar, según sus requisitos y la tolerancia al tiempo de inactividad.

No importa qué tipo de tecnología esté utilizando, mantener actualizados los servidores de su base de datos realizando actualizaciones periódicas es una tarea necesaria pero difícil, ya que debe asegurarse de que no perderá datos. o inconsistencia de datos después de la actualización. Un plan detallado y probado es la clave aquí y, por supuesto, debe incluir una opción de reversión, por si acaso.