Exécution d'une mise à niveau de version majeure

Choisissez la version majeure souhaitée dans la liste des cibles disponibles parmi celles répertoriées pour votre version dans le tableau. Vous pouvez obtenir une liste précise des versions disponibles dans votre Région AWS version actuelle en utilisant le AWS CLI. Pour en savoir plus, consultez Obtenir une liste des versions disponibles dans votre Région AWS.

Vérifiez que vos applications fonctionnent comme prévu lors d'un déploiement d'essai de la nouvelle version. Pour plus d'informations sur le processus complet, consultez Test d'une mise à niveau de votre cluster de base de données de production vers une nouvelle version majeure.

Après avoir vérifié que vos applications fonctionnent comme prévu lors du déploiement d'essai, vous pouvez mettre à niveau votre cluster. Pour en savoir plus, consultez Mise à niveau du moteur Aurora PostgreSQL vers une nouvelle version majeure.

Préparez un groupe de paramètres compatible avec la version.

Si vous utilisez une instance de base de données personnalisée ou un groupe de paramètres de cluster de base de données, vous pouvez choisir parmi deux options :

Si vous associez une nouvelle instance de base de données ou un nouveau groupe de paramètres de cluster de base de données dans le cadre de la demande de mise à niveau, veillez à redémarrer la base de données une fois la mise à niveau terminée afin d'appliquer les paramètres. Si une instance de base de données doit être redémarrée pour appliquer les modifications du groupe de paramètres, l'état du groupe de paramètres de l'instance indique pending-reboot. Vous pouvez afficher l'état du groupe de paramètres d'une instance dans la console ou en utilisant une commande de l'interface de ligne de commande comme describe-db-instances ou describe-db-clusters.

Vérifiez les bases de données non valides et supprimez celles qui existent.

La datconnlimit colonne du pg_database catalogue inclut une valeur de -2 pour marquer comme non valide toute base de données interrompue au cours d'une DROP DATABASE opération. Utilisez la requête suivante pour vérifier s'il existe des bases de données non valides.

SELECT
    datname
FROM
    pg_database
WHERE
    datconnlimit = - 2;

Si la requête renvoie des noms de base de données, ces bases de données ne sont pas valides. Utilisez l'DROP DATABASE invalid_db_nameinstruction pour supprimer les bases de données non valides. Vous pouvez utiliser l'instruction dynamique suivante pour supprimer toutes les bases de données non valides.

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

Recherchez une utilisation non prise en charge :

Vérifiez les bases de données template1 et template0.

Pour une mise à niveau réussie, les bases de données des modèles 1 et 0 doivent exister et doivent être répertoriées en tant que modèles. Pour vérifier cela, utilisez la commande suivante :

SELECT datname, datistemplate FROM pg_database; 
                        
datname    | datistemplate
-----------+---------------
template0  | t
rdsadmin   | f
template1  | t
postgres   | f

Dans la sortie de la commande, la valeur datistemplate des bases de données template1 et template0 doit être t.

Supprimez des emplacements logiques de réplication.

Le processus de mise à niveau ne peut pas avoir lieu si le cluster de base de données Aurora PostgreSQL utilise des emplacements de réplication logiques. Les emplacements de réplication logique sont généralement utilisés pour des tâches de migration de données à court terme, telles que la migration de données à l'aide AWS DMS ou pour la réplication de tables de la base de données vers des lacs de données, des outils de BI ou d'autres cibles. Avant de procéder à la mise à niveau, assurez-vous de connaître l'utilité de tout emplacement de réplication logique existant et confirmez que vous pouvez les supprimer. Vous pouvez vérifier les emplacements de réplication logiques à l'aide de la requête suivante :

SELECT * FROM pg_replication_slots;

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. Toutefois, si les emplacements de réplication logique ne sont pas nécessaires, vous pouvez les supprimer à l'aide du code SQL suivant :

SELECT pg_drop_replication_slot(slot_name);

Les scénarios de réplication logique qui utilisent l'extension pglogical doivent également avoir des emplacements supprimés du nœud de serveur de publication pour que la mise à niveau de version majeure réussisse sur ce nœud. Toutefois, vous pouvez redémarrer le processus de réplication à partir du nœud d'abonné après la mise à niveau. Pour de plus amples informations, veuillez consulter Rétablissement de la réplication logique après une mise à niveau majeure.

Effectuez une sauvegarde.

Le processus de mise à niveau crée un instantané de cluster de base de données de votre cluster de base de données lors de la mise à niveau. Si vous souhaitez également effectuer une sauvegarde manuelle avant le processus de mise à niveau, veuillez consulter Création d'un instantané de cluster de base de données pour de plus amples informations.

Mettez à niveau certaines extensions vers la dernière version disponible avant d'effectuer la mise à niveau de la version majeure. Les extensions à mettre à jour sont les suivantes :

Exécutez la commande suivante pour chaque extension actuellement installée.

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

Pour de plus amples informations, veuillez consulter Mise à niveau des extensions PostgreSQL. Pour en savoir plus sur la mise à niveau de PostGIS, consultez Étape 6 : mise à niveau de l'GISextension Post.

Si vous effectuez une mise à niveau vers la version 11.x, supprimez les extensions que celle-ci ne prend pas en charge avant d'effectuer la mise à niveau de la version majeure. Les extensions à supprimer sont :

Supprimez les types de données unknown en fonction de votre version cible.

PostgreSQL version 10 ne prend pas 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 la version 10 affiche un message d'erreur semblable au suivant :

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 de telles colonnes ou les remplacer par un type de données pris en charge, utilisez le code SQL suivant pour chaque base de données.

SELECT n.nspname, c.relname, a.attname
    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 = 'pg_catalog.unknown'::pg_catalog.regtype AND
    c.relkind IN ('r','m','c') AND
    c.relnamespace = n.oid AND
    n.nspname !~ '^pg_temp_' AND
    n.nspname !~ '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', 'information_schema');

Procédez à un essai de mise à niveau.

Nous vous recommandons vivement de tester la mise à niveau de version majeure sur une copie 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 l'instance de test dupliquée pour détecter d'éventuelles régressions du plan d'exécution et évaluer ses performances. Pour créer une copie d'une instance pour les tests, vous pouvez restaurer votre base de données à partir d'un instantané récent ou cloner votre base de données. Pour plus d’informations, consultez Restaurer à partir d'un instantané ou Clonage d'un volume pour un cluster de base de données Amazon Aurora.

Pour plus d'informations, consultez Mise à niveau du moteur Aurora PostgreSQL vers une nouvelle version majeure.

Mettez à niveau votre instance de production.

Lorsque l'essai de mise à niveau de version majeure est un succès, vous pouvez mettre à niveau en toute confiance votre base de données de production. Pour de plus amples informations, veuillez consulter Mise à niveau du moteur Aurora PostgreSQL vers une nouvelle version majeure.

Pour obtenir des informations sur une mise à niveau en cours, vous pouvez utiliser Amazon RDS for afficher deux journaux produits par l'utilitaire pg_upgrade. Il s'agit des journaux pg_upgrade_internal.log et pg_upgrade_server.log. Amazon Aurora ajoute un horodatage au nom de fichier de ces journaux. Vous pouvez consultez ces journaux comme tout autre journal. Pour plus d'informations, consultez Surveillance des fichiers journaux Amazon Aurora.

Mettez à niveau les extensions PostgreSQL. Le processus de mise à niveau de PostgreSQL ne met à niveau aucune extension PostgreSQL. Pour de plus amples informations, veuillez consulter Mise à niveau des extensions PostgreSQL.