Extensiones y objetos de replicación lógica que hay que revisar

Revisa los siguientes puntos antes de la actualización:

Extensiones

• pg_repack
• old_snapshot
• wal2json
• anon
• PostGIS

Espacios de replicación

• Logical replication slots

Dependencias de las aplicaciones Si elimina extensiones u objetos de replicación de los que dependen sus aplicaciones, compruebe los flujos de datos y el comportamiento de las aplicaciones antes de continuar con la actualización. Ten en cuenta también las posibles alteraciones en la lógica de tu aplicación que dependa de funciones específicas de PostgreSQL.

pg_repack

Elimina la carpeta « pg_repack » antes de la actualización y vuelve a crearla después de la misma. « pg_repack » utiliza una extensión específica de la versión y componentes de cliente/servidor que deben coincidir con la versión principal de « PostgreSQL ».

DROP EXTENSION pg_repack;

Vuelve a crear la extensión tras la actualización solo si tu carga de trabajo sigue necesitándola.

CREATE EXTENSION pg_repack;

old_snapshot

Elimina « old_snapshot » antes de la actualización. No Vuelve a crearlo tras actualizar a « PostgreSQL 18», ya que ya no es compatible.

DROP EXTENSION old_snapshot;

wal2json ranuras de replicación

Si utilizas « wal2json » para la decodificación lógica, debes eliminar todas las ranuras de replicación asociadas antes de la actualización. La utilidad « pg_upgrade » prohíbe terminantemente las actualizaciones de versión principal mientras existan ranuras de replicación, y generará un error crítico y detendrá la actualización.

Antes de actualizar:

1. Asegúrate de que se hayan procesado todos los datos pendientes del WAL.
2. Detén la aplicación que utiliza el canal de replicación.
3. Eliminar los slots de replicación:

SELECT pg_drop_replication_slot('your_slot_name');

Tras la actualización, puedes volver a crear los canales de replicación según sea necesario. Ten en cuenta que « wal2json » no se instala a través de CREATE EXTENSION, sino que se configura mediante parámetros de la base de datos (wal_level, max_replication_slots, max_wal_senders) y permisos de tabla, lo cual no impide las actualizaciones.

anon

Desactiva la extensión « anon » antes de la actualización y vuelve a activarla después de la actualización si aún la necesitas. Es necesario realizar algunos pasos adicionales antes de dar de baja anon.

Si tienes instalada la extensión « anon », sigue los pasos que se indican a continuación y ejecuta los comandos como usuario administrador antes de realizar la actualización.

1. Elimina todas las reglas de enmascaramiento (si están activadas).

   SELECT anon.remove_masks_for_all_columns();
   

2. Desactiva los roles ocultos (la actualización podría fallar si hay algún rol marcado como oculto).

   SECURITY LABEL FOR anon ON ROLE <role_name> IS NULL;
   

3. Elimina la extensión « anon » con la opción «cascade».

   DROP EXTENSION anon CASCADE;
   

4. Si la extensión « anon » está instalada en varias bases de datos dentro de una instancia, sigue los pasos indicados para cada una de ellas.

5. Una vez completada la actualización, vuelve a activar la extensión « anon » y vuelve a aplicar las reglas de enmascaramiento según sea necesario.

Se recomienda encarecidamente validar los datos tanto antes como después de eliminar la extensión, para garantizar la coherencia del enmascaramiento antes de realizar la actualización.

PostGIS

Si utilizas PostGIS,, actualiza primero PostGIS antes de actualizar PostgreSQL.

SELECT postgis_extensions_upgrade();

Utiliza la siguiente consulta para comprobar que la actualización de la extensión « PostGIS » se ha realizado correctamente.

SELECT postgis_full_version();

Logical replication slots

Elimina todas las ranuras de replicación lógica antes de la actualización y vuelve a crearlas después de la misma. Las ranuras lógicas están vinculadas al estado del servidor de origen y deben volver a crearse desde cero en la instancia actualizada.

SELECT pg_drop_replication_slot('<slot_name>');

Espacios de replicación lógica

