IBM Cloud Docs
Actualización a una nueva versión principal

Actualización a una nueva versión principal

A partir de diciembre de 2025, Databases for PostgreSQL ofrece tres vías de actualización diferentes:

  • Actualización in situ a una nueva versión principal.
  • Restaurando desde la copia de seguridad.
  • Actualización desde una réplica de solo lectura.

Cuando una versión principal de una base de datos se acerca al final de su vida útil (EOL), es recomendable actualizarla a una versión principal actual.

Busque las versiones disponibles de Databases for PostgreSQL en la página Catálogo deIBM Cloud, desde el mandato de plugin de CLI Cloud Databases ibmcloud cdb deployables-show, o desde el punto final Cloud Databases API /deployables.

Al actualizar a una nueva instancia, también debe cambiar la información de conexión en la aplicación.

Requisitos para actualizar a una versión mayor más PostgreSQL reciente desde PostgreSQL v14

Si tiene pg_repack instalado, debe eliminarlo antes de realizar la actualización. Esto se puede hacer con un mandato como:

DROP EXTENSION pg_repack;

Después de actualizar, vuelva a instalar pg_repack. Esto se puede realizar con el mandato siguiente:

CREATE EXTENSION pg_repack;

Si está utilizando, primero PostGIS, debe actualizar a PostGIS antes de actualizar PostgreSQL. Esto se puede hacer ejecutando el siguiente comando en una base de datos con PostGIS instalado.

SELECT postgis_extensions_upgrade();

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

SELECT postgis_full_version();

Actualizaciones importantes de la versión in situ

La actualización de la versión principal in situ le permite actualizar su implementación a la siguiente versión principal nueva, lo que elimina la necesidad de restaurar una copia de seguridad en una nueva implementación. Este enfoque mantiene las mismas cadenas de conexión, sin necesidad de reconfigurar la implementación. Sin embargo, si la nueva versión principal requiere ajustes en la aplicación, estos deben abordarse.

Durante el periodo de actualización de la versión principal, su implementación experimentará un breve periodo de inactividad. Esto es lo esperado, ya que el proceso sigue el enfoque de actualización recomendado por el proveedor. La duración exacta puede variar en función del tamaño y la complejidad del esquema de su implementación. Si su servicio necesita leer datos de la instancia actualizada durante este tiempo, es posible que desee crear una instancia en espera y actualizar los detalles de conexión de su aplicación para que apunten a la instancia en espera. Esto garantiza que disponga de una copia actualizada de su base de datos antes de iniciar la actualización. La instancia en espera también se puede promover y utilizar como instancia principal si la actualización in situ no se completa correctamente. Hay información adicional disponible en la página de réplicas de solo lectura, que se puede consultar aquí.

Databases for PostgreSQL ofrece a los clientes flexibilidad para gestionar sus propias copias de seguridad. El proceso de actualización de la versión principal in situ no crea automáticamente una copia de seguridad antes o después de la tarea. Si la actualización no se realiza correctamente, es posible que tenga que restaurar la implementación desde la copia de seguridad más reciente en una nueva instancia.

Aunque se admiten las actualizaciones in situ, no se recomienda realizarlas sin una copia de seguridad reciente. Disponer de una copia de seguridad actualizada antes y después de iniciar la actualización proporciona una capa adicional de protección y ayuda a garantizar una recuperación fluida en caso necesario. Por lo tanto, considere realizar una copia de seguridad nueva antes y después de la tarea de actualización de la versión principal in situ.

Antes de empezar

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

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

    Ejemplo: Buscar información sobre la actualización de la versión con la CLI.

    ibmcloud cdb capability-show versions postgresql

  • Su implementación debe estar en buen estado antes de actualizar.

  • Tu implementación debe tener al menos un 10 % del espacio disponible en disco.

  • Su implementación no debe estar sometida a una gran presión de E/S (máximo permitido: 90 %).

  • En este momento, solo se puede actualizar de PostgreSQL la versión 14 a la PostgreSQL 15.

  • Cada versión principal contiene algunas características que pueden 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 la versión principal in situ no se puede cancelar una vez iniciada.

  • Si no dispone de una copia de seguridad reciente, considere realizar una antes de actualizar.

