Comment effectuer une mise à niveau de version majeure de RDS pour PostgreSQL - Amazon Relational Database Service

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comment effectuer une mise à niveau de version majeure de RDS pour PostgreSQL

Nous vous recommandons le processus suivant lors d'une mise à niveau de version majeure sur une base de données Amazon RDS for PostgreSQL :

  1. Préparez un groupe de paramètres compatible avec la version – Si vous utilisez un groupe de paramètres personnalisé, vous avez deux options. Vous pouvez spécifier un groupe de paramètres par défaut pour la nouvelle version du moteur de base de données. Ou vous pouvez créer votre propre groupe de paramètres personnalisé pour la nouvelle version du moteur de base de données Pour plus d’informations, consultez Groupes de paramètres pour (Amazon RDS) et Utilisation des groupes de paramètres de clusters de base de données pour les clusters de base de données Multi-AZ.

  2. Vérifiez les classes de bases de données non prises en charge : vérifiez que la classe d'instances de votre base de données est compatible avec la version PostgreSQL vers laquelle vous effectuez la mise à niveau. Pour de plus amples informations, veuillez consulter Moteurs de base de données pris en charge pour les classes d'instance de base de données.

  3. Recherchez une utilisation non prise en charge :

    • Transactions préparées – Validez ou restaurez toutes les transactions préparées ouvertes avant d'essayer d'effectuer une mise à niveau.

      Vous pouvez utiliser la requête suivante pour vérifier qu'aucune transaction préparée ouverte ne figure sur votre base de données. 

      SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

    • Types de données Reg* – Supprimez toutes les utilisations des types de données reg* avant d'essayer d'effectuer une mise à niveau. À l'exception de regtype et regclass, vous ne pouvez pas mettre à niveau les types de données reg*. L'utilitaire pg_upgrade ne peut pas conserver ce type de données, qui est utilisé par Amazon RDS pour effectuer la mise à niveau.

      Pour vérifier l'absence de toute utilisation des types de données reg* non pris en charge, utilisez la requête suivante pour chaque base de données. 

      
SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a
  WHERE c.oid = a.attrelid
      AND NOT a.attisdropped
      AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype,
                         'pg_catalog.regprocedure'::pg_catalog.regtype,
                         'pg_catalog.regoper'::pg_catalog.regtype,
                         'pg_catalog.regoperator'::pg_catalog.regtype,
                         'pg_catalog.regconfig'::pg_catalog.regtype,
                         'pg_catalog.regdictionary'::pg_catalog.regtype)
      AND c.relnamespace = n.oid
      AND n.nspname NOT IN ('pg_catalog', 'information_schema');

  4. Vérifiez la présence de bases de données non valides :

    • Assurez-vous qu'aucune base de données n'est invalide. La datconnlimit colonne du pg_database catalogue inclut une valeur de -2 pour marquer comme non valides les bases de données qui ont été interrompues au cours d'une DROP DATABASE opération.

      Utilisez la requête suivante pour vérifier la présence de bases de données non valides :

      SELECT datname FROM pg_database WHERE datconnlimit = - 2;

    • La requête précédente renvoie des noms de base de données non valides. Vous pouvez l'utiliser DROP DATABASE invalid_db_name; pour supprimer les bases de données non valides. Vous pouvez également utiliser la commande suivante pour supprimer les bases de données non valides :

      SELECT 'DROP DATABASE ' || quote_ident(datname) || ';' FROM pg_database WHERE datconnlimit = -2 \gexec

    Pour plus d'informations sur les bases de données non valides, voir Comprendre le comportement d'Autovacuum avec des bases de données non valides.

  5. Traitez les emplacements de réplication logique : une mise à niveau ne peut pas se produire si la base de données possède des emplacements de réplication logique. Les emplacements de réplication logique sont généralement utilisés pour la migration AWS DMS et la réplication de tables de la base de données vers des lacs de données, des outils BI et d'autres cibles. Avant de procéder à la mise à niveau, assurez-vous de connaître l'objectif des emplacements de réplication logique utilisés et confirmez qu'il est possible de les supprimer. Si les emplacements de réplication logique sont toujours utilisés, vous ne devez pas les supprimer et vous ne pouvez pas procéder à la mise à niveau.

    Si les emplacements de réplication logique ne sont pas nécessaires, vous pouvez les supprimer à l'aide du code SQL suivant :

    SELECT * FROM pg_replication_slots WHERE slot_type NOT LIKE 'physical';
