Comment puis-je résoudre les problèmes liés aux mises à niveau des versions majeures d'Amazon RDS for PostgreSQL ou d'Aurora compatible avec PostgreSQL ?

Brève description

Les mises à niveau de versions mineures sont compatibles avec les versions mineures antérieures et ultérieures de la même version majeure. Cependant, les mises à niveau de versions majeures contiennent des modifications de base de données qui ne sont pas rétrocompatibles avec les applications existantes. Ces 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. Toutefois, pour des problèmes spécifiques au moteur, vous devez consulter les fichiers journaux de base de données pour Amazon RDS for PostgreSQL ou pour Aurora PostgreSQL.

Résolution

L'utilitaire pg_upgrade qui effectue des mises à niveau de versions majeures génère deux journaux : pg_upgrade_internal.log et pg_upgrade_server.log. Amazon RDS ajoute un horodatage au nom de fichier de ces journaux. Consultez ces journaux pour obtenir plus d'informations sur les problèmes et les erreurs rencontrés lors de la mise à niveau. Pour plus d'informations, consultez la section Surveillance des fichiers journaux Amazon RDS ou Surveillance des fichiers journaux Amazon Aurora.

La mise à niveau prend beaucoup de temps

Vérifiez les activités de maintenance en cours

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 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 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 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 si 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 pour votre instance de base de données Aurora. Vous pouvez également exécuter la commande describe-pending-maintenance-actions de l'interface de ligne de commande AWS (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. Si des erreurs surviennent lorsque vous exécutez des commandes AWS CLI, consultez la section Résoudre les erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l’AWS CLI.

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

Créez un instantané avant la mise à niveau

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 avant de mettre à niveau la version. 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. Avec un instantané, vous réduisez 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.

Attendez 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. Vous subissez une panne tant que toutes les mises à niveau ne sont pas terminées. Si la durée d’interruption de la mise à niveau est courte, promouvez ou supprimez votre instance de réplication, 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. Ensuite, chaque instance de base de données en lecture subit une panne lorsque pg_upgrade la met à niveau vers la nouvelle version majeure. Notez que si vous mettez à niveau une base de données globale Aurora, des exigences et des processus supplémentaires s'appliquent.

Résolvez 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 requête de longue durée, utilisez pg_cancel_backend ou pg_terminate_backend pour terminer la requête. Pour plus d'informations sur ces fonctions, consultez la section 9.28.2. Fonctions de signalisation du serveur.

**Assurez-vous que vous disposez d'une capacité de calcul suffisante **

L'utilitaire pg_upgrade peut exiger une grande quantité de ressources de calcul. Il est recommandé d'effectuer une mise à niveau à sec avant de mettre à niveau vos bases de données de production afin de vérifier que votre capacité de calcul ou de mémoire est suffisante. La mise à niveau à sec vérifie également si vous risquez de rencontrer des erreurs de vérification préalable ou de mise à niveau. Vous pouvez restaurer un instantané de l'instance de production et effectuer un essai à blanc avec la même classe d'instance que celle de la base de données de production.

La mise à niveau échoue

Vérifiez 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érifiez 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. Validez ou annulez toutes les transactions préparées en cours avant de commencer une mise à niveau.

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;

Assurez-vous d'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érifiez 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. »

Les emplacements de réplication logique sont généralement utilisés pour la migration du service AWS Database Migration Service (AMS DMS). Ils sont également utilisés 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 utilisés pour vérifier si vous pouvez les supprimer. Si les emplacements de réplication logique sont utilisés, ne les supprimez pas. Avant de mettre à niveau la version, vous devez attendre de pouvoir supprimer les emplacements de réplication logique.

Si vous n'avez pas besoin des emplacements de réplication logique, exécutez les requêtes 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érifiez 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, l'erreur suivante 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. Recréez ensuite un nouveau réplica en lecture en fonction de l'instance principale mise à niveau après la mise à niveau.

Assurez-vous 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érifiez l’existence de paramètres incompatibles

L'erreur de 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 de ces paramètres, puis relancez la mise à niveau.

Mettez à 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 une erreur similaire à l'exemple 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 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 requête 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érifiez l'existence d'un problème dans les vues dû à une modification du catalogue système de la version cible

Les colonnes de certaines vues varient selon les versions de PostgreSQL. Par exemple, vous pourriez recevoir une erreur similaire à l'exemple 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 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.

Dans les journaux, vous pouvez recevoir une erreur similaire à l’exemple 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". »

Dans cet exemple, l'erreur se produit car 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 : Il est recommandé d'utiliser pgdump pour sauvegarder vos vues ou capturer la définition de la vue avant de l’abandonner. Lorsque vous supprimez une vue, vous devez la recréer manuellement après la mise à niveau de la version. Il est possible que vous deviez travailler avec votre administrateur de base de données.

Après 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