Comment résoudre les problèmes liés aux mises à niveau de versions majeures dans Amazon RDS pour PostgreSQL ou l'édition compatible avec Aurora PostgreSQL ?

Brève description

Les mises à niveau de versions majeures contiennent des modifications de base de données qui ne sont pas rétrocompatibles avec les applications existantes. Les mises à niveau peuvent modifier le format interne des tables système, des fichiers de données et du stockage de données. Amazon RDS utilise pg_upgrade pour effectuer des mises à niveau de versions majeures. Pour en savoir plus, consultez pg_upgrade sur le site Web de PostgreSQL.

Lors d'une mise à niveau de version majeure, Amazon RDS exécute une procédure de vérification préalable qui identifie les problèmes susceptibles d'entraîner l'échec de la mise à niveau. Il recherche les éventuelles conditions incompatibles dans toutes les bases de données. Si Amazon RDS identifie un problème pendant le processus de vérification préalable, il crée alors un événement du journal pour l'échec de la vérification préalable. Les événements du journal incluent le nom du fichier, l'horodatage et les raisons de l'échec de la mise à niveau. Pour des informations sur le processus de vérification préalable pour toutes les bases de données, consultez le journal pg_upgrade_precheck.log. Pour des problèmes spécifiques au moteur, vous devez consulter les fichiers journaux de base de données pour Amazon RDS pour PostgreSQL ou pour Compatible avec Aurora PostgreSQL.

Résolution

Si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez alors Résolution des erreurs liées à AWS CLI. Vérifiez également que vous utilisez la version la plus récente d'AWS CLI.

L'utilitaire pg_upgrade qui effectue des mises à niveau de versions majeures génère les journaux pg_upgrade_internal.log et pg_upgrade_server.log. Amazon RDS ajoute un horodatage au nom de fichier des journaux. Passez en revue les journaux pour obtenir plus d'informations sur les problèmes et les erreurs que vous rencontrez durant la mise à niveau. Pour en savoir plus, consultez Surveillance des fichiers journaux Amazon RDS ou Surveillance des fichiers journaux Amazon Aurora.

Mises à niveau de longue durée

Recherche des activités de maintenance en attente

Amazon RDS utilise automatiquement les mises à niveau de versions du moteur pour appliquer des activités de maintenance en attente telles qu'un correctif du système d'exploitation (SE) sur l'instance Amazon RDS. Amazon RDS applique d'abord l'activité en attente, puis met à niveau la version du moteur. Si Amazon RDS doit effectuer des activités de maintenance du SE, la mise à niveau prend alors plus de temps.

Si l'instance Amazon RDS fait partie d'un déploiement multi-AZ, la maintenance du SE entraîne alors un basculement. Lorsque vous configurez l'instance dans un environnement multi-AZ, Amazon RDS crée généralement la sauvegarde de l'instance sur l'instance secondaire. Lors d'un basculement, Amazon RDS crée une sauvegarde sur une nouvelle instance secondaire après la mise à niveau. Cette sauvegarde sur la nouvelle instance secondaire n'est peut-être pas la plus récente de sorte qu'Amazon RDS effectue une sauvegarde complète au lieu d'une sauvegarde incrémentielle. Une sauvegarde complète peut prendre du temps, en particulier lorsque la base de données est volumineuse.

Pour éviter ce problème, recherchez les activités de maintenance en attente pour l'instance de DB RDS ou l'instance de DB Aurora. Vous pouvez également exécuter la commande AWS CLI describe-pending-maintenance-actions suivante sur l'instance :

aws rds describe-pending-maintenance-actions --resource-identifier example-arn

Remarque : Remplacez example-arn par l'ARN de l'instance de DB.

Effectuez les activités de maintenance en attente avant d'effectuer les mises à niveau de versions du moteur de base de données.

Création d'un instantané avant la mise à niveau

Avant de mettre à niveau la version, il est recommandé de créer un instantané de l'instance de DB RDS ou du cluster de DB Aurora. Si vous avez déjà activé les sauvegardes pour l'instance, Amazon RDS crée alors automatiquement un instantané dans le cadre du processus de mise à niveau. Les instantanés réduisent la durée du processus de mise à niveau, car Amazon RDS doit uniquement créer une sauvegarde incrémentielle pour la mise à niveau.

Attente de la mise à niveau du réplica en lecture