SELECT pg_drop_replication_slot(slot_name);

    Les installations de réplication logique qui utilisent l'extension pglogical doivent également avoir des emplacements supprimés pour une mise à niveau de version majeure réussie. Pour obtenir des informations sur la façon d'identifier et de supprimer les emplacements créés à l'aide de l'extension pglogical, consultez Gestion des emplacements de réplication logiques pour SQL.

  6. Traitez les réplicas en lecture : une mise à niveau d'une instance de base de données mono-AZ ou d'un déploiement d'instance de base de données multi-AZ met également à niveau les réplicas en lecture dans la région ainsi que l'instance de base de données principale. Amazon RDS ne met pas à niveau les réplicas en lecture d'un cluster de bases de données multi-AZ.

    Vous ne pouvez pas mettre à niveau les réplicas en lecture séparément. Si vous le pouviez, cela pourrait conduire à des situations où les bases de données principale et de réplica auraient des versions majeures différentes de PostgreSQL. Toutefois, les mises à niveau de réplica en lecture peuvent augmenter les temps d'arrêt sur l'instance de base de données principale. Pour éviter la mise à niveau d'un réplica en lecture, promouvez le réplica en instance autonome ou supprimez-le avant de démarrer le processus de mise à niveau.

    Le processus de mise à niveau recrée le groupe de paramètres du réplica en lecture en fonction du groupe de paramètres actuel du réplica en lecture. Vous pouvez appliquer un groupe de paramètres personnalisé à un réplica en lecture uniquement une fois la mise à niveau terminée en modifiant le réplica en lecture. Pour plus d'informations sur les réplicas en lecture, consultez Utilisation de réplicas en lecture pour Amazon RDS for PostgreSQL.

  7. Gérez les intégrations sans ETL : si vous avez une intégration zéro ETL existante, supprimez-la avant d'effectuer une mise à niveau de version majeure. Ensuite, une fois la mise à niveau terminée, recréez l'intégration.

  8. Effectuez une sauvegarde – Nous vous recommandons d'effectuer une sauvegarde avant d'effectuer la mise à niveau de version majeure, afin de disposer d'un point de restauration connu pour votre base de données. Si la période de conservation des sauvegardes est supérieure à 0, le processus de mise à niveau crée des instantanés de base de données de votre base de données avant et après la mise à niveau. Pour modifier la période de rétention des sauvegardes, consultez Modification d'une RDS instance de base de données Amazon et Modification d'un cluster de base de données multi-AZ pour Amazon RDS.

    Pour effectuer une sauvegarde manuellement, consultez Création d'un instantané de base de données pour une instance de base de données mono-AZ pour Amazon RDS et Création d'un instantané de cluster de base de données multi-AZ pour Amazon RDS.

  9. Mise à niveau de certaines extensions avant une mise à niveau de version majeure – Si vous envisagez d'omettre une version majeure avec la mise à niveau, vous devez mettre à jour certaines extensions avant d'effectuer la mise à niveau de version majeure. Par exemple, la mise à niveau des versions 9.5.x ou 9.6.x vers une version 11.x entraîne une omission de la version majeure. Les extensions à mettre à jour comprennent PostGIS et les extensions connexes pour le traitement des données spatiales.

    • address_standardizer

    • address_standardizer_data_us

    • postgis_raster

    • postgis_tiger_geocoder

    • postgis_topology

    Vous ne pouvez pas passer directement à la version 17 de PostgreSQL si vous rdkit utilisez la version 4.6.0 ou inférieure, et la version 16 ou inférieure de PostgreSQL, en raison d'une incompatibilité. rdkit Vous trouverez ci-dessous les options de mise à niveau :

    • Si vous utilisez PostgreSQL version 13 ou inférieure, vous devez d'abord effectuer une mise à niveau majeure vers la version 14.14 et supérieure 14, les versions 15.9 et supérieures 15, ou les versions 16.5 et supérieures 16, puis effectuer la mise à niveau de version vers PostgreSQL 17.

    • Si vous utilisez PostgreSQL version 14, 15 ou 16, vous devez effectuer une mise à niveau de la version mineure vers les versions 14.14 et supérieures 14, 15.9 et supérieures 15, ou 16.5 et versions 16 supérieures, puis passer à PostgreSQL version 17.

    Exécutez la commande suivante pour chaque extension que vous utilisez :

    ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';

    Pour de plus amples informations, veuillez consulter Mise à niveau des SQL extensions Postgre RDS pour les bases de données SQL Postgre. Pour en savoir plus sur la mise à niveau de PostGIS, consultez Étape 6 : mise à niveau de l'GISextension Post.

  10. Supprimez certaines extensions avant une mise à niveau de version majeure – Une mise à niveau qui omet une version majeure pour passer directement à la version 11.x ne prend pas en charge la mise à jour de l'extension pgRouting. La mise à niveau des versions 9.4.x, 9.5.x ou 9.6.x vers les versions 11.x entraîne l'omission d'une version majeure. Il est plus sûr de supprimer l'extension pgRouting puis de la réinstaller sur une version compatible une fois la mise à niveau effectuée. Pour connaître les versions d'extension vers lesquelles vous pouvez effectuer une mise à jour, veuillez consulter Versions d'SQLextension Postgre prises en charge.

    Les extensions tsearch2 et chkpass ne sont plus prises en charge pour PostgreSQL versions 11 ou ultérieures. Si vous effectuez une mise à niveau vers la version 11.x, supprimez les extensions tsearch2 et chkpass avant la mise à niveau.

  11. Supprimer les types de données inconnus – Supprimez les types de données unknown en fonction de la version cible.

    PostgreSQL version 10 a cessé de prendre en charge le type de données unknown. Si une base de données version 9.6 utilise le type de données unknown, une mise à niveau vers une version 10 affiche un message d'erreur tel que : 

    Database instance is in a state that cannot be upgraded: PreUpgrade checks failed:
