ApsaraDB RDS:Upgrade a major version using zero-downtime mode

Funcionamiento

El modo sin tiempo de inactividad ejecuta pg_upgrade para actualizar una instantánea de su instancia a la versión destino y luego utiliza la replicación lógica nativa para sincronizar los cambios incrementales desde el origen. Usted debe verificar la instancia de destino antes de iniciar el cambio. Al comenzar el cambio, la instancia pasa brevemente a solo lectura mientras se sincronizan las secuencias y, posteriormente, el tráfico se redirige a la nueva versión.

Facturación

Sin costo adicional.

Requisitos previos

Antes de empezar, asegúrese de que:

• La instancia ejecute ApsaraDB RDS for PostgreSQL 16 o una versión anterior.

• El tipo de almacenamiento sea disco en la nube. Las instancias con discos locales de alto rendimiento solo pueden usar blue-green deployment mode.

• El método de facturación sea pay-as-you-go o suscripción. Las instancias serverless solo pueden usar blue-green deployment mode.

• La instancia no sea una read-only instance ni una dedicated cluster instance.

• El parámetro wal_level esté establecido en logical. Las actualizaciones sin tiempo de inactividad dependen de la replicación lógica, por lo que si wal_level está en replica o minimal, la comprobación previa a la actualización fallará. De lo contrario, modify the instance parameters antes de continuar.

• Babelfish no esté habilitado. El número de versión menor del motor no debe terminar con babelfish.

Notas de uso

Revise la siguiente información antes de iniciar la actualización.

Impacto en el negocio

Las operaciones DDL (Lenguaje de Definición de Datos) están prohibidas desde el momento en que comienza la actualización hasta que se completa el cambio. El tiempo de inactividad de la instancia de origen se mide en segundos y depende de la cantidad de secuencias y del volumen de escrituras de transacciones grandes.

Slots de replicación

• Si la instancia de origen tiene una publicación (extremo publicador de un slot de replicación), dicho slot se pierde después de la actualización.

• Si la instancia de origen tiene un suscriptor (extremo suscriptor de un slot de replicación), la actualización puede causar problemas de sincronización de datos debido a la apropiación del slot de replicación. Consulte la sección de preguntas frecuentes para obtener más detalles.

Cambios de parámetros

• Los parámetros no compatibles con la versión de destino se eliminan automáticamente.

• Los parámetros cuyos valores caen fuera del rango válido para la versión de destino se restablecen a los valores predeterminados de la plantilla de parámetros de dicha versión.

• statement_timeout se establece temporalmente en 0 durante la actualización y se restaura a su valor original al finalizar.

Tareas de DTS

Si la instancia es origen o destino de Data Transmission Service (DTS), recreate the DTS task después de la actualización.

Compatibilidad de plugins

La actualización lleva la instancia automáticamente a la última versión menor del motor, lo cual puede causar problemas de compatibilidad con los plugins.

Copias de seguridad

Se realiza una copia de seguridad completa tanto antes como después de la actualización para permitir la recuperación basada en clonación.

Impacto en las distintas etapas de la actualización

Una vez iniciada la tarea de actualización, vaya a la pestaña Upgrade History. En la columna Upgrade Log de la tarea de actualización correspondiente, haga clic en View Information para consultar el proceso detallado de la actualización.

Paso 1: Ejecutar una comprobación previa a la actualización

1. Inicie sesión en la consola de ApsaraDB RDS. En la barra de navegación superior, seleccione la región donde reside la instancia, localícela y haga clic en su ID.

2. En el panel de navegación izquierdo, haga clic en Major Version Upgrade.

   Si Major Version Upgrade no aparece, compruebe la versión y la configuración de su instancia. Para más detalles, consulte Prerequisites .

3. En la pestaña Upgrade Check, haga clic en Create upgrade check report.

4. Seleccione la versión de destino, establezca Upgrade Mode en Zero Downtime y haga clic en OK. El estado de la instancia cambia a Maintaining Instance. Una vez completada la comprobación, el estado vuelve a Running.

5. Revise el resultado de la comprobación: Para ayuda sobre cómo interpretar los resultados, consulte Interpret an ApsaraDB RDS for PostgreSQL major version upgrade check report.

   • Success o Warning: continúe con el Paso 2.

   • Failed: haga clic en View Information, corrija los problemas reportados y vuelva a ejecutar la comprobación.

   Importante

   • Si el resultado es Warning, corrija todos los problemas reportados y vuelva a ejecutar la comprobación hasta que el resultado sea Success. - Si crea un plugin en la instancia principal después de una comprobación exitosa, ejecute la comprobación nuevamente antes de actualizar.

Paso 2: Iniciar la actualización

Antes de realizar este paso, asegúrese de haber completado el Paso 1: Ejecutar una comprobación previa a la actualización: en la pestaña Upgrade Check, cree un informe de comprobación de actualización y confirme que el resultado sea Success o Warning antes de crear la tarea de actualización.

1. Haga clic en la pestaña Upgrade Instance, lea las advertencias, seleccione una versión en Select The Destination Version y haga clic en Create Upgrade Task.

2. En el cuadro de diálogo, lea el mensaje y haga clic en OK.

3. En la sección Create Major Engine Version Upgrade Task, establezca Upgrade Mode en Zero Downtime y haga clic en Create.

Cuando el estado de la instancia cambie a Migrating, la tarea de actualización habrá comenzado.

El tiempo requerido depende de la cantidad de objetos de base de datos en la instancia: a mayor cantidad de objetos, mayor será la duración. Puede seguir el progreso en Task Hub.

Paso 3: Verificar y realizar el cambio

Descripción de los resultados de actualización

La columna Upgrade Result en la pestaña Upgrade History muestra uno de los siguientes valores durante la actualización.

Referencia de API

Preguntas frecuentes

SELECT PostGIS_Extensions_Upgrade();
SELECT PostGIS_Extensions_Upgrade();

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

CREATE TABLE my_tbl(id INT PRIMARY KEY, t TIMESTAMP, val TEXT);

INSERT INTO my_tbl VALUES (1, CURRENT_TIMESTAMP, 'a');
INSERT INTO my_tbl VALUES (2, CURRENT_TIMESTAMP, 'b');
INSERT INTO my_tbl VALUES (3, CURRENT_TIMESTAMP, 'c');

-- Update if the incoming row has a newer timestamp
INSERT INTO my_tbl VALUES (1, CURRENT_TIMESTAMP, 'd')
ON CONFLICT(id) DO UPDATE
  SET t = excluded.t, val = excluded.val
  WHERE my_tbl.t < excluded.t;

-- Skip if the incoming row has an older timestamp
INSERT INTO my_tbl VALUES (2, CURRENT_TIMESTAMP - '10 hours'::interval, 'e')
ON CONFLICT(id) DO UPDATE
  SET t = excluded.t, val = excluded.val
  WHERE my_tbl.t < excluded.t;

-- Insert new rows normally
INSERT INTO my_tbl VALUES (5, CURRENT_TIMESTAMP - '10 hours'::interval, 'f')
ON CONFLICT(id) DO UPDATE
  SET t = excluded.t, val = excluded.val
  WHERE my_tbl.t < excluded.t;

Pasos siguientes

• Perform a major version upgrade in blue-green deployment mode

• Perform a major version upgrade in local upgrade mode

• Interpret an ApsaraDB RDS for PostgreSQL major version upgrade check report

• Best practices for zero-downtime major version upgrades