Ten en cuenta también que, una vez completada la actualización, tu base de datos funcionará con una nueva versión PostgreSQL principal. Debido a que PostgreSQL almacena datos en formatos específicos de cada versión, el nuevo PostgreSQL directorio de datos no se puede utilizar con versiones anteriores. Esto significa que las copias de seguridad realizadas antes de la actualización no se pueden utilizar para restaurar la nueva PostgreSQL versión. Para mantener las capacidades de restauración completa y PITR (recuperación en un punto en el tiempo) en el futuro, realice una nueva copia de seguridad después de la actualización. Esta nueva copia de seguridad se convierte en la línea de base para todas las futuras operaciones de recuperación en la PostgreSQL línea de tiempo.

Actualización en la IU

  1. Cree uno nuevo Databases for PostgreSQL para probar el proceso de actualización.
    Cree la implementación restaurando una copia de seguridad de su implementación existente con la misma versión.

  2. Dirija su aplicación de ensayo a la implementación de prueba.
    Actualiza tu aplicación de staging para que apunte a la implementación de prueba. Confirme que su aplicación de prueba puede conectarse correctamente a la implementación provisional y que la aplicación funciona según lo previsto. Realizar todas las pruebas de rendimiento y operativas necesarias en el entorno de prueba.

  3. Actualice la versión principal de su implementación de prueba haciendo clic en el botón Actualizar versión principal en la página Descripción general.
    Tenga en cuenta cuánto tiempo tarda en completarse la actualización, de modo que pueda utilizar la configuración de caducidad de la actualización para contener las actualizaciones dentro de su ventana de mantenimiento.

  4. Confirma que tu aplicación de ensayo funciona con la nueva versión de la base de datos.
    Si su aplicación funciona, este paso confirma que es seguro actualizar su base de datos de producción.

  5. Actualice la implementación de su base de datos de producción a la nueva versión.
    Una vez que haya confirmado que su aplicación funciona correctamente con la nueva versión de la base de datos, puede volver a la consola de administración e iniciar el proceso de actualización de su implementación de producción. En la sección Detalles de implementación de la página Descripción general, haga clic en el botón Actualizar versión principal y siga los pasos.

    Una vez iniciado el proceso de actualización in situ, no se puede detener ni revertir. Por lo tanto, en el improbable caso de que se produzca un error, la implementación de su base de datos podría quedar irrecuperable. Por lo tanto, cree una copia de seguridad que luego pueda utilizar para restaurar una nueva implementación.

Le expiration for starting upgrade permite configurar un período de «tiempo de espera» en el que debe iniciarse la tarea de actualización antes de que se cancele automáticamente. Además, pruebe la actualización en la fase de preparación por adelantado para asegurarse de que la actualización se complete dentro del plazo deseado. Si, por ejemplo, desea completar la actualización en 1 hora y ha probado la actualización y sabe que tarda 30 minutos, entonces su trabajo de actualización debe comenzar en los 30 minutos siguientes a la confirmación de que desea actualizar. Por lo tanto, establezca el tiempo de caducidad en 30 minutos, de modo que si no se inicia dentro de ese tiempo, no se excederá su ventana.

Actualización a través de la API

Utilice el siguiente comando para actualizar in situ:

curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/version -H 'Authorization: Bearer <>' -H 'Content-Type: application/json' -d '{"version": "15"}'

Le expiration for starting upgrade permite configurar un período de «tiempo de espera» en el que debe iniciarse la tarea de actualización antes de que se cancele automáticamente. Además, pruebe la actualización en la fase de preparación por adelantado para asegurarse de que la actualización se complete dentro del plazo deseado. Si, por ejemplo, desea completar la actualización en 1 hora y ha probado la actualización y sabe que tarda 30 minutos, entonces su trabajo de actualización debe comenzar en los 30 minutos siguientes a la confirmación de que desea actualizar. Por lo tanto, establezca la caducidad en una marca de tiempo de 30 minutos a partir de ahora, de modo que si no se inicia dentro de ese tiempo, no se excederá su ventana. La caducidad debe estar comprendida entre 5 minutos (valor predeterminado) y 24 horas a partir de ahora. Para obtener más información, consulte la Cloud Databases API.

Actualización a través de la CLI

Disponible en la versión del complemento CDB >= 0.20.0.

Para ver la lista de transiciones de actualización y restauración permitidas para la implementación:

ibmcloud cdb deployment-capability-show <NAME|CRN> versions

Para actualizar el comando con los parámetros necesarios:

ibmcloud cdb deployment-version-upgrade <NAME|CRN> <TARGET_VERSION>

Para ver todos los detalles de los parámetros comando :

ibmcloud cdb deployment-version-upgrade --help