The instance could not be upgraded because the 'unknown' data type is used in user tables.
Please remove all usages of the 'unknown' data type and try again."

    Pour rechercher le type de données unknown dans votre base de données afin de pouvoir supprimer la colonne incriminée ou la remplacer par un type de données pris en charge, utilisez le code SQL suivant :

    SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';

  12. Réalisez un essai de mise à niveau – Nous vous recommandons fortement de tester la mise à niveau de version majeure sur un doublon de votre base de données de production avant d'essayer d'effectuer la mise à niveau sur votre base de données de production. Vous pouvez surveiller les plans d'exécution sur la base de données de test dupliquée pour détecter d'éventuelles régressions du plan d'exécution et évaluer ses performances. Pour créer une instance de test dupliquée, vous pouvez soit restaurer votre base de données à partir d'un instantané récent, soit point-in-time restaurer votre base de données à sa date de restauration la plus récente.

    Pour plus d’informations, consultez Restaurer à partir d'un instantané ou Restauration d'une instance de base de données à une heure spécifiée pour Amazon RDS. Pour les clusters de bases de données multi-AZ, consultez Restauration d'un instantané dans un cluster de base de données multi-AZ ou Restauration d'un cluster de base de données multi-AZ à une date définie.

    Pour en savoir plus sur la procédure de mise à niveau, consultez Mise à niveau manuelle de la version du moteur.

    Lors de la mise à niveau d'une base de données de version 9.6 vers la version 10, sachez que PostgreSQL 10 active les requêtes parallèles par défaut. Vous pouvez tester l'impact du parallélisme avant la mise à niveau en modifiant le paramètre max_parallel_workers_per_gather sur votre base de données de test et en spécifiant 2.

    Note

    La valeur par défaut du paramètre max_parallel_workers_per_gather dans le groupe de paramètres de base de données default.postgresql10 est 2.

    Pour de plus amples informations, veuillez consulter Parallel Query dans la documentation PostgreSQL. Pour désactiver le parallélisme sur la version 10, définissez le paramètre max_parallel_workers_per_gather sur 0.

    Durant la mise à niveau de version majeure, les bases de données public et template1, ainsi que le schéma public figurant dans chaque base de données, sont renommés temporairement. Ces objets apparaissent dans les journaux avec leur nom d'origine et une chaîne aléatoire ajoutée. Cette chaîne est ajoutée afin que les paramètres personnalisés tels que locale et owner soient conservés au cours de la mise à niveau de version majeure. À la fin de la mise à niveau, les objets reprennent leurs noms d'origine.

    Note

    Pendant le processus de mise à niveau de la version majeure, vous ne pouvez pas point-in-time restaurer votre instance de base de données ou votre cluster de base de données multi-AZ. Une fois qu'Amazon RDS a effectué la mise à niveau, le service réalise une sauvegarde automatique de la base de données. Vous pouvez effectuer une point-in-time restauration avant le début de la mise à niveau et une fois la sauvegarde automatique de votre base de données terminée.

  13. Résolvez les problèmes si une mise à niveau échoue avec des erreurs de procédure de pré-vérification – Au cours du processus de mise à niveau de version majeure, Amazon RDS for PostgreSQL exécute d'abord une procédure de pré-vérification pour identifier les éventuels problèmes pouvant provoquer un échec de la mise à niveau. Le procédure de pré-vérification recherche les éventuelles conditions d'incompatibilité entre toutes les bases de données de l'instance.

    Si la pré-vérification détecte un problème, elle crée un événement de journal indiquant l'échec de la pré-vérification de mise à niveau. Les détails de la procédure de pré-vérification se trouvent dans un journal de mise à niveau nommé pg_upgrade_precheck.log pour toutes les bases de données d'une base de données. Amazon RDS ajoute un horodatage au nom du fichier. Pour de plus amples informations sur l'affichage des journaux, veuillez consulter Surveillance des fichiers journaux RDSAmazon.

    Si la mise à niveau d'un réplica en lecture échoue au stade de la vérification préalable, la réplication sur le réplica en lecture défaillant est interrompue et le réplica en lecture est mis à l'état résilié. Supprimez le réplica en lecture et recréez un nouveau réplica en lecture basé sur l'instance de base de données principale mise à niveau.

    Résolvez tous les problèmes identifiés dans le journal de pré-vérification puis relancez la mise à niveau de version majeure. Voici un exemple de journal de pré-vérification.

    ------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with the requested major engine version upgrade and try the upgrade again.

