ApsaraDB RDS:Mise à niveau majeure sur place

Prérequis

Avant de commencer, assurez-vous que :

• L'instance exécute ApsaraDB RDS for PostgreSQL 16 ou une version antérieure.

• Le type de stockage est un disque cloud.

• La méthode de facturation est le paiement à l'utilisation ou l'abonnement.

• L'instance n'est pas une instance en lecture seule ni une instance de cluster dédié.

• Babelfish n'est pas activé. Le numéro de version mineure du moteur ne se termine pas par babelfish.

Facturation

Gratuit.

Notes d'utilisation

Consultez les points suivants avant de démarrer la mise à niveau.

SELECT count(1) FROM pg_class;

Étape 1 : Exécuter une vérification préalable à la mise à niveau

1. Connectez-vous à la console ApsaraDB RDS. Dans la barre de navigation supérieure, sélectionnez la région où réside l'instance. Recherchez et cliquez sur l'ID de l'instance.

2. (Facultatif) Si l'instance possède des instances en lecture seule, modifiez le point de terminaison de l'application pour qu'il pointe vers le point de terminaison de l'instance principale au lieu de celui de l'instance en lecture seule, puis supprimez les instances en lecture seule.

   Remarque

   Modifiez le point de terminaison de l'application pendant les heures creuses afin de minimiser l'impact sur le service.

3. Dans le volet de navigation de gauche, cliquez sur Major Version Upgrade.

   Remarque

   Si

   Major Version Upgrade

   n'apparaît pas, vérifiez la version et la configuration de votre instance. Pour plus d'informations, consultez les

   Prérequis

   .

4. Sous l'onglet Upgrade Check, cliquez sur Create upgrade check report.

5. Sélectionnez la version de destination, définissez Upgrade Mode sur Local Upgrade, puis cliquez sur OK. L'état de l'instance passe à Maintaining Instance pendant l'exécution de la vérification, puis revient à Running une fois celle-ci terminée.

6. Examinez les résultats de la vérification :

   • Success ou Warning : passez à l'étape 2.

   • Failed : cliquez sur View Information, corrigez les problèmes identifiés dans le rapport, puis relancez la vérification. Pour plus de détails sur les erreurs courantes, consultez la rubrique Interpréter un rapport de vérification de mise à niveau majeure pour ApsaraDB RDS for PostgreSQL.

   Important

   - Si le résultat est Warning, corrigez les problèmes et relancez la vérification jusqu'à obtenir un résultat Success. - Si vous créez un plugin sur l'instance principale après la réussite de la vérification, relancez celle-ci.

Étape 2 : Mettre à niveau la version majeure du moteur

1. Cliquez sur l'onglet Upgrade Instance. Lisez les avertissements, sélectionnez la version de mise à niveau, puis cliquez sur Create Upgrade Task.

2. Dans la boîte de dialogue, lisez l'invite et cliquez sur OK.

3. Dans la section Create Major Engine Version Upgrade Task, définissez Upgrade Mode sur Local Upgrade et configurez l'Cutover time :

   • immediately : le basculement se produit immédiatement après la fin de la migration.

   • Instance operation and maintenance time : le basculement a lieu dans la fenêtre de maintenance configurée.

4. Cliquez sur Create now. L'état de l'instance passe à Migration in Progress lorsque la tâche de mise à niveau démarre. La durée dépend du nombre d'objets de base de données. Suivez la progression dans le Task Hub.

   Important

   - Les tâches de mise à niveau ne peuvent pas être modifiées ni supprimées après leur création. - Tant que l'instance est en état Migration in Progress, les opérations telles que la modification des paramètres, le redémarrage ou la libération de l'instance ne sont pas disponibles.

5. La mise à niveau est terminée lorsque les instances source et destination affichent toutes deux l'état Running.

   Remarque

   Sous l'onglet

   Upgrade History

   , cliquez sur

   View Information

   dans la colonne

   Upgrade Log

   pour afficher la durée du mode lecture seule et le journal détaillé de la mise à niveau. La durée du mode lecture seule correspond à l'intervalle entre

   Cutover Time

   et

   Cutover End Time

   , hors période de vidage du cache DNS.

Étapes suivantes