Lorsque vous effectuez une mise à niveau de version majeure de l'instance de DB principale, Amazon RDS met automatiquement à niveau tous les réplicas en lecture dans la même région AWS. Une fois le flux de travail mise à niveau démarré, les réplicas en lecture attendent que pg_upgrade se termine avec succès sur l'instance de DB principale. Ensuite, la mise à niveau de l'instance de DB principale attend la fin des mises à niveau des réplicas en lecture. L'instance de DB s'arrête jusqu'à ce que toutes les mises à niveau soient terminées. Si la fenêtre de durée d'indisponibilité de la mise à niveau est courte, promouvez ou supprimez alors l'instance de réplica. Recréez ensuite les réplicas en lecture une fois la mise à niveau terminée.

Pour les clusters de DB Aurora, pg_upgrade met d'abord à niveau l'instance en écriture. Ensuite, chaque instance de DB en lecture s'arrête lorsque pg_upgrade la met à niveau vers la nouvelle version majeure.

Remarque : Si vous mettez à niveau une base de données globale Aurora, vous devez alors suivre desexigences et des processus supplémentaires.

Résolution des transactions de longue durée ou des charges de travail élevées avant la mise à niveau

Des transactions de longue durée ou des charges de travail élevées peuvent augmenter le temps nécessaire à Amazon RDS pour arrêter la base de données et mettre à niveau le moteur de base de données.

Pour identifier les transactions de longue durée, exécutez la requête suivante :

SQL>SELECT pid, datname, application_name, state, age(query_start, clock_timestamp()), usename, query
FROM pg_stat_activity
WHERE query NOT ILIKE '%pg_stat_activity%' AND
usename!='rdsadmin'
ORDER BY query_start desc;

Si vous identifiez une transaction de longue durée, utilisez alors pg_cancel_backend ou pg_terminate_backend pour terminer la transaction. Pour en savoir plus sur pg_cancel_backend et pg_terminate_backend, consultez Fonctions de signalement du serveur sur le site Web de PostgreSQL.

Vérification de la capacité de calcul suffisante

L'utilitaire pg_upgrade peut exiger une grande quantité de ressources de calcul. Pour vérifier la capacité de calcul, de mémoire et de stockage disponible, il est recommandé d'effectuer une mise à niveau test avant de mettre à niveau les bases de données de production. La mise à niveau test vérifie également si vous risquez de rencontrer des erreurs de vérification préalable ou de mise à niveau. Vous pouvez restaurer l'instantané de l'instance de production et effectuer un test avec la même classe d'instance que la classe d'instance de la base de données de production.

Échecs de mise à niveau

Recherche des classes d'instance de DB et des versions de moteur non prises en charge

Si la classe d'instance de l'instance de DB n'est pas compatible avec la version de PostgreSQL vers laquelle vous effectuez la mise à niveau, la mise à niveau échoue alors. Vérifiez la compatibilité de la version du moteur avec la classe d'instance pour Amazon RDS ou pour Aurora.

Pour vérifier les versions de moteur compatibles pour une mise à niveau de version de moteur, exécutez la commande describe-db-engine-versions suivante :

aws rds describe-db-engine-versions --engine postgres --engine-version your-version --query "DBEngineVersions[].ValidUpgradeTarget[].{EngineVersion:EngineVersion}" --output text

Remarque : Remplacez your-version par la version du moteur.

Si la version actuelle n'est pas compatible, il est alors recommandé de mettre à niveau vers la version mineure la plus récente. Vous pouvez également mettre à niveau vers l'une des autres versions de mise à niveau disponibles. Pour des informations sur les mises à niveau des versions du moteur, consultez Choix d'une version majeure pour une mise à niveau de RDS pour PostgreSQL.

Recherche des transactions préparées ouvertes

Si des transactions préparées sont ouvertes dans la base de données, la mise à niveau échoue alors. L'erreur « There are uncommitted prepared transactions » (Il existe des transactions préparées non validées) s'affiche dans le fichier pg_upgrade.log. Avant de démarrer la mise à niveau, validez ou annulez toutes les transactions préparées ouvertes.

Pour rechercher des transactions préparées ouvertes sur l'instance, exécutez la requête suivante :

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

Utilisation d'un type de données pris en charge