* There are uncommitted prepared transactions. Please commit or rollback all prepared transactions.* One or more role names start with 'pg_'. Rename all role names that start with 'pg_'.

* The following issues in the database 'my"million$"db' need to be corrected before upgrading:** The ["line","reg*"] data types are used in user tables. Remove all usage of these data types.
** The database name contains characters that are not supported by RDS for PostgreSQL. Rename the database.
** The database has extensions installed that are not supported on the target database version. Drop the following extensions from your database: ["tsearch2"].

* The following issues in the database 'mydb' need to be corrected before upgrading:** The database has views or materialized views that depend on 'pg_stat_activity'. Drop the views.

  14. Si une mise à niveau de réplica en lecture échoue lors de la mise à niveau de la base de données, résolvez le problème : un réplica en lecture ayant échoué obtient le statut incompatible-restore et la réplication est arrêtée sur la base de données. Supprimez le réplica en lecture et recréez un nouveau réplica en lecture basé sur l'instance de base de données principale mise à niveau.

    Note

    Amazon RDS ne met pas à niveau les réplicas en lecture pour les clusters de bases de données multi-AZ. Si vous effectuez une mise à niveau de version majeure sur un cluster de base de données multi-AZ, l'état de réplication de ses répliques de lecture devient terminé.

    Une mise à niveau de réplica en lecture peut échouer pour les raisons suivantes :

    • Elle n'a pas pu s'aligner sur l'instance de base de données principale même après un temps d'attente.

    • Elle était dans un état de mise hors service ou de cycle de vie incompatible, tel que storage-full, incompatible-restore, etc.

    • Lorsque la mise à niveau de l'instance de base de données principale a démarré, une mise à niveau de version mineure distincte était en cours d'exécution sur le réplica en lecture.

    • Le réplica en lecture utilisait des paramètres incompatibles.

    • Le réplica en lecture n'a pas pu communiquer avec l'instance de base de données principale pour synchroniser le dossier de données.

  15. Mettez à niveau votre base de données de production : quand l'essai de mise à niveau de version majeure est un succès, vous devez être en mesure de mettre à niveau en toute confiance votre base de données de production. Pour de plus amples informations, veuillez consulter Mise à niveau manuelle de la version du moteur.

  16. Exécutez l'opération ANALYZE pour actualiser la table pg_statistic. Vous devez le faire pour chaque base de données de toutes vos bases de données PostgreSQL. Les statistiques de l'optimiseur ne sont pas transférées lors d'une mise à niveau majeure de la version. Vous devez donc régénérer toutes les statistiques pour éviter les problèmes de performances. Exécutez la commande sans paramètres pour générer des statistiques pour toutes les tables normales de la base de données actuelle, comme suit :

    ANALYZE VERBOSE;

    L'indicateur VERBOSE est facultatif, mais son utilisation vous montre la progression. Pour en savoir plus, veuillez consulter ANALYZE dans la documentation PostgreSQL.

    Lorsque vous analysez des tables spécifiques au lieu d'utiliser ANALYZE VERBOSE, exécutez la commande ANALYZE pour chaque table comme suit :

    ANALYZE table_name;

    Pour les tables partitionnées, analysez toujours la table parent. Ce processus :

    • Échantillonne automatiquement les lignes de toutes les partitions

    • Met à jour les statistiques de chaque partition de manière récursive

    • Maintient les statistiques de planification essentielles au niveau des parents

    Bien que les tables parents ne stockent aucune donnée réelle, leur analyse est essentielle pour l'optimisation des requêtes. L'exécution d'ANALYZE uniquement sur des partitions individuelles peut nuire aux performances des requêtes, car l'optimiseur ne disposera pas des statistiques complètes nécessaires à une planification efficace entre partitions.

    Note

    Exécutez ANALYZE sur votre système après la mise à niveau pour éviter les problèmes de performances.

Une fois la mise à niveau de version majeure effectuée, nous vous recommandons d'effectuer les tâches suivantes :

  • Une mise à niveau de PostgreSQL ne met à niveau aucune extension PostgreSQL. Pour mettre à niveau les extensions, veuillez consulter Mise à niveau des SQL extensions Postgre RDS pour les bases de données SQL Postgre.

  • Vous pouvez utiliser Amazon RDS pour consulter deux journaux générés par l'utilitaire pg_upgrade. Il s'agit des journaux pg_upgrade_internal.log et pg_upgrade_server.log. Amazon RDS ajoute un horodatage au nom de fichier de ces journaux. Vous pouvez consultez ces journaux comme tout autre journal. Pour de plus amples informations, veuillez consulter Surveillance des fichiers journaux RDSAmazon.

    Vous pouvez également télécharger les journaux de mise à niveau sur Amazon CloudWatch Logs. Pour de plus amples informations, veuillez consulter Publication de journaux PostgreSQL sur Amazon Logs CloudWatch .

  • Pour vérifier si tout fonctionne comme prévu, testez votre application sur la base de données mise à niveau avec une charge de travail similaire. Une fois la mise à niveau vérifiée, vous pouvez supprimer l'instance de test.