Extensiones y objetos de replicación lógica que deben revisarse

Revisa los siguientes puntos antes de la actualización:

pg_repack

Elimina la carpeta « pg_repack » antes de la actualización y vuelve a crearla después de la actualización. La carpeta « 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 la tabla « old_snapshot » antes de la actualización. PostgreSQL NO lo vuelvas a crear tras actualizar a Windows 18, ya que ha dejado de ser compatible.

DROP EXTENSION old_snapshot;

wal2json ranuras de replicación

Si utiliza « wal2json » para la decodificación lógica, debe 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. Elimina las ranuras de replicación:

SELECT pg_drop_replication_slot('your_slot_name');

Tras la actualización, puede volver a crear las ranuras de replicación según sea necesario. Ten en cuenta que « wal2json » no se instala mediante « CREATE EXTENSION », sino que se configura a través de los parámetros de la base de datos (wal_level, max_replication_slots, max_wal_senders) y los permisos de las tablas, 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 sigues necesitándola. Es necesario seguir algunos pasos más antes de desinstalar 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. Deshabilite los roles enmascarados (la actualización podría fallar si algún rol está marcado como enmascarado).

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

3. Elimine la extensión anon con la opción de cascada.

   DROP EXTENSION anon CASCADE;
   

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

5. Una vez finalizada la actualización, vuelva a activar la extensión anon y aplique de nuevo las reglas de enmascaramiento necesarias.

Se recomienda encarecidamente validar los datos antes y después de eliminar la ampliació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();

Utilice la siguiente consulta para validar la actualización de la extensión PostGIS.

SELECT postgis_full_version();

Logical replication slots

Elimine todos los espacios de replicación lógica antes de la actualización y vuelva a crearlos después de la actualización. Los slots lógicos están vinculados al estado del servidor de origen y deben volver a crearse desde cero en la instancia actualizada.

SELECT pg_drop_replication_slot('<slot_name>');

Antes de empezar

Tenga en cuenta los siguientes aspectos antes de iniciar el procedimiento de actualización.

• Comprueba si hay una actualización disponible para la versión de tu implementación consultando la información sobre las capacidades de implementación a través de la interfaz de usuario, la API, la CLI o Terraform.

  Ejemplo: consultar la información sobre actualizaciones de versión mediante la CLI:

  ibmcloud cdb capability-show versions postgresql
  

• Asegúrate de revisar los requisitos relacionados con la verificación previa que se indican en este tema antes de activar la IPU. IPU se ejecuta directamente en el entorno de origen y no crea una nueva instancia. Por motivos de seguridad de los clientes, el servicio realiza comprobaciones previas antes de que comience la actualización y bloquea la operación si se detecta algún riesgo. En concreto, compruebe los siguientes puntos:

  • Tu implementación tiene como máximo 3 miembros.
  • Tu implementación se encuentra en buen estado.
  • Tu implementación tiene al menos un 10 % de espacio libre en disco disponible. El uso máximo de disco permitido por defecto para las comprobaciones previas de la IPU es del 90 %.
  • Tu implementación no está sometida a una gran carga de E/S. El porcentaje máximo de utilización de E/S permitido por defecto para la comprobación previa de la IPU es del 90 %.
  • El tamaño de su esquema y el número de objetos se encuentran dentro de los límites predeterminados de la comprobación previa. Por defecto, ningún esquema individual puede superar los 100 GB y el número total de índices y secuencias debe ser inferior a 50 000.
  • Ha completado todas las tareas necesarias de limpieza de extensiones y de ranuras de replicación lógica antes de la actualización.

• Cada versión principal incluye algunas funciones que podrían no ser compatibles con versiones anteriores. Consulte las notas de la versión del proveedor de la base de datos para ver si hay cambios que puedan afectar a sus aplicaciones.

• No se admite la degradación de una implementación a una versión anterior.

• La actualización de versión principal in situ no se puede cancelar una vez iniciada.

• Si no tienes una copia de seguridad reciente, te recomendamos que hagas una antes de actualizar.