Si vous avez supprimé des instances en lecture seule avant la mise à niveau :

1. Créez des instances en lecture seule sur l'instance de destination.

2. Dans votre application, mettez à jour le point de terminaison pour qu'il pointe vers la nouvelle instance en lecture seule.

Référence des résultats de mise à niveau

La colonne Upgrade Result sous l'onglet Upgrade History affiche l'un des états suivants :

Référence API

Références

• Présentation des mises à niveau majeures

• Mettre à niveau une version majeure du moteur avec la méthode zéro temps d'arrêt

• Mettre à niveau une version majeure du moteur avec la méthode de déploiement blue-green

• Interpréter le rapport de vérification de mise à niveau majeure du moteur

FAQ

Puis-je modifier l'instance pendant une mise à niveau majeure du moteur ?

Non. Attendez que la mise à niveau soit terminée avant d'apporter des modifications à l'instance.

Les mises à niveau automatiques de la version majeure du moteur sont-elles prises en charge ?

Non. Les mises à niveau de la version majeure du moteur doivent être initiées manuellement.

Les rétrogradations de la version majeure du moteur sont-elles prises en charge ?

Non. Pour exécuter une version inférieure, achetez une nouvelle instance avec la version cible et utilisez DTS pour migrer les données.

Après la mise à niveau, j'obtiens une erreur de conflit raster_overviews lors de la création d'une vue. Comment résoudre ce problème ?

Ce problème affecte les versions de PostGIS antérieures à la 2.5.2 sur PostgreSQL 10 ou 11 lors de la mise à niveau vers PostgreSQL 12. Suivez ces étapes :

1. Sur l'instance source, mettez à niveau le plugin PostGIS. Exécutez la commande suivante deux fois pour vous assurer qu'elle réussit :

   SELECT PostGIS_Extensions_Upgrade();
   SELECT PostGIS_Extensions_Upgrade();

2. Choisissez la correction en fonction de l'utilisation ou non du plugin PostGIS Raster.

Si vous utilisez PostGIS Raster :

1. Sur l'instance source, supprimez la vue raster_overviews de l'extension et remplacez-la par un espace réservé :

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

2. Mettez à niveau l'instance PostgreSQL vers PostgreSQL 12 au minimum.

3. Sur l'instance de destination, recréez la vue complète et ajoutez-la de nouveau à l'extension :

   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 vous n'utilisez pas PostGIS Raster :

1. Sur l'instance source, supprimez l'extension :

   DROP EXTENSION PostGIS_Raster;

2. Mettez à niveau l'instance PostgreSQL vers PostgreSQL 12 au minimum.

Comment éviter les incohérences de données causées par la préemption des emplacements de réplication lors d'une mise à niveau ?

Choisissez l'une des approches suivantes en fonction de l'emplacement souhaité des données d'abonnement après la mise à niveau.

Conserver les données d'abonnement sur l'instance source :

Assurez-vous que l'instance source ne tombe pas en panne sous une charge excessive pendant la mise à niveau. Si cela se produit, l'emplacement de réplication peut être préempté par l'instance de destination, ce qui entraîne une incohérence des données. Après la mise à niveau, désactivez l'abonnement sur la base de données de destination :

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Déplacer les données d'abonnement vers l'instance de destination :

Avant la mise à niveau, désactivez l'abonnement sur l'instance source :

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Après la mise à niveau, activez l'abonnement sur l'instance de destination :

\c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;

Comment corriger l'incohérence des données d'abonnement après une mise à niveau ?

1. Sur l'instance de destination (version supérieure), supprimez les données des tables concernées. Recréez ensuite l'abonnement avec copy_data=true. Pour plus de détails, consultez la rubrique ALTER SUBSCRIPTION.

2. Utilisez ON CONFLICT pour importer les données de l'instance source (version inférieure) vers la destination. L'exemple suivant illustre le modèle :

   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;

Pourquoi dois-je supprimer les instances en lecture seule avant une mise à niveau majeure du moteur ?

Les nœuds en lecture seule et leurs emplacements de réplication restent attachés à l'instance source après la mise à niveau et ne sont pas automatiquement transférés vers l'instance de destination. Supprimez-les avant la mise à niveau et recréez-les sur l'instance de destination par la suite.