Vous ne pouvez mettre à niveau la version que pour les types de données regclass, regrole et regtype. L'utilitaire pg_upgrade ne peut pas mettre à niveau les bases de données qui incluent des colonnes de table utilisant les types de référencement d'identifiant d'objet (OID) reg*. Si vous utilisez un type de données regcollation, regconfig, regdictionary, regnamespace, regoper, regoperator, regproc ou regprocedure, la mise à niveau échoue alors.

Pour résoudre ce problème, supprimez toutes les utilisations des types de données reg*, à l'exception de regclass, regrole et regtype, avant de mettre à niveau le moteur de données. Pour rechercher les types de données reg* non pris en charge dans les tables, exécutez la requête suivante :

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');

Recherche des emplacements de réplication logique

Si l'instance comporte des emplacements de réplication logique, vous ne pouvez alors pas la mettre à niveau et le message d'erreur suivant s'affiche dans le fichier pg_upgrade.log :

« The instance could not be upgraded because one or more databases have logical replication slots. Please drop all logical replication slots and try again. » (L'instance n'a pas pu être mise à niveau, car une ou plusieurs bases de données comportent des emplacements de réplication logique. Veuillez supprimer tous les emplacements de réplication logique et réessayez.)

Vous utilisez généralement les emplacements de réplication logique pour les migrations d'AWS Database Migration Service (AMS DMS). Vous les utilisez également pour répliquer des tables de bases de données vers des lacs de données, des outils de veille économique et d'autres destinations. Assurez-vous de connaître l'objectif des emplacements de réplication logique que vous utilisez pour déterminer si vous pouvez les supprimer. Si les emplacements de réplication logique sont en cours d'utilisation, ne les supprimez pas. Vous devez attendre pour mettre à niveau la version avant de pouvoir supprimer les emplacements de réplication logique.

Si vous n'avez pas besoin des emplacements de réplication logique, exécutez alors les commandes suivantes pour les supprimer :

SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot(slot_name);

Remarque : Remplacez slot_name par le nom de l'emplacement de réplication logique.

Recherche des problèmes de stockage

Si l'espace disponible sur l'instance est insuffisant lors de l'exécution du script pg_upgrade, la mise à niveau échoue alors et le message d'erreur suivant s'affiche :

« pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] could not execute query: ERROR: could not create file "base/12345/12345678": No space keyword" left on device »

Pour résoudre ce problème, assurez-vous que l'instance dispose d'un espace de stockage disponible suffisant avant de démarrer la mise à niveau.

Recherche de types de données inconnus

Vous ne pouvez pas utiliser de types de données inconnus dans les versions 10 et ultérieures de PostgreSQL. Par exemple, si une base de données PostgreSQL version 9.6 utilise le type de données inconnu, le message d'erreur suivant s'affiche lors de la mise à niveau vers la version 10 :

« 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. » (L'instance n'a pas pu être mise à niveau, car le type de données « inconnu » est utilisé dans les tables utilisateur. Veuillez supprimer toutes les utilisations du type de données « inconnu » et réessayez.)

Pour résoudre ce problème, supprimez manuellement les colonnes qui utilisent le type de données inconnu ou modifiez-les vers un type de données pris en charge.

Pour trouver les colonnes de la base de données qui utilisent le type de données inconnu, exécutez la requête suivante :

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

(RDS pour PostgreSQL uniquement) Recherche d'un échec de la mise à niveau du réplica en lecture

Si l'instance PostgreSQL comporte des réplicas en lecture, les échecs de mise à niveau des réplicas en lecture peuvent alors entraîner le blocage ou l'échec de la mise à niveau de l'instance principale. Amazon RDS définit un réplica en lecture ayant échoué sur l'état incompatible-restore, puis arrête la réplication sur l'instance de DB.

La mise à niveau d'un réplica en lecture peut échouer pour l'une des raisons suivantes :

• Le réplica en lecture ne peut pas rattraper l'instance de DB principale même après le temps d'attente.
• Le réplica en lecture se trouve dans un état de cycle de vie terminal ou incompatible tel que storage-full ou incompatible-restore.
• Lorsque la mise à niveau de l'instance de DB principale démarre, une mise à niveau de version mineure distincte est exécutée sur le réplica en lecture.
• Le réplica en lecture utilise des paramètres incompatibles.
• Le réplica en lecture ne peut pas communiquer avec l'instance de DB principale pour synchroniser le dossier de données.