Le expiration for starting upgrade permite configurar un período de «tiempo de espera» en el que debe iniciarse la tarea de actualización antes de que se cancele automáticamente. Además, pruebe la actualización en la fase de preparación por adelantado para asegurarse de que la actualización se complete dentro del plazo deseado. Si, por ejemplo, desea completar la actualización en 1 hora y ha probado la actualización y sabe que tarda 30 minutos, entonces su trabajo de actualización debe comenzar en los 30 minutos siguientes a la confirmación de que desea actualizar. Por lo tanto, establezca el tiempo de caducidad en 30 minutos, de modo que si no se inicia dentro de ese tiempo, no se excederá su ventana. La caducidad debe estar comprendida entre 5 minutos (por defecto) y 24 horas a partir de ahora. Hay dos formas de configurar la caducidad utilizando CLI --expire-in o --expire-at. Para obtener más información, consulte la ayuda comando comando.

Actualización mediante Terraform

Disponible en la versión del proveedor Terraform >= 1.79.2.

Para actualizar, solo tienes que añadir o cambiar el version valor en tu configuración.

Omitir una copia de seguridad antes de actualizar una versión es peligroso y puede provocar la pérdida de datos si la actualización falla en cualquier momento, ya que no habrá una copia de seguridad inmediata desde la que restaurar. Por lo tanto, considere realizar una copia de seguridad nueva antes de iniciar una tarea de actualización de versión mayor in situ.

La actualización puede requerir más tiempo que el tiempo de espera predeterminado. Se puede establecer un valor de tiempo de espera más largo utilizando el atributo timeouts.

Terraform tiene tiempos de espera en lugar de marcas de tiempo de caducidad. Por lo tanto, aumente su tiempo de espera, ya que el valor de actualización del tiempo de espera se utiliza como fecha de caducidad. Por ejemplo, si establece un tiempo de espera de 20 minutos, la caducidad se fijará en 20 minutos y, si la actualización no se inicia en ese plazo, caducará y la actualización no se iniciará. Ten en cuenta que el vencimiento máximo es de 24 horas, por lo que, aunque establezcas un tiempo de espera de 36 horas, la actualización caducará si no se ha iniciado en las primeras 24 horas.

Si se está realizando una actualización, tenga en cuenta que algunas tareas pueden quedar en cola y no se ejecutarán hasta que finalice la actualización de la versión.

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. Evite iniciar un PITR o restaurar una copia de seguridad por su 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 existen 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:

  • Estado del clúster: Asegúrese de que el clúster Patroni esté en buen estado y que haya 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: compruebe que hay 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 del disco: comprueba la utilización 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.

Gestión de la extensión anon antes de la actualización

Si la extensión anon está instalada, siga los pasos que se indican a continuación y ejecute 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 descritos para cada base de datos.

  5. Pasos posteriores a la actualización:

    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.

Actualización a partir de una réplica de solo lectura

Actualice configurando una réplica de sólo lectura. Proporcione una réplica de solo lectura con la misma versión de base de datos que su implementación y espere mientras se replican todos sus datos. Cuando la implementación y su réplica estén sincronizadas, promueva y actualice la réplica de solo lectura a una implementación completa e independiente que ejecute la nueva versión de la base de datos. Para realizar el paso de actualización y promoción, utilice una solicitud POST al /deployments/{id}/remotes/promotion punto final con la versión a la que desea actualizar en el cuerpo de la solicitud.

Esta solicitud tiene el aspecto siguiente:

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
    }
}' \

skip_initial_backup es opcional. Si se establece en true, el nuevo despliegue no realizará una copia de seguridad inicial cuando se completa la promoción. El nuevo despliegue está disponible en menos tiempo, a expensas de que no se realice una copia de seguridad hasta que se ejecute la siguiente copia de seguridad automática o que realice una copia de seguridad bajo demanda.

Simulacro de la promoción y actualización

Para evaluar los efectos de las actualizaciones de versiones principales, active 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. Esto garantiza que la versión que está ejecutando actualmente 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
    }
}' \

Copia de seguridad y restauración de la actualización

Puede actualizar la versión de la base de datos restaurando una copia de seguridad de los datos en un nuevo despliegue que ejecute la nueva versión de la base de datos.

Actualización en la IU

Actualice a una nueva versión al restaurar una copia de seguridad desde el menú Copias de seguridad del Panel de control de despliegue. Haga clic en Restaurar en una copia de seguridad para acceder a la página de aprovisionamiento en una nueva pestaña, donde podrá cambiar algunas opciones para la nueva implantación. Una de las opciones es la versión de la base de datos, que se rellena automáticamente con las versiones disponibles para que puedas actualizar. Seleccione una versión y haga clic en Crear para iniciar el proceso de aprovisionamiento y restauración.

