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.
Mise à niveau du moteur de base de données PostgreSQL pour Amazon RDS
Il existe deux types de mises à niveau que vous pouvez gérer pour votre base de données PostgreSQL :
-
Mises à jour du système d'exploitation : il peut arriver qu'Amazon RDS doive mettre à jour le système d'exploitation sous-jacent de votre base de données afin d'appliquer des correctifs de sécurité ou des modifications du système d'exploitation. Vous pouvez décider quand Amazon RDS applique les mises à jour du système d'exploitation à l'aide de la console RDS, AWS Command Line Interface (AWS CLI) ou de l'API RDS. Pour plus d'informations sur les mises à jour de SE, consultez Application des mises à jour pour une instance de base de données.
-
Mises à niveau du moteur de base de données : quand Amazon RDS prend en charge une nouvelle version d'un moteur de base de données, vous pouvez mettre à niveau vos bases de données vers cette nouvelle version.
Une base de données dans ce contexte est une instance de base de données RDS for PostgreSQL ou un cluster de bases de données multi-AZ.
Il existe deux types de mises à niveau du moteur pour les bases de données PostgreSQL : les mises à niveau des versions majeures et les mises à niveau des versions mineures.
- Mises à niveau de version majeure.
-
Les mises à niveau de version majeure peuvent contenir des modifications de base de données qui ne sont pas rétrocompatibles avec les applications existantes. Par conséquent, vous devez effectuer manuellement les mises à niveau de version majeure de vos bases de données. Vous pouvez lancer une mise à niveau de version majeure en modifiant votre instance de base de données ou votre cluster de bases de données multi-AZ. Avant d'effectuer une mise à niveau de version majeure, nous vous recommandons de suivre les étapes décrites dans Choix d'une mise à niveau de version majeure pour PostgreSQL.
Si vous mettez à niveau une instance de base de données qui possède des réplicas en lecture dans la région, Amazon RDS met à niveau les réplicas 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. Si vous effectuez une mise à niveau de version majeure d'un cluster de base de données multi-AZ, l'état de réplication de ses répliques de lecture devient terminé. Vous devez supprimer et recréer manuellement les réplicas en lecture une fois la mise à niveau terminée.
Astuce
Vous pouvez minimiser le temps d'arrêt requis pour une mise à niveau de version majeure en utilisant un déploiement bleu/vert. Pour plus d’informations, consultez Utilisation des déploiements bleu/vert Amazon RDS pour les mises à jour de base de données.
- Mises à niveau de version mineure.
-
En revanche, une mise à niveau de version mineure contient uniquement des modifications rétrocompatibles avec les applications existantes. Vous pouvez lancer manuellement une mise à niveau de version mineure en modifiant votre base de données. Vous pouvez également activer l'option de mise à niveau automatique des versions mineures lors de la création ou de la modification d'une base de données. Cela signifie qu'Amazon RDS met automatiquement à niveau votre base de données après avoir testé et approuvé la nouvelle version. Si votre base de données PostgreSQL utilise des répliques en lecture, vous devez d'abord mettre à niveau toutes les répliques en lecture avant de mettre à niveau l'instance ou le cluster source.
Si votre base de données est un déploiement d'instance de base de données multi-AZ, Amazon RDS met à niveau simultanément l'instance principale et les instances de secours. Il est donc possible que votre base de données ne soit pas disponible tant que la mise à niveau n'est pas terminée. Si votre base de données est un déploiement de cluster de bases de données multi-AZ, Amazon RDS met à niveau les instances de base de données du lecteur une par une. Ensuite, l'une des instances de base de données du lecteur devient la nouvelle instance de base de données du rédacteur. Amazon RDS met ensuite à niveau l'ancienne instance d'écriture (qui est désormais une instance de lecteur).
Note
Le temps d'arrêt lié à une mise à niveau de version mineure d'un déploiement d'instance de base de données multi-AZ peut durer plusieurs minutes. Les clusters de bases de données multi-AZ réduisent généralement le temps d'arrêt des mises à niveau de versions mineures à environ 35 secondes. Lorsqu'il est utilisé avec le proxy RDS, vous pouvez réduire davantage les temps d'arrêt à une seconde ou moins. Pour plus d’informations, consultez Utilisation d'Amazon RDS Proxy . Vous pouvez également utiliser un proxy de base de données open source tel que ProxySQL
ou le pilote PgBouncer AWS JDBC pour MySQL. Pour plus d’informations, consultez Mises à niveau automatiques des versions mineures pour PostgreSQL. Pour de plus amples informations sur l'exécution manuelle d'une mise à niveau de version mineure, veuillez consulter Mise à niveau manuelle de la version du moteur.
Pour plus d'informations sur les versions du moteur de base de données et la politique de dépréciation des versions du moteur de base de données, consultez la section Versions du moteur de base de données dans les
Rubriques
- Présentation de la mise à niveau de PostgreSQL
- Numéros de version PostgreSQL
- Numéro de version de RDS
- Choix d'une mise à niveau de version majeure pour PostgreSQL
- Comment effectuer une mise à niveau de version majeure
- Mises à niveau automatiques des versions mineures pour PostgreSQL
- Mise à niveau des extensions PostgreSQL
Présentation de la mise à niveau de PostgreSQL
Pour mettre à niveau vos bases de données en toute sécurité, Amazon RDS utilise l'utilitaire pg_upgrade décrit dans la documentation PostgreSQL
Lorsque vous utilisez le AWS Management Console pour mettre à niveau une base de données, il indique les cibles de mise à niveau valides pour la base de données. Vous pouvez également utiliser la AWS CLI commande suivante pour identifier les cibles de mise à niveau valides pour une base de données :
Pour LinuxmacOS, ou Unix :
aws rds describe-db-engine-versions \ --engine postgres \ --engine-versionversion-number\ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
Dans Windows :
aws rds describe-db-engine-versions ^ --engine postgres ^ --engine-versionversion-number^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
Par exemple, pour identifier les cibles de mise à niveau valides pour une base de données PostgreSQL version 12.13, exécutez la commande suivante : AWS CLI
Pour LinuxmacOS, ou Unix :
aws rds describe-db-engine-versions \ --engine postgres \ --engine-version 12.13 \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
Dans Windows :
aws rds describe-db-engine-versions ^ --engine postgres ^ --engine-version 12.13 ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
Si votre période de rétention des sauvegardes est supérieure à 0, Amazon RDS crée deux instantanés de base de données pendant la mise à niveau. Le premier instantané de base de données porte sur la base de données avant que toute modification de mise à niveau soit apportée. Si la mise à niveau échoue pour vos bases de données, vous pouvez restaurer cet instantané afin de créer une base de données exécutant l'ancienne version. Le second instantané de base de données est pris à la fin de la mise à niveau.
Note
Amazon RDS ne prend des instantanés de base de données pendant le processus de mise à niveau que si vous avez défini la période de conservation des sauvegardes de votre base de données sur un nombre supérieur à 0. Pour modifier la période de conservation des sauvegardes pour une instance de base de données, consultez Modification d'une instance de base de données Amazon RDS. Vous ne pouvez pas configurer une période de conservation personnalisée des sauvegardes pour un cluster de bases de données multi-AZ.
Quand vous effectuez une mise à niveau de version majeure d'une instance de base de donnée, tous les réplicas en lecture dans la région sont également automatiquement mis à niveau. Une fois que le flux de mise à niveau a 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 que les mises à niveau du réplica en lecture se terminent. Vous faites face à une panne tant que la mise à niveau n'est pas terminée. Quand vous effectuez une mise à niveau de version majeure d'un cluster de bases de données multi-AZ, l'état de réplication de ses réplicas en lecture devient résilié.
Une fois qu'une mise à niveau est terminée, vous ne pouvez pas rétablir la version précédente du moteur de base de données. Si vous souhaitez revenir à la version précédente, restaurez l'instantané de base de données pris avant la mise à niveau pour créer une nouvelle base de données.
Numéros de version PostgreSQL
La séquence de numérotation des versions du moteur de base de données PostgreSQL est la suivante :
-
Pour les versions 10 et ultérieures de PostgreSQL, le format du numéro de version du moteur est majeure.mineure. Le numéro de version majeure est la partie entière du numéro de version. Le numéro de version mineure est la partie fractionnaire du numéro de version.
Une mise à niveau de version majeure augmente la partie entière du numéro de version, par exemple la mise à niveau de 10.mineure à 11.mineure.
-
Pour les versions de PostgreSQL antérieures à 10, le format du numéro de version du moteur est majeure.majeure.mineure. Le numéro de version majeure du moteur est à la fois l'entier et la première partie fractionnaire du numéro de version. Par exemple, 9.6 est une version majeure. Le numéro de version mineure est la troisième partie du numéro de version. Par exemple, pour la version 9.6.12, le numéro 12 est le numéro de version mineure.
Une mise à niveau majeure augmente la partie majeure du numéro de version. Par exemple, une mise à niveau de la version 9.6.12 vers la version 11.14 est une mise à niveau de version majeure, 9.6 et 11 étant les numéros des versions majeures.
Pour plus d'informations sur la numérotation des versions de RDS Extended Support, consultez. Dénomination de la version d'Amazon RDS Extended Support
Numéro de version de RDS
Les numéros de version de RDS utilisent le schéma de dénomination major.minor.patch
Pour identifier le numéro de version Amazon RDS de votre base de données, vous devez d'abord créer l'extension rds_tools à l'aide de la commande suivante :
CREATE EXTENSION rds_tools;
À partir de la version 15.2-R2 de PostgreSQL, vous pouvez déterminer le numéro de version RDS de votre base de données RDS for PostgreSQL avec la requête SQL suivante :
postgres=>SELECT rds_tools.rds_version();
Par exemple, l'interrogation d'une base de données RDS for PostgreSQL 15.2 renvoie ce qui suit :
rds_version ---------------- 15.2.R2 (1 row)
Choix d'une mise à niveau de version majeure pour PostgreSQL
Les mises à niveau de versions majeures peuvent contenir des modifications qui ne sont pas rétrocompatibles avec les versions précédentes de la base de données. Les nouvelles fonctionnalités peuvent empêcher vos applications existantes de fonctionner correctement. Pour cette raison, Amazon RDS n'applique pas automatiquement les mises à niveau des versions majeures. Pour effectuer une mise à niveau de version majeure, vous modifiez manuellement votre base de données. Veillez à tester soigneusement toute mise à niveau pour vérifier que vos applications fonctionnent correctement avant d'appliquer la mise à niveau à vos bases de données de production. Lorsque vous effectuez une mise à niveau de version majeure de PostgreSQL, nous vous recommandons de suivre les étapes décrites dans Comment effectuer une mise à niveau de version majeure.
Lorsque vous mettez à niveau une instance de base de données mono-AZ PostgreSQL ou un déploiement d'instance de base de données multi-AZ vers sa prochaine version majeure, tous les réplicas en lecture associés à la base de données sont également mis à niveau vers cette prochaine version majeure. Dans certains cas, vous pouvez passer à une version majeure ultérieure lors de la mise à niveau. Si votre mise à niveau ignore une version majeure, les réplicas en lecture sont également mis à niveau vers cette version majeure cible. Les mises à niveau vers la version 11 qui sautent d'autres versions majeures présentent certaines limitations. Vous trouverez les détails dans les étapes décrites dans la section Comment effectuer une mise à niveau de version majeure.
La plupart des extensions PostgreSQL ne sont pas mises à jour lors d'une mise à niveau du moteur PostgreSQL. Elles doivent être mises à niveau séparément. Pour plus d’informations, consultez Mise à niveau des extensions PostgreSQL.
Vous pouvez savoir quelles versions majeures sont disponibles pour votre base de données RDS pour PostgreSQL en exécutant la requête suivante : AWS CLI
aws rds describe-db-engine-versions --engine postgres --engine-versionyour-version--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
Le tableau suivant récapitule les résultats de cette requête pour toutes les versions disponibles. Un astérisque (*) sur le numéro de version signifie que la version est obsolète. Si votre version actuelle est obsolète, nous vous recommandons d'effectuer une mise à niveau vers la cible de mise à niveau de la version mineure la plus récente ou vers l'une des autres cibles de mise à niveau disponibles pour cette version. Pour plus d'informations sur l'obsolescence de RDS pour PostgreSQL version 9.6, consultez Obsolescence de PostgreSQL version 9.6. Pour plus d'informations sur l'obsolescence de RDS pour PostgreSQL version 10, consultez Obsolescence de PostgreSQL version 10.
Comment effectuer une mise à niveau de version majeure
Nous vous recommandons le processus suivant lors d'une mise à niveau de version majeure sur une base de données Amazon RDS for PostgreSQL :
-
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 Utilisation des groupes de paramètres et Utilisation des groupes de paramètres de clusters de base de données pour les clusters de base de données Multi-AZ.
-
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 plus d’informations, consultez Moteurs de base de données pris en charge pour les classes d'instance de base de données.
-
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
regtypeetregclass, vous ne pouvez pas mettre à niveau les types de données reg*. L'utilitairepg_upgradene 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');
-
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; SELECT pg_drop_replication_slot(slot_name);Les installations de réplication logique qui utilisent l'extension
pglogicaldoivent é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'extensionpglogical, consultez Gestion des emplacements logiques de réplication pour RDS for PostgreSQL.-
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.
-
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 instance de base de données Amazon RDS et Modification d'un cluster de base de données multi-AZ.
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 et Création d'un instantané de cluster de bases de données multi-AZ.
-
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
Exécutez la commande suivante pour chaque extension que vous utilisez :
ALTER EXTENSIONPostgreSQL-extensionUPDATE TO 'new-version';Pour plus d’informations, consultez Mise à niveau des extensions PostgreSQL. Pour en savoir plus sur la mise à niveau de PostGIS, consultez Étape 6 : Mettre à niveau l'extension PostGIS.
-
-
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'extensionpgRoutingpuis 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 de l'extension PostgreSQL prises en charge.Les extensions
tsearch2etchkpassne 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 extensionstsearch2etchkpassavant la mise à niveau. -
Supprimer les types de données inconnus – Supprimez les types de données
unknownen 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éesunknown, 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
unknowndans 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'; -
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 date spécifiée. 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_gathersur 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_gatherdans le groupe de paramètres de base de donnéesdefault.postgresql10est 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_gathersur 0.Durant la mise à niveau de version majeure, les bases de données
publicettemplate1, ainsi que le schémapublicfigurant 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 quelocaleetownersoient 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.
-
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.logpour 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 Amazon RDS.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. -
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-restoreet 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.
-
-
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 plus d’informations, consultez Mise à niveau manuelle de la version du moteur.
Exécutez l'opération
ANALYZEpour actualiser la tablepg_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
VERBOSEest facultatif, mais son utilisation vous montre la progression. Pour en savoir plus, veuillez consulter ANALYZEdans la documentation PostgreSQL. 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 extensions PostgreSQL.
-
Vous pouvez utiliser Amazon RDS pour consulter deux journaux générés par l'utilitaire
pg_upgrade. Il s'agit des journauxpg_upgrade_internal.logetpg_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 plus d’informations, consultez Surveillance des fichiers journaux Amazon RDS.Vous pouvez également télécharger les journaux de mise à niveau sur Amazon CloudWatch Logs. Pour plus d’informations, consultez 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.
Mises à niveau automatiques des versions mineures pour PostgreSQL
Si vous activez l'option Mise à niveau automatique des versions mineures au moment de créer ou modifier une instance de base de données ou un cluster de bases de données multi-AZ, votre base de données peut être mise à niveau automatiquement.
Pour chaque version majeure de RDS for PostgreSQL, une seule version mineure est désignée par RDS comme étant la version de mise à niveau automatique. Une fois qu'une version mineure a été testée et approuvée par Amazon RDS, la mise à niveau de la version mineure se produit automatiquement pendant votre fenêtre de maintenance. RDS ne définit pas automatiquement les dernières versions mineures publiées comme version de mise à niveau automatique. Avant de désigner une publication de version récente comme version de mise à niveau automatique, RDS prend en compte plusieurs critères, à savoir :
-
Problèmes de sécurité connus
-
Bogues dans la version de la communauté PostgreSQL
-
Stabilité globale du parc depuis la publication de la version mineure
Vous pouvez utiliser la AWS CLI commande suivante pour déterminer la version cible de mise à niveau mineure automatique actuelle pour une version mineure de PostgreSQL spécifiée dans une version spécifique. Région AWS
Pour LinuxmacOS, ou Unix :
aws rds describe-db-engine-versions \ --engine postgres \ --engine-versionminor-version\ --regionregion\ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \ --output text
Dans Windows :
aws rds describe-db-engine-versions ^ --engine postgres ^ --engine-versionminor-version^ --regionregion^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^ --output text
Par exemple, la AWS CLI commande suivante détermine la cible de mise à niveau mineure automatique pour la version mineure 12.13 de PostgreSQL dans l'est des États-Unis (Ohio Région AWS ) (us-east-2).
Pour LinuxmacOS, ou Unix :
aws rds describe-db-engine-versions \ --engine postgres \ --engine-version 12.13 \ --region us-east-2 \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \ --output table
Dans Windows :
aws rds describe-db-engine-versions ^ --engine postgres ^ --engine-version 12.13 ^ --region us-east-2 ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^ --output table
Votre sortie est similaire à ce qui suit.
---------------------------------- | DescribeDBEngineVersions | +--------------+-----------------+ | AutoUpgrade | EngineVersion | +--------------+-----------------+ | True | 12.14 | | False | 12.15 | | False | 13.9 | | False | 13.10 | | False | 13.11 | | False | 14.6 | +--------------+-----------------+
Dans cet exemple, la valeur de AutoUpgrade est True pour PostgreSQL version 12.14. Ainsi, la cible de mise à niveau mineure automatique est la version 12.14 de PostgreSQL, comme indiqué dans la sortie.
Une base de données PostgreSQL est automatiquement mise à niveau au cours de votre fenêtre de maintenance si les critères suivants sont réunis :
-
L'option Mise à niveau automatique des versions mineures est activée pour la base de données.
-
La base de données exécute une version mineure du moteur de base de données qui est inférieure à la version mineure de la mise à niveau automatique actuelle.
Pour plus d’informations, consultez Mise à niveau automatique de la version mineure du moteur.
Note
Une mise à niveau de PostgreSQL ne met pas à niveau les extensions PostgreSQL. Pour mettre à niveau les extensions, veuillez consulter Mise à niveau des extensions PostgreSQL.
Mise à niveau des extensions PostgreSQL
Une mise à niveau du moteur PostgreSQL ne met pas à niveau la plupart des extensions PostgreSQL. Pour mettre à jour une extension après une mise à niveau de version, utilisez la commande ALTER EXTENSION UPDATE.
Note
Pour plus d'informations sur la mise à jour de l'extension PostGIS, consultez Gestion des données spatiales avec l'extension PostGIS (Étape 6 : Mettre à niveau l'extension PostGIS).
Pour mettre à jour l'extension pg_repack, supprimez l'extension, puis créez la nouvelle version dans la base de données mise à niveau. Pour plus d'informations, veuillez consulter pg_repack installationpg_repack.
Pour mettre à niveau une extension, utilisez la commande suivante.
ALTER EXTENSIONextension_nameUPDATE TO 'new_version';
Pour voir la liste des versions prises en charge des extensions PostgreSQL, consultez Versions de l'extension PostgreSQL prises en charge.
Pour afficher une liste des extensions actuellement installées, utilisez le catalogue pg_extension
SELECT * FROM pg_extension;
Pour afficher une liste des versions d'extensions spécifiques disponibles pour votre installation, utilisez la vue pg_available_extension_versions
SELECT * FROM pg_available_extension_versions;