Pour résoudre ce problème, supprimez le réplica en lecture. Ensuite, créez un nouveau réplica en lecture en fonction de l'instance principale mise à niveau après la mise à niveau.

Vérification de l'exactitude du nom d'utilisateur principal

Si le nom d'utilisateur principal commence par pg_, la mise à niveau échoue alors et le message d'erreur suivant s'affiche :

« PreUpgrade checks failed: The instance could not be upgraded because one or more role names start with 'pg_'. Please rename all roles with names that start with 'pg_' and try again. » (Échec des vérifications préalables à la mise à niveau : l'instance n'a pas pu être mise à niveau, car un ou plusieurs noms de rôles commencent par ’pg_’. Veuillez renommer tous les rôles avec des noms qui commencent par ’pg_’ et réessayez.)

Pour résoudre ce problème, créez un autre utilisateur avec le rôle rds_superuser qui ne commence pas par pg_.

Recherche des paramètres incompatibles

L'erreur « incompatible parameters » (paramètres incompatibles) se produit lorsque la valeur d'un paramètre lié à la mémoire, tel que shared_buffer ou work_memory, est trop élevée pour la configuration. Cette erreur entraîne l'échec du script de mise à niveau. Pour résoudre le problème, réduisez les valeurs des paramètres, puis relancez la mise à niveau.

Mise à jour des extensions avant de procéder à la mise à niveau

Les mises à niveau de versions majeures ne mettent pas à niveau les extensions PostgreSQL. Si vous ne mettez pas à jour les extensions avant une mise à niveau de version majeure, le fichier pg_upgrade.log peut afficher le message d'erreur suivant :

« The Logs indicates that the RDS instance ''abcd'' has older version of PostGIS extension or its dependent extensions (address_standardizer,address_standardizer_data_us, postgis_tiger_geocoder, postgis_topology, postgis_raster) installed as against the current version required for the upgrade. » (Les journaux indiquent que l'instance RDS « abcd » présente une version antérieure de l'extension PostGIS ou de ses extensions dépendantes (address_standardizer,address_standardizer_data_us, postgis_tiger_geocoder, postgis_topology, postgis_raster) installées par rapport à la version actuelle requise pour la mise à niveau.)

L'exemple de message d'erreur précédent montre un problème lié à l'extension PostGIS. Pour résoudre ce problème, exécutez la requête suivante pour vérifier les versions par défaut et installées de PostGIS et de ses extensions dépendantes :

SELECT name, default_version, installed_versionFROM pg_available_extensions WHERE installed_version IS NOT NULL ANDname LIKE 'postgis%' OR name LIKE 'address%';

Remarque : Remplacez postgis% par l'extension.

Si la valeur de installed_version est inférieure à la valeur de default_version, vous devez alors mettre à jour PostGIS vers la version par défaut. Pour mettre à jour l'extension, exécutez la commande suivante :

ALTER EXTENSION extension_name UPDATE TO 'default_version_number';

Remarque : Remplacez default_version_number par la valeur default_version.

Pour en savoir plus, consultez Mises à niveau du moteur de DB RDS for PostgreSQL ou Mise à niveau des clusters de DB compatibles avec Amazon Aurora PostgreSQL.

Recherche des modifications apportées au catalogue système de la version qui pose des problèmes dans les vues

Les colonnes de certaines vues varient selon les versions de PostgreSQL. Par exemple, un message d'erreur similaire au message suivant peut s'afficher :

