ApsaraDB RDS:In-place major version upgrade

Requisitos previos

Antes de empezar, asegúrese de que:

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

• El tipo de almacenamiento es disco en la nube.

• El método de facturación es pay-as-you-go o suscripción.

• La instancia no es una read-only instance ni una instancia de clúster dedicado.

• Babelfish no está habilitado. El número de versión menor del motor no termina con babelfish.

Facturación

Sin costo.

Notas de uso

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

SELECT count(1) FROM pg_class;

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. Busque el ID de la instancia y haga clic en él.

2. (Opcional) Si la instancia tiene instancias de solo lectura, cambie el endpoint de la aplicación del endpoint de la instancia de solo lectura al endpoint de la instancia principal y luego elimine las instancias de solo lectura.

   Nota

   Cambie el endpoint de la aplicación fuera del horario pico para minimizar el impacto en el servicio.

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

   Nota

   Si

   Major Version Upgrade

   no aparece, compruebe la versión y la configuración de su instancia. Para obtener más información, consulte

   Prerequisites

   .

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

5. Seleccione la versión de destino, establezca Upgrade Mode en Local Upgrade y haga clic en OK. El estado de la instancia cambia a Maintaining Instance mientras se ejecuta la comprobación y vuelve a Running cuando esta finaliza.

6. Revise los resultados de la comprobación:

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

   • Failed: haga clic en View Information, corrija los problemas identificados en el informe y vuelva a ejecutar la comprobación. Para obtener detalles sobre errores comunes, consulte Interpret an ApsaraDB RDS for PostgreSQL major version upgrade check report.

   Importante

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

Paso 2: Actualizar la versión principal del motor

1. Haga clic en la pestaña Upgrade Instance. Lea las advertencias, seleccione la versión de actualización 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 Local Upgrade y configure Cutover time:

   • immediately: el cambio ocurre inmediatamente después de que finaliza la migración.

   • Instance operation and maintenance time: el cambio ocurre dentro de la maintenance window configurada.

4. Haga clic en Create now. El estado de la instancia cambia a Migration in Progress cuando comienza la tarea de actualización. La duración depende del número de objetos de la base de datos. Puede seguir el progreso en Task Hub.

   Importante

   • Las tareas de actualización no se pueden modificar ni eliminar después de su creación. - Mientras la instancia esté en estado Migration in Progress, operaciones como modificar parámetros, reiniciar o liberar la instancia no están disponibles.

5. La actualización se completa cuando tanto la instancia de origen como la de destino muestran el estado Running.

   Nota

   En la pestaña

   Upgrade History

   , haga clic en

   View Information

   en la columna

   Upgrade Log

   para ver la duración del estado de solo lectura y el registro detallado de la actualización. La duración del estado de solo lectura es el tiempo transcurrido entre

   Cutover Time

   y

   Cutover End Time

   , sin incluir el período de limpieza de la caché DNS.

Pasos siguientes

Si eliminó instancias de solo lectura antes de la actualización:

1. Create read-only instances en la instancia de destino.

2. En su aplicación, actualice el endpoint para que apunte a la nueva instancia de solo lectura.

Referencia de resultados de actualización

La columna Upgrade Result en la pestaña Upgrade History muestra uno de los siguientes estados:

Referencia de API

Referencias

• Introduction to major version upgrades

• Upgrade a major engine version using the zero-downtime method

• Upgrade a major engine version using the blue-green deployment method

• Interpret the major engine version upgrade check report

Preguntas frecuentes

¿Puedo modificar la instancia durante una actualización de versión principal del motor?

No. Espere a que finalice la actualización antes de realizar cambios en la instancia.

¿Se admiten actualizaciones automáticas de versión principal del motor?

No. Las actualizaciones de versión principal del motor deben iniciarse manualmente.

¿Se admiten reducciones de versión principal del motor?

No. Para ejecutar una versión inferior, adquiera una nueva instancia en la versión objetivo y utilice DTS para migrar los datos.

Después de la actualización, obtengo un error de conflicto raster_overviews al crear una vista. ¿Cómo lo soluciono?

Esto afecta a versiones de PostGIS anteriores a la 2.5.2 en PostgreSQL 10 u 11 al actualizar a PostgreSQL 12. Siga estos pasos:

