Comment puis-je résoudre les problèmes liés aux mises à niveau des versions majeures d'Amazon RDS pour PostgreSQL ou d'Aurora compatible avec 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 la page pg_upgrade sur le site Web de PostgreSQL.

Lors d’une mise à niveau de versions majeures, 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 vérifie 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 un événement de journal pour l'échec de vérification préalable. Les événements de journaux incluent le nom du fichier, l'horodatage et les raisons de l'échec de la mise à niveau. Pour plus d'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 Aurora PostgreSQL.

Résolution

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. Examinez ces journaux pour obtenir plus d'informations sur les problèmes et les erreurs que vous rencontrez durant la mise à niveau. Pour plus d'informations, consultez la section Surveillance des fichiers journaux Amazon RDS ou Surveillance des fichiers journaux Amazon Aurora.

Mises à niveau de longue durée

Vérifier les activités de maintenance en cours

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

Amazon RDS utilise automatiquement les mises à niveau de versions du moteur pour appliquer les activités de maintenance en attente, telles qu'un correctif du système d'exploitation (OS) sur votre 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 système d'exploitation, la mise à niveau prend plus de temps.

Si votre instance Amazon RDS fait partie d'un déploiement multi-AZ, la maintenance du système d'exploitation entraîne un basculement. Lorsque vous configurez votre 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. Amazon RDS effectue donc 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 votre instance de base de données RDS ou votre instance de base de données Aurora. Vous pouvez également exécuter la commande describe-pending-maintenance-actions de l’AWS CLI suivante sur votre instance :

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

Remarque : Remplacez example-arn par l'ARN de votre instance de base de données.

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

Créer un instantané avant votre mise à niveau

Avant de mettre à niveau la version, il est recommandé de créer un instantané de l'instance de base de données RDS ou du cluster de bases de données Aurora. Si vous avez déjà activé les sauvegardes pour votre instance, Amazon RDS crée 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 dans le cadre de la mise à niveau.

Attendre que le réplica en lecture soit mis à niveau

Lorsque vous effectuez une mise à niveau de versions majeures de votre instance de base de données principale, Amazon RDS met automatiquement à niveau tous les réplicas en lecture dans la même région AWS. Une fois le flux de mise à niveau démarré, les réplicas en lecture attendent que pg_upgrade se termine correctement sur l'instance de base de données principale. Ensuite, la mise à niveau de l'instance de base de données principale attend la fin des mises à niveau des réplicas en lecture. L'instance de base de données s'arrête jusqu'à ce que toutes les mises à niveau soient terminées. Si la durée d’indisponibilité de la mise à niveau est courte, promouvez ou supprimez votre instance de réplica, puis recréez les réplicas en lecture une fois la mise à niveau terminée.

Pour les clusters de base de données Aurora, pg_upgrade met d'abord à niveau l'instance en écriture. Puis, chaque instance de base de données de lecteur 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, des exigences et des processus supplémentaires s'appliquent.

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

Des transactions de longue durée ou une charge de travail élevée 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 pg_cancel_backend ou pg_terminate_backend pour terminer la transaction. Pour plus d'informations sur pg_cancel_backend et pg_terminate_backend, consultez la page Fonctions de signalement du serveur sur le site Web de PostgreSQL.

Veiller à disposer d'une capacité de calcul suffisante

L'utilitaire pg_upgrade peut exiger une grande quantité de ressources de calcul. Pour vérifier que votre capacité de calcul ou de mémoire est suffisante, il est recommandé d'effectuer une mise à niveau de test avant de mettre à niveau vos bases de données de production. La mise à niveau de 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

Vérifier les classes d'instance de base de données non prises en charge

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

Vérifier les transactions préparées en cours

Si des transactions préparées sont en cours dans la base de données, la mise à niveau échoue. L'erreur « There are uncommitted prepared transactions » s'affiche dans le fichier pg_upgrade.log. Avant de commencer la mise à niveau, validez ou annulez toutes les transactions préparées en cours.

Pour vérifier s'il existe des transactions préparées en cours sur votre instance, exécutez la requête suivante :

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

Utiliser 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.

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 vérifier la présence de types de données reg* non pris en charge dans vos 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');

Vérifier les emplacements de réplication logique

Si votre instance utilise des emplacements de réplication logique, vous ne pouvez 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. »

Vous utilisez généralement les emplacements de réplication logique pour la migration du service 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 d’informatique décisionnelle et d'autres cibles. 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 utilisés, ne les supprimez pas. Vous devez attendre de pouvoir supprimer les emplacements de réplication logique avant de pouvoir mettre à niveau la version.

Si vous n'avez pas besoin des emplacements de réplication logique, exécutez 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.

Vérifier les 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 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 commencer la mise à niveau.

Vérifiez l’existence 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. »

Pour résoudre ce problème, supprimez manuellement les colonnes qui utilisent le type de données inconnu ou modifiez-les en fonction d'un type de données pris en charge. Pour rechercher les colonnes de votre 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 for PostgreSQL uniquement) Vérifiez l’existence d’un échec de mise à niveau du réplica en lecture

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

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 base de données principale même après le temps d'attente.
• Le réplica en lecture se trouve dans un état terminal ou de cycle de vie incompatible, tel que storage-full ou incompatible-restore.
• Lorsque la mise à niveau de l'instance de base de données principale démarre, une mise à niveau de versions mineures 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 base de données principale pour synchroniser le dossier de données.

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

Vérifier que votre nom d'utilisateur principal est exact

Si le nom d'utilisateur principal commence par pg_, la mise à niveau échoue 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. »

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

Vérifier l’existence de paramètres incompatibles

L'erreur « 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 votre 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.

Mettre à jour vos 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 affiche un message d’erreur similaire au 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. »

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 AND
name LIKE 'postgis%' OR name LIKE 'address%';

Remarque : Remplacez postgis% par votre extension.

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

ALTER EXTENSION extension_name UPDATE TO 'default_version_number';

Remarque : Remplacez default_version_number par default_version.

Pour plus d'informations, consultez la section Mises à niveau du moteur de base de données RDS for PostgreSQL ou Mise à niveau des clusters de base de données Amazon Aurora PostgreSQL.

Vérifier les modifications apportées au catalogue système de la version cible qui génèrent des problèmes dans les vues

Les colonnes de certaines vues varient selon les versions de PostgreSQL. Par exemple, vous recevrez peut-être un message d'erreur similaire au message suivant :

« PreUpgrade checks failed: The instance could not be upgraded because one or more databases have views or materialized views which depend on 'pg_stat_activity'. Please drop them and try again. »

Cette erreur se produit lorsque vous mettez à niveau la base de données de la version 9.5 vers la version 9.6. Dans l'exemple de message d’erreur précédent, la vue pg_stat_activity est à l'origine du problème. Dans la version 9.6, PostgreSQL a remplacé la colonne en attente par les colonnes wait_event_type et wait_event.

Ou, vous pouvez recevoir un message d'erreur similaire au message suivant :

« 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". »

L'exemple de message d'erreur précédent indique que l'erreur s'est produite parce que la structure du catalogue pg_constraint a changé dans la version 12 de PostgreSQL.

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

Important : Avant d’abandonner les vues, il est recommandé d'utiliser pgdump pour sauvegarder vos 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.

Fin de la mise à niveau

Une fois la mise à niveau terminée, exécutez ANALYZE sur toutes les bases de données utilisateur pour mettre à niveau la table pg_statistics. Une mise à niveau majeure ne déplace pas le contenu de la table pg_statistics vers la nouvelle version. Si vous ne déplacez pas le contenu, vous risquez de faire face à des requêtes lentes.

Informations connexes

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