Elimina todas las ranuras de replicación lógica antes de la actualización y vuelve a crearlas después. Las ranuras de replicación lógica están vinculadas al estado del servidor de origen y deben volver a crearse en la instancia actualizada.

SELECT pg_drop_replication_slot('<slot_name>');

Antes de empezar

Revisa lo siguiente antes de iniciar la actualización:

• Comprueba que tu implementación admita actualizaciones de versión mediante la interfaz de usuario, la API, la CLI o Terraform.

  Ejemplo (CLI):

  ibmcloud cdb capability-show versions postgresql
  

• Revisa los requisitos de verificación previa. La actualización se ejecuta en el entorno de origen y se bloquea si se detectan riesgos. Asegúrese de lo siguiente:

  • La implementación funciona correctamente
  • Hay al menos un 10 % de espacio libre disponible en el disco
  • La utilización de E/S es inferior al 90 %
  • El tamaño del esquema y el número de objetos se encuentran dentro de los límites admitidos
  • Se ha completado la limpieza necesaria de la extensión y de los espacios de replicación lógica

• Consulta el informe « https://www.postgresql.org/docs/release/ » para conocer los cambios de compatibilidad que puedan afectar a tus aplicaciones.

• No se admite el cambio a una versión anterior.

• Una actualización in situ no se puede cancelar una vez iniciada.

• Asegúrate de que dispones de una copia de seguridad reciente antes de actualizar.

Gen2 empieza con « PostgreSQL » 18. Las rutas de actualización a versiones más recientes se van añadiendo a medida que se incorporan. Para versiones anteriores (14-17), consulta la página /docs/databases-for-postgresql?topic=databases-for-postgresql-upgrading.

Una vez completada la actualización, tu implementación se ejecutará con una nueva versión principal de PostgreSQL. Las copias de seguridad y los puntos PITR anteriores a la actualización pertenecen a la línea temporal de la versión anterior y no se pueden restaurar en la versión actualizada.

Para mantener las funciones de restauración y PITR en la nueva versión, realiza una copia de seguridad inmediatamente después de la actualización. Esta copia de seguridad se convierte en la referencia para futuras operaciones de recuperación.

Si la actualización falla, las copias de seguridad realizadas antes de la actualización pueden seguir utilizándose con PITR para restaurar la versión anterior en una nueva implementación.

Resolución de problemas

Si surgen problemas tras una actualización correcta y necesitas volver a la versión anterior, ponte en contacto con el servicio de asistencia de IBM Cloud® para que te orienten. Evita realizar operaciones PITR o restauraciones sin recibir orientación, ya que esto puede complicar la recuperación.

Las actualizaciones solo se ejecutan una vez que se hayan superado todas las comprobaciones previas. Si la actualización se bloquea, comprueba lo siguiente:

• Estado del clúster (el estado de Patroni es estable)
• Espacio libre suficiente en el disco
• Utilización aceptable de E/S de disco
• Límites de tamaño del esquema y de número de objetos

Los esquemas de gran tamaño y el elevado número de objetos pueden alargar la duración de la actualización.

Si los intentos de actualización siguen fallando, abre un ticket de asistencia a través de https://cloud.ibm.com/login?redirect=%2Funifiedsupport%2Fsupportcenter.

Simulacro de la promoción y actualización

Para evaluar los efectos de las actualizaciones de versión importantes, realiza una prueba de simulación. Una prueba simula la promoción y la actualización, y los resultados se registran en los registros de la base de datos. Accede y consulta los registros de tu base de datos a través de la integración de análisis de registros. Esto garantiza que la versión que está utilizando actualmente, junto con sus extensiones, se pueda actualizar correctamente a la versión deseada.

El simulacro debe ejecutarse con skip_initial_backup establecido en false y con version definido.

El comando tiene este aspecto:

curl -X POST \
  https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/remotes/promotion \
  -H 'Authorization: Bearer <>'  \
 -H 'Content-Type: application/json' \
 -d '{
    "promotion": {
        "version": "14",
        "skip_initial_backup": false,
        "dry_run": true
    }
}' \