1. En la instancia de origen, actualice el plugin PostGIS. Ejecute el siguiente comando dos veces para asegurarse de que se complete correctamente:

   SELECT PostGIS_Extensions_Upgrade();
   SELECT PostGIS_Extensions_Upgrade();

2. Elija la solución según si utiliza el plugin PostGIS Raster.

Si utiliza PostGIS Raster:

1. En la instancia de origen, elimine la vista raster_overviews de la extensión y reemplácela con un marcador de posición:

   ALTER EXTENSION PostGIS_Raster DROP VIEW raster_overviews;
   CREATE OR REPLACE VIEW raster_overviews AS SELECT 1;

2. Actualice la instancia de PostgreSQL a PostgreSQL 12 como mínimo.

3. En la instancia de destino, vuelva a crear la vista completa y agréguela nuevamente a la extensión:

   CREATE OR REPLACE VIEW raster_overviews AS
   SELECT
     current_database() AS o_table_catalog,
     n.nspname AS o_table_schema,
     c.relname AS o_table_name,
     a.attname AS o_raster_column,
     current_database() AS r_table_catalog,
     split_part(split_part(s.consrc, '''::name', 1), '''', 2)::name AS r_table_schema,
     split_part(split_part(s.consrc, '''::name', 2), '''', 2)::name AS r_table_name,
     split_part(split_part(s.consrc, '''::name', 3), '''', 2)::name AS r_raster_column,
     trim(both from split_part(s.consrc, ',', 2))::integer AS overview_factor
   FROM
     pg_class c,
     pg_attribute a,
     pg_type t,
     pg_namespace n,
     (
       SELECT connamespace, conrelid, conkey, pg_get_constraintdef(oid) AS consrc
       FROM pg_constraint
     ) AS s
   WHERE
     t.typname = 'raster'::name
     AND a.attisdropped = false
     AND a.atttypid = t.oid
     AND a.attrelid = c.oid
     AND c.relnamespace = n.oid
     AND c.relkind = ANY(ARRAY['r'::char, 'v'::char, 'm'::char, 'f'::char])
     AND s.connamespace = n.oid
     AND s.conrelid = c.oid
     AND s.consrc LIKE '%_overview_constraint(%'
     AND NOT pg_is_other_temp_schema(c.relnamespace)
     AND has_table_privilege(c.oid, 'SELECT'::text);
   
   ALTER EXTENSION PostGIS_Raster ADD VIEW raster_overviews;

Si no utiliza PostGIS Raster:

1. En la instancia de origen, elimine la extensión:

   DROP EXTENSION PostGIS_Raster;

2. Actualice la instancia de PostgreSQL a PostgreSQL 12 como mínimo.

¿Cómo evito la inconsistencia de datos causada por la apropiación de slots de replicación durante una actualización?

Elija uno de los siguientes enfoques según dónde desee que residan los datos de la suscripción después de la actualización.

Mantener los datos de la suscripción en la instancia de origen:

Asegúrese de que la instancia de origen no se caiga debido a una carga excesiva durante la actualización. Si esto ocurre, la instancia de destino podría apropiarse del slot de replicación, lo que causaría inconsistencia en los datos. Después de la actualización, deshabilite la suscripción en la base de datos de destino:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Mover los datos de la suscripción a la instancia de destino:

Antes de la actualización, deshabilite la suscripción en la instancia de origen:

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Después de la actualización, habilite la suscripción en la instancia de destino:

\c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;

¿Cómo soluciono la inconsistencia de datos de la suscripción después de una actualización?

1. En la instancia de destino (versión superior), elimine los datos de la tabla afectada. Luego, vuelva a crear la suscripción con copy_data=true. Para obtener más detalles, consulte ALTER SUBSCRIPTION.

2. Utilice ON CONFLICT para importar los datos de la instancia de origen (versión inferior) al destino. El siguiente ejemplo muestra el patrón:

   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');
   
   -- Newer timestamp: update the existing row
   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;
   
   -- Older timestamp: skip the row
   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;
   
   -- New row: insert
   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;

¿Por qué necesito eliminar las instancias de solo lectura antes de una actualización de versión principal del motor?

Los nodos de solo lectura y sus slots de replicación permanecen vinculados a la instancia de origen después de la actualización y no se transfieren automáticamente a la instancia de destino. Elimínelos antes de la actualización y vuélvalos a crear en la instancia de destino posteriormente.