« pg_restore: error: could not execute query: ERROR: column reference 'backend_type' is ambiguous » (pg_restore : erreur : impossible d'exécuter la requête : ERREUR : la référence de colonne « backend_type » est ambiguë)

Cette erreur se produit lorsque vous essayez de mettre à niveau la base de données de la version 12.x vers la version 13.x et que ** pg_stat_activity** possède des structures différentes dans les versions 12.x et 13.x.

Afin de résoudre ce problème, procédez comme suit :

1. Exécutez la commande suivante pour interroger la définition de la vue :

   SELECT pg_get_viewdef('pg_stat_activity_allusers', true);

2. Exécutez la commande suivante pour supprimer la vue :

   DROP VIEW pg_stat_activity_allusers;

3. Mettez à niveau la version du moteur.

4. Exécutez la commande suivante pour recréer la vue :

   CREATE VIEW pg_stat_activity_allusers AS SELECT * FROM get_sa();
   GRANT SELECT ON pg_stat_activity_allusers TO public;

Sinon, un message d'erreur similaire au message suivant peut s'afficher :

« pg_restore: from TOC entry abc; abc abcd VIEW sys_user_constraints art pg_restore: error: could not execute query: ERROR: column c.consrc does not exist LINE 18: 'c'.'consrc' AS 'search_condition', ^ HINT: Perhaps you meant to reference the column 'c.conkey' or the column 'c.conbin'. » (pg_restore: depuis l'entrée TOC abc ; abc abcd VIEW sys_user_constraints art pg_restore : erreur : impossible d'exécuter la requête : ERREUR : la colonne c.consrc n'existe past LIGNE 18 : 'c'.'consrc' AS 'search_condition', ^ ASTUCE : vous souhaitiez peut-être désigner la colonne 'c.conkey' ou la colonne 'c.conbin'.)

Cette erreur se produit lorsque la structure du catalogue pg_constraints a changé dans la version 12 de PostgreSQL.

Pour résoudre ce problème, supprimez les vues en fonction des catalogues système de la version de destination.

Important : Avant de supprimer les vues, il est recommandé d'utiliser pgdump pour sauvegarder les vues ou capturer la définition des vues. Lorsque vous supprimez une vue, vous ou votre administrateur de base de données devez la recréer manuellement après la mise à niveau de la version.

Recherche des tables étrangères avec une valeur de pré-extraction

Utilisez l'extension oracle_fdw pour pré-extraire entre 0 et 10 240 lignes à partir des bases de données Oracle. Définissez le paramètre prefetch (pré-extraire) dans la clause OPTIONS de la table étrangère. Des valeurs plus élevées améliorent les performances, mais utilisent plus de mémoire sur le serveur PostgreSQL. Pour réduire l'utilisation de la mémoire, il est recommandé de définir prefetch (pré-extraire) lors de la phase de vérification préalable d'une mise à niveau de version majeure.

Si la valeur prefetch (pré-extraire) est supérieure à 1 000, le message d'erreur suivant peut alors s'afficher :

« pg_restore: error: could not execute query: ERROR: invalid value for option 'prefetch' » (pg_restore : erreur : impossible d'exécuter la requête : ERREUR : valeur non valide pour l'option « prefetch » (pré-extraire))

Remarque : Les valeurs valides dans ce contexte sont des entiers compris entre 0 et 1 000.

Pour résoudre le problème, définissez les valeurs de pré-extraction entre 1 et 1 000 sur toutes les tables étrangères, puis réessayez la mise à niveau.

Pour modifier les tables étrangères, exécutez la commande suivante :

ALTER FOREIGN TABLE dwh_ddl_sync.fdw_all_tab_cols OPTIONS (SET prefetch '999');

Pour répertorier toutes les tables étrangères, exécutez la commande suivante :

SELECT * from information_schema.foreign_tables;

Pour vérifier la valeur prefetch (pré-extraire) des tables, exécutez la commande suivante :

SELECT * FROM pg_foreign_table;

Vérification de la mise à jour du cluster compatible avec Babelfish pour Aurora PostgreSQL

Lorsque vous effectuez une mise à niveau de version majeure du moteur sur un cluster compatible avec Babelfish pour Aurora PostgreSQL, un message d'erreur similaire au message suivant peut s'afficher :

« You can't perform a multi major version upgrade on a Babelfish for Aurora PostgreSQL DB cluster 13.20 and lower versions. » (Vous ne pouvez pas effectuer une mise à niveau de plusieurs versions majeures sur un cluster de DB Babelfish pour Aurora PostgreSQL 13.20 et les versions inférieures.)

Pour résoudre ce problème, mettez à niveau le cluster vers une version qui prend en charge la mise à niveau de version majeure, puis mettez à niveau vers la version majeure suivante.

Après la fin de la mise à niveau

Une fois la mise à niveau terminée, exécutez la commande ** ANALYZE** sur toutes les bases de données utilisateur pour mettre à jour la table pg_statistics. Les mises à niveau de versions majeures ne migrent pas le contenu de la table pg_statistics vers la nouvelle version. Si vous ne migrez pas le contenu, vous risquez alors de faire face à des requêtes lentes.

Informations connexes

Présentation des processus de mise à niveau d'Aurora PostgreSQL

Recommandations de mise à niveau d'Amazon RDS vers les versions majeures et mineures de PostgreSQL