Actualización a través de la CLI

Para actualizar y restaurar desde una copia de seguridad a través de la IBM Cloud CLI, utilice el comando de aprovisionamiento del controlador de recursos.

ibmcloud resource service-instance-create <DEPLOYMENT_NAME_OR_CRN> <SERVICE_ID> <SERVICE_PLAN_ID> <REGION>

Los parámetros service-name, service-id, service-plan-id y region son todos obligatorios. También debe indicar -p con los parámetros de versión y de ID de copia de seguridad en un objeto JSON. El nuevo despliegue se dimensiona automáticamente con el mismo disco y memoria que el despliegue de origen en el momento de la copia de seguridad.

Este mandato tiene el aspecto siguiente:

ibmcloud resource service-instance-create example-upgrade databases-for-postgresql standard us-south \
-p \ '{
  "backup_id": "crn:v1:bluemix:public:databases-for-postgresql:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
  "version":14
}'

Actualización a través de la API

Complete los pasos necesarios para utilizar la API del controlador de recursos antes de utilizarla para actualizar desde una copia de seguridad. A continuación, envía una solicitud POST a la API. Los parámetros name, target, resource_group y resource_plan_id son obligatorios. También debe indicar la versión y el ID de copia de seguridad. El nuevo despliegue tiene la misma asignación de memoria y de disco que el despliegue de origen en el momento de la copia de seguridad.

Este mandato tiene el aspecto siguiente:

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "my-instance",
    "target": "bluemix-us-south",
    "resource_group": "5g9f447903254bb58972a2f3f5a4c711",
    "resource_plan_id": "databases-for-postgresql-standard",
    "backup_id": "crn:v1:bluemix:public:databases-for-postgresql:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
    "version":14
  }'

Actualización forzada

Después de la fecha de fin de vida útil, todas las implementaciones Databases for PostgreSQL activas en la versión obsoleta se actualizarán de forma obligatoria a la siguiente versión compatible. Por ejemplo, PostgreSQL la versión 13 (obsoleta) se actualiza a la versión 14.

Actualice antes de la fecha de fin de vida útil para evitar los siguientes riesgos:

  • Para este tipo de actualización forzosa no se ofrecen acuerdos de nivel de servicio.
  • Es posible que experimente alguna pérdida de datos.
  • Su aplicación puede experimentar un tiempo de inactividad prolongado.
  • Su aplicación puede dejar de funcionar si es incompatible con la nueva versión.
  • No puede controlar el momento en que se producirá esta actualización para su implantación.
  • No hay proceso de reversión para esta actualización forzada.

Para conocer las fechas de fin de vida útil, consulte la página de política de versiones.

Problemas del usuario administrador durante la actualización de versiones

A partir de PostgreSQL la versión 16, la aplicación de privilegios de roles se ha vuelto más estricta. En cambio, las versiones anteriores permitían que los roles con el atributo CREATEROLE gestionaran otros roles; la versión 16 y posteriores exigen que un rol tenga el atributo ADMIN OPTION sobre otro rol para concederlo o revocarlo.

Si está actualizando su base de datos de PostgreSQL v15 o anterior a PostgreSQL v16 o superior, puede encontrarse con errores relacionados con privilegios, tales como:

ERROR: only roles with the ADMIN OPTION on role "some_role" may grant this role
DETAIL: role "admin" is not permitted to grant role "some_role"

Para solucionar este problema, proporcionamos una función de ayuda incorporada grant_admin_option_to_roles que está diseñada para restaurar el comportamiento esperado de la gestión de roles.

Esta función:

  • Sólo se aplica a las bases de datos actualizadas de PostgreSQL v15 y versiones anteriores a PostgreSQL 16 y versiones posteriores (si se encuentra con el error descrito anteriormente).
  • Acepta una lista arbitraria de roles a los que aplicar la corrección.
  • Sólo puede ser ejecutado por el admin user.
  • Es seguro ejecutarlo varias veces (idempotente).

Uso de ejemplo:

SELECT grant_admin_option_to_roles('role1', 'role2', 'role3');

Esto garantiza que admin user conserve los privilegios adecuados de ADMIN OPTION para gestionar las funciones designadas en las instancias actualizadas.

Registro de cambios para las versiones principales de PostgreSQL