Además, ten en cuenta que, una vez completada la actualización, tu base de datos ejecutará una nueva versión principal de PostgreSQL. Dado que PostgreSQL almacena los datos en formatos específicos de cada versión, las copias de seguridad y los puntos de 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 completa y PITR (recuperación en un momento determinado) en la nueva versión, realice una nueva copia de seguridad inmediatamente después de que finalice la actualización. Esa copia de seguridad se convierte en la referencia para futuras operaciones de recuperación en la línea temporal de la nueva versión.

Si IPU falla, las copias de seguridad válidas anteriores a la actualización pueden seguir utilizándose con PITR para restaurar la versión anterior de PostgreSQL en una nueva instancia.

Resolución de problemas

Si sus aplicaciones muestran problemas inesperados después de una actualización exitosa de la versión principal y necesita volver a la versión PostgreSQL anterior, póngase en contacto con nuestro equipo de soporte para obtener ayuda. Evita iniciar un PITR o restaurar una copia de seguridad por tu cuenta, ya que esto puede complicar la recuperación.

Una actualización importante in situ no se llevará a cabo hasta que se hayan superado todas las comprobaciones previas. Estas medidas de seguridad están pensadas para proteger su implementación, ya que la actualización se realiza directamente en la instancia de origen. Si la actualización está bloqueada, revise las siguientes áreas:

• Número de miembros: la actualización de versión principal in situ admite implementaciones con un máximo de 3 miembros. Si tu implementación tiene más de 3 miembros, las comprobaciones previas bloquean la actualización. Los miembros no se pueden eliminar mediante el escalado horizontal, por lo que debes abrir un ticket de asistencia en IBM Cloud para reducir el número de miembros antes de volver a intentar la actualización.
• Estado del clúster: asegúrate de que el clúster de Patroni funcione correctamente y de que exista un estado claro de líder/réplica. Las actualizaciones no pueden continuar si Patroni informa de condiciones de inestabilidad o conmutación por error.
• Espacio en disco: comprueba que haya suficiente espacio libre disponible. El proceso utiliza el pg_upgrade modo de enlace, que requiere un margen adecuado. Si el uso del disco supera el límite configurado (por defecto: 90 %), libere espacio antes de volver a intentarlo.
• Carga de E/S de disco: comprueba el uso actual de E/S y las IOPS. Las actualizaciones se detienen cuando el sistema está sometido a una carga elevada para evitar la degradación del rendimiento o el fallo de la actualización.
• Tamaño del esquema y recuento de objetos: como se ha mencionado, el tamaño del esquema afecta directamente a la duración de una actualización de versión principal in situ. Asegúrese de que ningún esquema individual supere el tamaño máximo (por defecto: 100 GB) y que el número total de objetos de índice y secuencia se mantenga por debajo del límite (por defecto: 50 000). Los esquemas grandes o los recuentos de objetos inusualmente altos pueden requerir una limpieza u optimización antes de continuar con la actualización. pg_upgrade Realiza actualizaciones rápidas creando nuevas tablas del sistema y reutilizando simplemente los antiguos archivos de datos de usuario. El tiempo necesario para crear estas tablas del sistema varía en función del número de objetos de la base de datos. El consumo de recursos se puede evaluar utilizando la integración de supervisión. Si no todos los componentes de la base de datos están disponibles para actualizarse, la tarea de actualización falla. Esto puede suceder debido al mantenimiento. Las tareas que han fallado debido a comprobaciones de estado fallidas se pueden volver a intentar más tarde. Si la tarea sigue fallando, abre un ticket de soporte con IBM Cloud support. Si ciertas comprobaciones no son relevantes para su entorno y la actualización sigue bloqueada, cree un ticket de soporte para obtener más ayuda.

Simulacro de la promoción y actualización

Para evaluar los efectos de las actualizaciones a versiones principales, realiza una simulación. Una ejecución en seco simula la promoción y la actualización, con los resultados impresos en los registros de base de datos. Acceda y visualice los registros de su base de datos a través de la integración de análisis de registros. De este modo, se garantiza que la versión que estás 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 mandato tiene el siguiente 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
    }
}' \