ApsaraDB RDS:Mise à niveau d'une version majeure avec déploiement blue-green

Prérequis

Avant de commencer, assurez-vous que :

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

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

• Babelfish n'est pas activé sur l'instance (le numéro de version mineure du moteur ne se termine pas par babelfish).

Facturation

Lorsque vous lancez une mise à niveau par déploiement blue-green, le système crée une nouvelle instance basée sur l'instance source. Les deux instances sont facturées séparément jusqu'à ce que vous libériez l'instance source.

Une fois que vous avez confirmé la stabilité de vos services sur la nouvelle instance, convertissez celle-ci en abonnement et libérez ou résiliez l'instance source.

Impacts potentiels

Examinez les éléments suivants avant de lancer la mise à niveau.

Étape 1 : Exécuter la 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. Localisez l'instance et cliquez sur son ID.

2. (Facultatif) Si des instances en lecture seule existent pour l'instance source, modifiez le point de terminaison de l'instance en lecture seule dans votre application pour le faire pointer vers le point de terminaison de l'instance principale pendant les heures creuses, puis supprimez l'instance en lecture seule.

   La suppression des instances en lecture seule avant la mise à niveau est nécessaire car les nœuds en lecture seule et les slots de réplication ne sont pas automatiquement transférés vers la nouvelle instance. Après la mise à niveau, créez de nouvelles instances en lecture seule sur la nouvelle instance.

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

   Si l'option Major Version Upgrade n'est pas visible, vérifiez que votre instance respecte les prérequis listés ci-dessus.

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

5. Sélectionnez la version cible, définissez le paramètre Upgrade Mode sur Blue-green Deployment, puis cliquez sur OK. Le statut de l'instance passe à Maintaining Instance. Une fois la vérification terminée, le statut revient à Running.

6. Consultez le résultat du rapport de vérification :

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

   • Failed : cliquez sur View Information, corrigez les problèmes identifiés et relancez la vérification.

   Important

   • En cas de résultat Warning, corrigez tous les éléments signalés et relancez la vérification jusqu'à obtenir un résultat Success.

   • Si vous créez un plugin sur l'instance principale après une vérification réussie, relancez la vérification avant de poursuivre.

Étapes suivantes

1. Si vous avez effectué la mise à niveau via la méthode blue-green deployment (cutover), une fois que vous avez confirmé la stabilité de vos services sur la nouvelle instance, libérez l'instance source. Convertissez la méthode de facturation de la nouvelle instance en abonnement pour réduire les coûts.

   La libération d'une instance sous abonnement avant son expiration peut entraîner une perte financière. La nouvelle instance n'hérite d'aucune remise de l'instance source. Les remboursements dépendent de la facture de résiliation réelle et ne sont pas traités en temps réel.

2. (Facultatif) Si vous avez supprimé une instance en lecture seule avant la mise à niveau, recréez-la sur la nouvelle instance :

   1. Créez une instance en lecture seule PostgreSQL sur la nouvelle instance.

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

Référence API

Références

• Présentation des mises à niveau des versions majeures

• Effectuer une mise à niveau de version majeure en mode zéro temps d'arrêt

• Effectuer une mise à niveau de version majeure en mode de mise à niveau sur place

• Interpréter le rapport de vérification de mise à niveau de version majeure pour ApsaraDB RDS for PostgreSQL

FAQ

Puis-je modifier l'instance pendant une mise à niveau de version majeure ?

Non. L'instance ne peut pas être modifiée tant qu'une mise à niveau est en cours. Les modifications ne sont possibles qu'une fois la mise à niveau terminée.

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

Non. Les mises à niveau de version majeure doivent être déclenchées manuellement.

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

Non. La rétrogradation n'est pas prise en charge après une mise à niveau de version majeure. Pour exécuter une version inférieure, achetez une nouvelle instance avec cette version et utilisez Data Transmission Service (DTS) pour migrer vos données.

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

Ce problème survient lorsque la version de PostGIS est antérieure à la 2.5.2 et que vous effectuez une mise à niveau de PostgreSQL 10 ou 11 vers PostgreSQL 12 sans avoir d'abord mis à niveau le plugin PostGIS.

Étape 1 : Mettre à niveau le plugin PostGIS sur l'instance source.

Exécutez la commande suivante deux fois pour vous assurer que la mise à niveau se termine avec succès :

SELECT PostGIS_Extensions_Upgrade();
SELECT PostGIS_Extensions_Upgrade();

Étape 2 : Choisir la correction en fonction de l'utilisation ou non du plugin PostGIS Raster.

Si le plugin PostGIS Raster est utilisé :

1. Sur l'instance source, détachez 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. Après la mise à niveau, recréez la vue sur la nouvelle instance :

   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 le plugin PostGIS Raster n'est pas utilisé :

1. Supprimez le plugin sur l'instance source :

   DROP EXTENSION PostGIS_Raster;

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

Comment prévenir l'incohérence des données causée par la préemption des slots de réplication lors d'une mise à niveau ?

Si l'instance source est un abonné à un slot de réplication, le slot de réplication peut être préempté par la nouvelle instance pendant la mise à niveau, ce qui peut entraîner une incohérence des données.

Pour conserver les données d'abonnement sur l'instance source (version inférieure) : assurez-vous que l'instance source ne tombe pas en panne en raison d'une charge excessive pendant la mise à niveau afin d'éviter la préemption du slot de réplication. Une fois la mise à niveau terminée, désactivez l'abonnement sur la nouvelle instance :

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Pour préserver les données d'abonnement sur la nouvelle instance (version supérieure) : désactivez l'abonnement sur l'instance source avant de démarrer la mise à niveau, puis activez-le sur la nouvelle instance une fois la mise à niveau terminée.

Désactivation sur l'instance source :

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

Activation sur la nouvelle instance :

\c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;

Pour plus d'informations, consultez les rubriques Logical Subscription et Change Tracking.

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

Si une incohérence s'est déjà produite, utilisez l'approche suivante pour la reconcilier :

1. Sur la nouvelle instance, supprimez les données de la table concernée, puis recréez l'abonnement avec copy_data=true. Pour plus de détails, consultez la documentation ALTER SUBSCRIPTION.

2. Utilisez ON CONFLICT pour importer les données depuis l'instance source. L'exemple suivant montre comment gérer différents scénarios de conflit :

   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: keep the existing 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 directly
   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 la mise à niveau ?

Les nœuds en lecture seule et les slots de réplication de l'instance source ne sont pas automatiquement transférés vers la nouvelle instance après la mise à niveau. La suppression de l'instance en lecture seule avant la mise à niveau évite les conflits de points de terminaison et garantit un basculement propre. Après la mise à niveau, créez une nouvelle instance en lecture seule sur la nouvelle instance et mettez à jour le point de terminaison de votre application en conséquence.