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 des clusters de base de données Amazon Aurora PostgreSQL
Amazon Aurora met à disposition de nouvelles versions du moteur de base de données PostgreSQL dans les Régions AWS seulement après des tests approfondis. Vous pouvez mettre à niveau vos clusters de bases de données Aurora PostgreSQL vers la nouvelle version lorsqu’elle est disponible dans votre région.
Selon la version d’Aurora PostgreSQL actuellement exécutée par votre cluster de bases de données, une mise à niveau vers la nouvelle version est soit une mise à niveau mineure, soit une mise à niveau majeure. Par exemple, la mise à niveau d’un cluster de bases de données Aurora PostgreSQL 11.15 vers Aurora PostgreSQL 13.6 est une *mise à niveau de version majeure*. La mise à niveau d’un cluster de bases de données Aurora PostgreSQL 13.3 vers Aurora PostgreSQL 13.7 est une *mise à niveau de version mineure*. Dans les rubriques suivantes, vous apprendrez comment effectuer les deux types de mises à niveau.
**Contents**
+ [Présentation des processus de mise à niveau Aurora PostgreSQL](#USER_UpgradeDBInstance.PostgreSQL.Overview)
+ [Obtenir une liste des versions disponibles dans votre Région AWS](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md)
+ [Réalisation d’une mise à niveau de version majeure](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)
+ [Test d’une mise à niveau de votre cluster de bases de données de production vers une nouvelle version majeure](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary)
+ [Recommandations après la mise à niveau](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.postupgrade)
+ [Mise à niveau du moteur Aurora PostgreSQL vers une nouvelle version majeure](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.Upgrading.Manual)
+ [Mises à niveau majeures des bases de données globales](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.GlobalDB)
+ [Réalisation d’une mise à niveau de version mineure](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md)
+ [Avant d’effectuer une mise à niveau de version mineure](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
+ [Comment effectuer des mises à niveau de versions mineures et appliquer des correctifs](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor)
+ [Mises à niveau de versions mineures et application de correctifs sans durée d’indisponibilité](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp)
+ [Limites des correctifs sans durée d’indisponibilité](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp.limitations)
+ [Mise à niveau du moteur Aurora PostgreSQL vers une nouvelle version mineure](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.MinorUpgrade)
+ [Mise à niveau des extensions PostgreSQL](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md)
+ [Technique de blue/green mise à niveau alternative](#USER_UpgradeDBInstance.Upgrading.BlueGreen)
## Présentation des processus de mise à niveau Aurora PostgreSQL
Les différences entre les mises à niveau des versions majeures et mineures sont les suivantes :
**Mises à niveau des versions mineures et correctifs**
Les mises à niveau de versions mineures et les correctifs contiennent uniquement des modifications rétrocompatibles avec les applications existantes. Les mises à niveau des versions mineures et les correctifs ne sont disponibles qu’une fois qu’Aurora PostgreSQL les a testés et approuvés.
Aurora peut automatiquement appliquer à votre place les mises à niveau mineures. Lorsque vous créez un cluster de bases de données Aurora PostgreSQL, l’option **Activer la mise à niveau des versions mineures** est activée par défaut. À moins de désactiver manuellement cette option, Aurora applique régulièrement des mises à niveau automatiques des versions mineures durant votre fenêtre de maintenance planifiée. Pour plus d’informations sur l’option de mise à niveau automatique des versions mineures (AmVU) et sur la façon de modifier votre cluster de bases de données Aurora pour l’utiliser, consultez [Mises à niveau automatiques des versions mineures pour les clusters de bases de données Aurora](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU).
Si l’option de mise à niveau automatique des versions mineures n’est pas définie pour votre cluster de bases de données Aurora PostgreSQL, ce dernier n’est pas mis à niveau automatiquement vers la nouvelle version mineure. Au lieu de cela, lorsqu’une nouvelle version mineure est publiée dans votre Région AWS et que votre cluster de bases de données Aurora PostgreSQL exécute une version mineure plus ancienne, Aurora vous invite à le mettre à niveau. Pour ce faire, il ajoute une recommandation aux tâches de maintenance de votre cluster.
Les correctifs ne sont pas considérés comme une mise à niveau et ils ne sont pas appliqués automatiquement. Aurora PostgreSQL vous invite à appliquer les éventuels correctifs en ajoutant une recommandation aux tâches de maintenance de votre cluster de bases de données Aurora PostgreSQL. Pour plus d’informations, consultez [Comment effectuer des mises à niveau de versions mineures et appliquer des correctifs](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor).
Les correctifs qui résolvent les problèmes de sécurité ou d’autres problèmes critiques sont également ajoutés en tant que tâches de maintenance. Ces correctifs sont toutefois obligatoires. Assurez-vous d’appliquer les correctifs de sécurité à votre cluster de bases de données Aurora PostgreSQL lorsqu’ils sont mis à disposition dans vos tâches de maintenance en attente.
Des mises à niveau automatiques de version mineure sont effectuées vers la version mineure par défaut.
Il est possible que de courtes pannes se produisent pendant le processus de mise à niveau car chaque instance du cluster est mise à niveau vers la nouvelle version. Cependant, après Aurora PostgreSQL 14.3.3, 13.7.3, 12.11.3, 11.16.3, 10.21.3, et d’autres versions ultérieures de ces versions mineures et les nouvelles versions majeures, le processus de mise à niveau utilise la fonction ZDP (application de correctifs sans durée d’indisponibilité). Cette fonctionnalité réduit les pannes et les élimine complètement dans la plupart des cas. Pour plus d’informations, consultez [Mises à niveau de versions mineures et application de correctifs sans durée d’indisponibilité](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp). Pour plus d’informations sur les fonctionnalités prises en charge et les limites de ZDP, consultez [Limites des correctifs sans durée d’indisponibilité](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp.limitations).
**Mises à niveau de version majeure.**
Contrairement aux mises à niveau et aux correctifs des versions mineures, Aurora PostgreSQL ne dispose pas d’une option de mise à niveau automatique des versions majeures. Les nouvelles versions majeures de PostgreSQL peuvent contenir des modifications de base de données qui ne sont pas rétrocompatibles avec les applications existantes. Les nouvelles fonctionnalités peuvent empêcher vos applications existantes de fonctionner correctement.
Pour éviter tout problème, nous vous recommandons vivement de suivre le processus décrit dans [Test d’une mise à niveau de votre cluster de bases de données de production vers une nouvelle version majeure](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary) avant de mettre à niveau les instances de base de données de vos clusters de base de données Aurora PostgreSQL. Assurez-vous tout d’abord que vos applications peuvent s’exécuter sur la nouvelle version en procédant comme suit. Vous pouvez ensuite mettre à niveau manuellement votre cluster de bases de données Aurora PostgreSQL vers la nouvelle version.
Il est possible que de courtes pannes se produisent pendant la mise à niveau vers la nouvelle version de toutes les instances du cluster. Le processus de planification préliminaire prend également un certain temps. Nous vous recommandons de toujours effectuer les tâches de mise à niveau pendant la fenêtre de maintenance de votre cluster ou lorsque la charge d’opérations est minimale. Pour plus d’informations, consultez [Réalisation d’une mise à niveau de version majeure](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).
**Note**
Les mises à niveau de versions mineures et de versions majeures peuvent impliquer de courtes pannes. Nous vous recommandons ainsi vivement d’effectuer ou de planifier vos mises à niveau pendant votre fenêtre de maintenance ou pendant les périodes de faible utilisation.
Les clusters de bases de données Aurora PostgreSQL nécessitent parfois des mises à jour du système d’exploitation. Ces mises à jour peuvent inclure une version plus récente de la bibliothèque glibc. Lors de ces mises à jour, nous vous recommandons de suivre les directives décrites dans [Collations prises en charge dans Aurora PostgreSQL RDS pour ](PostgreSQL-Collations.md).
# Obtenir une liste des versions disponibles dans votre Région AWS
Vous pouvez obtenir une liste de toutes les versions de moteur disponibles en tant que cibles de mise à niveau pour votre cluster de base de données Aurora PostgreSQL en Région AWS vous interrogeant à l'aide de [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI la commande suivante.
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine aurora-postgresql \
--engine-version version-number \
--query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \
--output text
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine aurora-postgresql ^
--engine-version version-number ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
--output text
```
Par exemple, pour identifier les cibles de mise à niveau valides pour un cluster de base de données Aurora PostgreSQL version 12.10, exécutez la commande suivante : AWS CLI
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine aurora-postgresql \
--engine-version 12.10 \
--query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \
--output text
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine aurora-postgresql ^
--engine-version 12.10 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
--output text
```
Ce tableau indique les cibles de mise à niveau des versions majeures et mineures vers différentes versions de base de données Aurora PostgreSQL. Pour garantir la compatibilité, toutes les versions ne sont pas proposées comme cibles de mise à niveau. Aurora PostgreSQL introduit de nouvelles fonctionnalités et des corrections de bogues à chaque publication trimestrielle de version mineure. Pour plus d’informations sur les versions mineures d’Aurora PostgreSQL, consultez [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html).
| Version source actuelle | Cibles de mise à niveau |
| --- | --- |
| 17,7 | Aucune |
| 17,6 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) |
| 17,5 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x)[, 17,6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x) |
| 17,4 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x)[, [17,6, 17,5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x) |
| 16,11 | Aucune |
| 16,10 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) |
| 16,9 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x)[, [17,6, 16,10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17,5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x) |
| 16,8 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) |
| 16,6 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x) |
| 16,4 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x) |
| 16,3 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x) |
| 16,2 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x) |
| 16,1 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x) |
| 15,15 | Aucune |
| 15,14 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [15,15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x) |
| 15,13 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x) |
| 15,12 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x) |
| 15,10 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x) |
| 15,11 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x) |
| 14,20 | Aucune |
Pour toute version que vous envisagez d’utiliser, vérifiez toujours la disponibilité de la classe d’instance de base de données de votre cluster. Par exemple, `db.r4` n’est pas pris en charge pour Aurora PostgreSQL 13. Si votre cluster de base de données Aurora PostgreSQL utilise actuellement une classe d'instance db.r4, vous devez la modifier pour utiliser une classe d'instance de base de données prise en charge avant de pouvoir passer à Aurora PostgreSQL 13. Pour plus d'informations sur les classes d'instance de base de données Aurora PostgreSQL disponibles, notamment celles basées sur Graviton2 et celles basées sur Intel, consultez. [Classes d'instances de base de données Amazon Aurora](Concepts.DBInstanceClass.md)
# Réalisation d’une mise à niveau de version majeure
Les mises à niveau de version majeure risquent de contenir des modifications de base de données qui ne sont pas rétrocompatibles avec les versions antérieures de la base de données. Les nouvelles fonctionnalités d’une nouvelle version peuvent empêcher vos applications existantes de fonctionner correctement. Pour éviter les problèmes, Amazon Aurora n’applique pas les mises à niveau de versions majeures automatiquement. Nous vous recommandons plutôt de planifier soigneusement une mise à niveau de version majeure en procédant comme suit :
1. 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](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md).
1. 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 bases de données de production vers une nouvelle version majeure](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary).
1. 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](#USER_UpgradeDBInstance.Upgrading.Manual).
**Note**
Vous pouvez effectuer une mise à niveau de la version majeure de Babelfish pour Aurora PostgreSQL des versions 13 (à partir de 13.6) aux versions basées sur Aurora PostgreSQL 14 (à partir de 14.6). Babelfish pour Aurora PostgreSQL versions 13.4 et 13.5 ne prend pas en charge les mises à niveau de versions majeures.
Vous pouvez obtenir une liste des versions de moteur disponibles en tant que cibles de mise à niveau des versions majeures pour votre cluster de bases de données Aurora PostgreSQL en Région AWS vous interrogeant à l'aide de [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI la commande suivante.
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine aurora-postgresql \
--engine-version version-number \
--query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}' \
--output text
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine aurora-postgresql ^
--engine-version version-number ^
--query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}" ^
--output text
```
Dans certains cas, la version vers laquelle vous souhaitez effectuer une mise à niveau n’est pas une cible pour votre version actuelle. Dans ce cas, utilisez les informations du [versions table](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md#versions-table) pour effectuer des mises à niveau de versions mineures jusqu’à ce que votre cluster atteigne une version dont la cible choisie figure sur sa ligne de cibles.
## Test d’une mise à niveau de votre cluster de bases de données de production vers une nouvelle version majeure
Chaque nouvelle version majeure comprend des améliorations de l’optimiseur de requêtes destinées à améliorer les performances. Cependant, votre charge de travail peut inclure des requêtes qui donnent lieu à un plan moins performant dans la nouvelle version. C’est pourquoi nous vous recommandons de tester et d’examiner les performances avant de procéder à la mise à niveau en production. Vous pouvez gérer la stabilité du plan de requête entre les versions en utilisant l’extension Query Plan Management (QPM), comme indiqué dans [Assurer la stabilité du plan après une mise à niveau majeure de la version](AuroraPostgreSQL.Optimize.BestPractice.md#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade).
Avant de mettre à niveau vos clusters de base de données Aurora PostgreSQL de production vers une nouvelle version majeure, nous vous recommandons vivement de tester la mise à niveau pour vérifier que toutes vos applications fonctionnent correctement :
1. 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 bases de données, vous pouvez choisir parmi deux options :
1. Spécifiez l’instance de base de données par défaut, le groupe de paramètres de cluster de bases de données ou ces deux éléments pour la nouvelle version du moteur de base de données.
1. Créez votre propre groupe de paramètres personnalisé pour la nouvelle version du moteur de base de données.
1. Vérifiez les bases de données non valides et supprimez celles qui existent.
La colonne `datconnlimit` du catalogue `pg_database` inclut une valeur de `-2` pour marquer comme non valides les bases de données qui ont été interrompues au cours d’une opération `DROP DATABASE`. Utilisez la requête suivante pour vérifier la présence de 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’instruction `DROP DATABASE invalid_db_name` 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
```
1. Recherchez une utilisation non prise en charge :
+ 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 instance.
```
SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
```
+ Supprimez toutes les utilisations des types de données *reg\$1* avant d’essayer d’effectuer une mise à niveau. À l’exception de `regtype` et `regclass`, vous ne pouvez pas mettre à niveau les types de données *reg\$1*. L’utilitaire pg\$1upgrade (utilisé par Amazon Aurora pour effectuer la mise à niveau) ne peut pas conserver ce type de données. Pour en savoir plus sur cet utilitaire, consultez [pg\$1upgrade](https://www.postgresql.org/docs/current/pgupgrade.html) dans la documentation PostgreSQL.
Pour vérifier l’absence de toute utilisation des types de données *reg\$1* 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');
```
+ Si vous mettez à niveau un cluster de bases de données Aurora PostgreSQL version 10.18 ou supérieure sur lequel l’extension `pgRouting` est installée, retirez l’extension avant de mettre à niveau vers la version 12.4 ou supérieure.
Si vous mettez à niveau une version d’Aurora PostgreSQL 10.x sur laquelle l’extension `pg_repack` version 1.4.3 est installée, supprimez l’extension avant d’effectuer la mise à niveau vers une version ultérieure.
1. 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`.
1. Supprimez des emplacements logiques de réplication.
Le processus de mise à niveau ne peut pas avoir lieu si le cluster de bases 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 plus d’informations, consultez [Rétablissement de la réplication logique après une mise à niveau majeure](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md).
1. Effectuez une sauvegarde.
Le processus de mise à niveau crée un instantané de cluster de bases de données de votre cluster de bases de données lors de la mise à niveau. Si vous souhaitez également effectuer une sauvegarde manuelle avant le processus de mise à niveau, consultez [Création d’un instantané de cluster de bases de données](USER_CreateSnapshotCluster.md) pour de plus amples informations.
1. 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 :
+ `pgRouting`
+ `postgis_raster`
+ `postgis_tiger_geocoder`
+ `postgis_topology`
+ `address_standardizer`
+ `address_standardizer_data_us`
Exécutez la commande suivante pour chaque extension actuellement installée.
```
ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';
```
Pour plus d’informations, consultez [Mise à niveau des extensions PostgreSQL](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md). Pour en savoir plus sur la mise à niveau de PostGIS, consultez [Étape 6 : Mettre à niveau l’extension PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update).
1. 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 :
+ `chkpass`
+ `tsearch2`
1. 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');
```
1. 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é](aurora-restore-snapshot.md#aurora-restore-snapshot.Restoring) ou [Clonage d’un volume pour un cluster de bases de données Amazon Aurora](Aurora.Managing.Clone.md).
Pour plus d’informations, consultez [Mise à niveau du moteur Aurora PostgreSQL vers une nouvelle version majeure](#USER_UpgradeDBInstance.Upgrading.Manual).
1. 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 plus d’informations, consultez [Mise à niveau du moteur Aurora PostgreSQL vers une nouvelle version majeure](#USER_UpgradeDBInstance.Upgrading.Manual).
**Note**
Lors d’un processus de mise à niveau, Aurora PostgreSQL prend un instantané du cluster de bases de données. Vous ne pouvez pas point-in-time restaurer votre cluster au cours de ce processus. Plus tard, vous pourrez effectuer une point-in-time restauration avant le début de la mise à niveau et après la fin de la capture automatique de votre instance. Cependant, vous ne pouvez pas point-in-time restaurer une version mineure précédente.
Pour obtenir des informations sur une mise à niveau en cours, vous pouvez utiliser Amazon RDS for afficher deux journaux produits par l’utilitaire pg\$1upgrade. 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](USER_LogAccess.md).
1. Mettez à niveau les extensions PostgreSQL. Le processus de mise à niveau de PostgreSQL ne met à niveau aucune extension PostgreSQL. Pour plus d’informations, consultez [Mise à niveau des extensions PostgreSQL](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md).
## Recommandations après la mise à niveau
Après avoir effectué une mise à niveau majeure de la version, nous vous recommandons de procéder comme suit :
+ Exécutez l'opération `ANALYZE` pour actualiser la table `pg_statistic`. Vous devez le faire pour chaque base de données de toutes vos instances de base 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 `VERBOSE` est facultatif, mais son utilisation vous montre la progression. Pour en savoir plus, consultez [ANALYZE](https://www.postgresql.org/docs/10/sql-analyze.html) dans la documentation PostgreSQL.
Lorsque vous analysez des tables spécifiques au lieu d’utiliser ANALYZE VERBOSE, exécutez la commande ANALYZE pour chaque table comme suit :
```
ANALYZE table_name;
```
Pour les tables partitionnées, analysez toujours la table parent. Ce processus :
+ Échantillonne automatiquement les lignes de toutes les partitions
+ Met à jour les statistiques de chaque partition de manière récursive
+ Maintient les statistiques de planification essentielles au niveau des parents
Bien que les tables parents ne stockent aucune donnée réelle, leur analyse est essentielle pour l’optimisation des requêtes. L’exécution d’ANALYZE uniquement sur des partitions individuelles peut nuire aux performances des requêtes, car l’optimiseur ne dispose pas des statistiques complètes nécessaires à une planification efficace entre partitions.
**Note**
Exécutez ANALYZE sur votre système après la mise à niveau pour éviter les problèmes de performances.
+ Si vous avez effectué une mise à niveau vers PostgreSQL version 10, exécutez `REINDEX` sur tous les index de hachage dont vous disposez. Les index de hachage ont été modifiés dans la version 10 et doivent être reconstruits. Pour localiser des index de hachage non valides, exécutez le code SQL suivant pour chaque base de données contenant des index de hachage.
```
SELECT idx.indrelid::regclass AS table_name,
idx.indexrelid::regclass AS index_name
FROM pg_catalog.pg_index idx
JOIN pg_catalog.pg_class cls ON cls.oid = idx.indexrelid
JOIN pg_catalog.pg_am am ON am.oid = cls.relam
WHERE am.amname = 'hash'
AND NOT idx.indisvalid;
```
+ Nous vous recommandons de tester votre application sur la base de données mise à niveau avec une charge de travail similaire afin de vérifier que tout fonctionne comme prévu. Une fois la mise à niveau vérifiée, vous pouvez supprimer l’instance de test.
## Mise à niveau du moteur Aurora PostgreSQL vers une nouvelle version majeure
Lorsque vous lancez le processus de mise à niveau vers une nouvelle version majeure, Aurora PostgreSQL prend un instantané du cluster de bases de données Aurora avant d’apporter des modifications à votre cluster. Cet instantané est créé uniquement pour les mises à niveau de versions majeures, pas pour les mises à niveau de versions mineures. Lorsque le processus de mise à niveau est terminé, cet instantané figure parmi les instantanés manuels répertoriés sous **Snapshots** (Instantanés) dans la console RDS. Le nom de l’instantané inclut le préfixe `preupgrade`, le nom de votre cluster de bases de données Aurora PostgreSQL, la version source, la version cible, ainsi que la date et l’horodatage, comme illustré dans l’exemple suivant.
```
preupgrade-docs-lab-apg-global-db-12-8-to-13-6-2022-05-19-00-19
```
Une fois la mise à niveau terminée, vous pouvez utiliser l’instantané créé et stocké par Aurora dans votre liste d’instantanés manuels pour restaurer le cluster de bases de données vers sa version précédente, si nécessaire.
**Astuce**
En général, les instantanés offrent de nombreuses façons de restaurer votre cluster de bases de données Aurora à différents moments. Pour en savoir plus, consultez [Restauration à partir d’un instantané de cluster de bases de données](aurora-restore-snapshot.md) et [Restauration d’un cluster de bases de données à une date définie](aurora-pitr.md). Toutefois, Aurora PostgreSQL ne prend pas en charge l’utilisation d’un instantané pour restaurer une version mineure antérieure.
Au cours du processus de mise à niveau de version majeure, Aurora alloue un volume et clone le cluster de bases de données Aurora PostgreSQL source. Si la mise à niveau échoue pour une raison quelconque, Aurora PostgreSQL utilise le clone pour annuler la mise à niveau. Lorsque plus de 15 clones d’un volume source sont alloués, les clones suivants deviennent des copies complètes et prennent plus de temps. Cela peut également allonger le temps nécessaire au processus de mise à niveau. Si Aurora PostgreSQL annule la mise à niveau, sachez que :
+ Il se pourrait que des entrées de facturation et des métriques apparaissent pour le volume d’origine et le volume cloné alloué lors de la mise à niveau. Aurora PostgreSQL nettoie le volume supplémentaire une fois que la fenêtre de rétention de la sauvegarde du cluster dépasse l’échéance de la mise à niveau.
+ La copie de l’instantané entre régions suivante à partir de ce cluster sera une copie complète au lieu d’une copie incrémentielle.
Pour mettre à niveau en toute sécurité les instances de base de données qui composent votre cluster, Aurora PostgreSQL utilise l’utilitaire pg\$1upgrade. Une fois la mise à niveau de l’enregistreur terminée, chaque instance de lecteur subit une brève panne pendant sa mise à niveau vers la nouvelle version majeure. Pour en savoir plus sur cet utilitaire PostgreSQL, consultez [pg\$1upgrade](https://www.postgresql.org/docs/current/pgupgrade.html) dans la documentation PostgreSQL.
Vous pouvez mettre à niveau votre cluster de base de données Aurora PostgreSQL vers une nouvelle version à l'aide AWS Management Console de l'API, de ou de AWS CLI l'API RDS.
### Console
**Pour mettre à niveau la version de moteur d’un cluster de bases de données**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Bases de données**, puis le cluster de bases de données que vous souhaitez mettre à niveau.
1. Sélectionnez **Modify**. La page **Modify DB cluster (Modifier le cluster DB)** s’affiche.
1. Dans le champ **Version du moteur**, sélectionnez la nouvelle version.
1. Choisissez **Continuer** et vérifiez le récapitulatif des modifications.
1. Pour appliquer les modifications immédiatement, choisissez **Appliquer immédiatement**. La sélection de cette option peut entraîner une interruption de service dans certains cas. Pour plus d’informations, consultez [Modification d’un cluster de bases de données Amazon Aurora](Aurora.Modifying.md).
1. Sur la page de confirmation, examinez vos modifications. Si elles sont correctes, choisissez **Modifier le cluster** pour enregistrer vos modifications.
Ou choisissez **Retour** pour revoir vos modifications, ou choisissez **Annuler** pour les annuler.
### AWS CLI
Pour mettre à niveau la version du moteur d'un cluster de base de données, utilisez la [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI commande. Spécifiez les paramètres suivants :
+ `--db-cluster-identifier` : nom du cluster de bases de données.
+ `--engine-version` : numéro de version du moteur de base de données vers lequel effectuer la mise à niveau. Pour plus d'informations sur les versions valides du moteur, utilisez la AWS CLI [ describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)commande.
+ `--allow-major-version-upgrade` : indicateur obligatoire lorsque le paramètre `--engine-version` est une version majeure différente de la version majeure actuelle du cluster de bases de données.
+ `--no-apply-immediately` : appliquer les modifications pendant le créneau de maintenance suivant. Pour appliquer les modifications immédiatement, utilisez `--apply-immediately`.
**Example**
Pour Linux, macOS ou Unix :
```
1. aws rds modify-db-cluster \
2. --db-cluster-identifier mydbcluster \
3. --engine-version new_version \
4. --allow-major-version-upgrade \
5. --no-apply-immediately
```
Pour Windows :
```
1. aws rds modify-db-cluster ^
2. --db-cluster-identifier mydbcluster ^
3. --engine-version new_version ^
4. --allow-major-version-upgrade ^
5. --no-apply-immediately
```
### API RDS
Pour mettre à niveau la version du moteur d'un cluster de base de données, utilisez l'DBClusteropération [Modifier](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Spécifiez les paramètres suivants :
+ `DBClusterIdentifier` : nom du cluster de bases de données, par exemple *`mydbcluster`*.
+ `EngineVersion` : numéro de version du moteur de base de données vers lequel effectuer la mise à niveau. Pour plus d'informations sur les versions valides du moteur, utilisez l'opération [DBEngineDescribe les versions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html).
+ `AllowMajorVersionUpgrade` : indicateur obligatoire lorsque le paramètre `EngineVersion` est une version majeure différente de la version majeure actuelle du cluster de bases de données.
+ `ApplyImmediately` : si des modifications doivent être appliquées immédiatement ou au cours du prochain créneau de maintenance. Pour appliquer les modifications immédiatement, définissez la valeur sur `true`. Pour appliquer les modifications pendant le créneau de maintenance suivant, définissez la valeur sur `false`.
### Mises à niveau majeures des bases de données globales
Pour un cluster de bases de données global Aurora, le processus de mise à niveau met à niveau tous les clusters de bases de données qui composent votre base de données globale Aurora en même temps. Cela garantit que chaque cluster exécute la même version d’Aurora PostgreSQL. Cela garantit également que toutes les modifications apportées aux tables système, aux formats de fichiers de données et autres éléments sont automatiquement répliquées sur tous les clusters secondaires.
Pour mettre à niveau un cluster de bases de données global vers une nouvelle version majeure d’Aurora PostgreSQL, nous vous recommandons de tester vos applications sur la version mise à niveau, comme décrit dans [Test d’une mise à niveau de votre cluster de bases de données de production vers une nouvelle version majeure](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary). Assurez-vous de préparer les paramètres de votre groupe de paramètres de cluster de base de données et de groupe de paramètres de base de données pour chacun d'entre eux Région AWS dans votre base de données globale Aurora avant la mise à niveau, comme [step 1.](#step-1) indiqué [Test d’une mise à niveau de votre cluster de bases de données de production vers une nouvelle version majeure](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary) dans le
Si votre cluster de bases de données global Aurora PostgreSQL a un objectif de point de reprise (RPO) défini pour son paramètre `rds.global_db_rpo`, assurez-vous de réinitialiser le paramètre avant de procéder à la mise à niveau. Le processus de mise à niveau de version majeure ne fonctionne pas si le RPO est activé. Ce paramètre est désactivé par défaut. Pour plus d’informations sur les bases de données globales Aurora PostgreSQL et le RPO, consultez [Gestion des RPO pour les bases de données globales basées sur Aurora PostgreSQL–](aurora-global-database-disaster-recovery.md#aurora-global-database-manage-recovery).
Si vous vérifiez que vos applications peuvent s’exécuter comme prévu lors du déploiement d’essai de la nouvelle version, vous pouvez démarrer le processus de mise à niveau. Pour ce faire, consultez [Mise à niveau du moteur Aurora PostgreSQL vers une nouvelle version majeure](#USER_UpgradeDBInstance.Upgrading.Manual). Assurez-vous de choisir l’élément de niveau supérieur dans la liste **Bases de données** de la console RDS, à savoir **Base de données globale**, comme illustré dans l’image suivante.
![\[Image de la console montrant une base de données globale Aurora, un cluster de bases de données Aurora Serverless et un autre cluster de bases de données Aurora PostgreSQL\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-database-plus-other.png)
Comme pour toute modification, vous pouvez confirmer que vous souhaitez que le processus se poursuive lorsque vous y êtes invité.
![\[Image de la console montrant l’invite de confirmation du processus de mise à niveau d’un cluster de bases de données Aurora PostgreSQL\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-apg-upgrade-2.png)
Plutôt que d’utiliser la console, vous pouvez démarrer le processus de mise à niveau en utilisant AWS CLI ou l’API RDS. Comme pour la console, vous utilisez le cluster de bases de données global Aurora plutôt que l’un de ses composants, comme suit :
+ Utilisez la [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) AWS CLI commande pour démarrer la mise à niveau de votre base de données globale Aurora à l'aide du AWS CLI.
+ Utilisez l'[ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html)API pour démarrer la mise à niveau.
# Réalisation d’une mise à niveau de version mineure
Vous pouvez utiliser les méthodes suivantes pour mettre à niveau la version mineure d’un cluster de bases de données ou appliquer un correctif à un cluster de bases de données :
**Topics**
+ [Avant d’effectuer une mise à niveau de version mineure](#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
+ [Comment effectuer des mises à niveau de versions mineures et appliquer des correctifs](#USER_UpgradeDBInstance.PostgreSQL.Minor)
+ [Mises à niveau de versions mineures et application de correctifs sans durée d’indisponibilité](#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp)
+ [Limites des correctifs sans durée d’indisponibilité](#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp.limitations)
+ [Mise à niveau du moteur Aurora PostgreSQL vers une nouvelle version mineure](#USER_UpgradeDBInstance.MinorUpgrade)
## Avant d’effectuer une mise à niveau de version mineure
Nous vous recommandons d’effectuer les actions suivantes pour réduire la durée d’indisponibilité lors d’une mise à niveau de version mineure :
+ La maintenance du cluster de bases de données Aurora doit être effectuée pendant une période de faible trafic. Utilisez Performance Insights pour identifier ces périodes afin de configurer correctement les fenêtres de maintenance. Pour plus d’informations sur Performance Insights, consultez [Surveillance de la charge de la base de données avec Performance Insights sur Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html). Pour plus d’informations sur la fenêtre de maintenance du cluster de bases de données, consultez [Ajustement du créneau de maintenance préféré pour un cluster de bases de données](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora).
+ Utilisez AWS SDKs ce support pour un recul et une instabilité exponentiels comme meilleure pratique. Pour plus d’informations, consultez [Backoff exponentiel et instabilité](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/).
## Comment effectuer des mises à niveau de versions mineures et appliquer des correctifs
Les mises à niveau et les correctifs des versions mineures ne sont disponibles Régions AWS qu'après des tests rigoureux. Avant de publier des mises à niveau et des correctifs, Aurora PostgreSQL effectue des tests pour s’assurer que les problèmes de sécurité connus, les bogues et les autres problèmes survenus après la publication de la version communautaire mineure ne perturbent pas la stabilité de la flotte Aurora PostgreSQL.
Si vous activez **Activer la mise à niveau automatique des versions mineures**, Aurora PostgreSQL met régulièrement à jour votre cluster de bases de données durant la fenêtre de maintenance spécifiée. Assurez-vous que l’option **Activer la mise à niveau automatique des versions mineures** est activée pour toutes les instances de cluster de bases de données Aurora PostgreSQL. Pour obtenir des informations sur la façon de définir **Mise à niveau automatique des versions mineures** et sur la façon dont ce paramètre fonctionne lorsqu’il est appliqué aux niveaux du cluster et de l’instance, consultez [Mises à niveau automatiques des versions mineures pour les clusters de bases de données Aurora](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU).
Vérifiez la valeur de l'option **Activer la mise à niveau automatique des versions mineures** pour tous vos clusters de base de données Aurora PostgreSQL à l'aide de [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) AWS CLI la commande suivante.
```
aws rds describe-db-instances \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'
```
Cette requête renvoie une liste de tous les clusters de base de données Aurora et de leurs instances dont le paramètre `AutoMinorVersionUpgrade` est défini sur `true` ou `false`. La commande suppose que vous êtes AWS CLI configuré pour cibler votre valeur par défaut Région AWS.
Pour plus d’informations sur l’option AmVU et sur la façon de modifier votre cluster de bases de données Aurora pour l’utiliser, consultez [Mises à niveau automatiques des versions mineures pour les clusters de bases de données Aurora](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU).
Vous pouvez mettre à niveau vos clusters de base de données Aurora PostgreSQL vers de nouvelles versions mineures, soit en répondant aux tâches de maintenance, soit en modifiant le cluster pour utiliser la nouvelle version.
Vous pouvez identifier toutes les mises à niveau ou tous les correctifs disponibles pour vos clusters de bases de données Aurora PostgreSQL à l’aide de la console RDS et en ouvrant le menu **Recommendations** (Recommandations). Vous y trouverez une liste des problèmes de maintenance tels que **Old minor versions** (Anciennes versions mineures). En fonction de votre environnement de production, vous pouvez choisir de planifier (**Schedule**) la mise à niveau ou de prendre des mesures immédiates, en choisissant **Apply now** (Appliquer maintenant), comme indiqué ci-après.
![\[Image de la console montrant la recommandation de mise à niveau vers une version mineure plus récente.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/apg-maintenance-upgrade-minor.png)
Pour en savoir plus sur la gestion d’un cluster de bases de données Aurora, y compris sur l’application manuelle des correctifs et des mises à niveau de versions mineures, consultez [Entretien d’un cluster de bases de données Amazon Aurora](USER_UpgradeDBInstance.Maintenance.md).
## Mises à niveau de versions mineures et application de correctifs sans durée d’indisponibilité
Il est possible qu’une panne se produise pendant la mise à niveau d’un cluster de bases de données Aurora PostgreSQL. Au cours du processus de mise à niveau, la base de données est arrêtée. Si vous démarrez la mise à niveau alors que la base de données est occupée, vous perdez toutes les connexions et transactions traitées par le cluster de bases de données. Si vous attendez que la base de données soit inactive pour effectuer la mise à niveau, vous devrez peut-être attendre longtemps.
La fonctionnalité ZDP (application de correctifs sans durée d’indisponibilité) améliore le processus de mise à niveau. Avec ZDP, les mises à niveau de versions mineures et les correctifs peuvent être appliqués avec un impact minimal sur votre cluster de bases de données Aurora PostgreSQL. ZDP est utilisé lors de l’application de correctifs ou de mises à jour de versions mineures plus récentes vers des versions d’Aurora PostgreSQL et d’autres versions ultérieures de ces versions mineures, et de nouvelles versions majeures. En d’autres termes, la mise à niveau vers de nouvelles versions mineures à partir de l’une de ces versions utilise ZDP.
Le tableau suivant montre les versions d’Aurora PostgreSQL et les classes d’instance de base de données où ZDP est disponible :
| Version | Classes d’instance db.r\$1 | Classes d’instance db.t\$1 | Classes d’instance db.x\$1 | Classe d’instance db.serverless |
| --- | --- | --- | --- | --- |
| 10.21 et versions ultérieures | Oui | Oui | Oui | N/A |
| 11.16 et versions ultérieures | Oui | Oui | Oui | N/A |
| 11.17 et versions ultérieures | Oui | Oui | Oui | N/A |
| 12.11 et versions ultérieures | Oui | Oui | Oui | N/A |
| 12.12 et versions ultérieures | Oui | Oui | Oui | N/A |
| 13.7 et versions ultérieures | Oui | Oui | Oui | N/A |
| 13.8 et versions ultérieures | Oui | Oui | Oui | Oui |
| 14.3 et versions ultérieures | Oui | Oui | Oui | N/A |
| 14.4 et versions ultérieures | Oui | Oui | Oui | N/A |
| 14.5 et versions ultérieures | Oui | Oui | Oui | Oui |
| 15.3 et versions ultérieures | Oui | Oui | Oui | Oui |
| 16.1 et versions ultérieures | Oui | Oui | Oui | Oui |
Au cours du processus de mise à niveau utilisant l’application de correctifs sans durée d’indisponibilité, le moteur de base de données recherche un point silencieux pour suspendre toutes les nouvelles transactions. Cette action protège la base de données lors des applications de correctifs et des mises à niveau. Pour garantir le bon fonctionnement de vos applications quand les transactions sont suspendues, nous vous recommandons d’intégrer une logique de nouvelle tentative dans votre code. Cette approche garantit que le système pourra gérer toute durée d’indisponibilité de courte durée sans défaillance et pourra réessayer les nouvelles transactions après la mise à niveau.
Lorsque l’application de correctifs sans durée d’indisponibilité réussit, les sessions d’application sont conservées, à l’exception de celles avec des connexions interrompues, et le moteur de base de données redémarre avant la fin de la mise à niveau. Le redémarrage du moteur de base de données peut entraîner une chute temporaire du débit, mais celle-ci ne dure généralement que quelques secondes ou une minute environ tout au plus.
Dans certains cas, l’application de correctifs sans durée d’indisponibilité (ZDP) peut échouer. Par exemple, les modifications de paramètres à l’état `pending` sur votre cluster de bases de données Aurora PostgreSQL ou ses instances interfèrent avec l’application de correctifs sans durée d’indisponibilité.
Vous trouverez des métriques et des événements pour les opérations ZDP sur la page **Events** (Événements) de la console. Les événements se déroulent du début de la mise à niveau ZDP à la fin de la mise à niveau. Dans ce cas, vous pouvez obtenir la durée du processus et le nombre de connexions conservées et supprimées survenues pendant le redémarrage. Pour plus de détails, consultez le journal des erreurs de votre base de données.
## Limites des correctifs sans durée d’indisponibilité
Les limitations suivantes s’appliquent à l’application de correctifs sans durée d’indisponibilité :
+ ZDP essaie de préserver les connexions actuelles des clients à votre instance d’enregistreur Aurora PostgreSQL tout au long du processus de mise à niveau d’Aurora PostgreSQL. Toutefois, dans les cas suivants, les connexions seront interrompues pour que l’application de correctifs sans durée d’indisponibilité réussisse :
+ Des requêtes ou des transactions de longue durée sont en cours.
+ Des instructions en langage de définition de données (DDL) sont en cours.
+ Des tables temporaires ou des verrous de table sont utilisés
+ Toutes les sessions sont écoutées sur des canaux de notification.
+ Un curseur dont le statut est « WITH HOLD » est en cours d’utilisation.
+ TLSv11. Les connexions sont en cours d'utilisation. À partir des versions d'Aurora PostgreSQL ultérieures à 16.1, 15.3, 14.8, 13.11, 12.15 et 11.20, ZDP est pris en charge avec les connexions .3. TLSv1
+ ZDP n’est pas pris en charge dans les cas suivants :
+ Lorsque les clusters de bases de données Aurora PostgreSQL sont configurés en tant qu’Aurora Serverless v1.
+ Lors de la mise à niveau des instances de lecture Aurora.
+ Lors de la mise à niveau des instances de lecture Aurora faisant partie d’un cluster de bases de données globale Aurora dans une région secondaire.
+ Lors des correctifs et mises à niveau du système d’exploitation.
## Mise à niveau du moteur Aurora PostgreSQL vers une nouvelle version mineure
Vous pouvez mettre à niveau votre cluster de base de données Aurora PostgreSQL vers une nouvelle version mineure à l'aide de la console, de l'API RDS ou de AWS CLI l'API RDS. Avant d’effectuer la mise à niveau, nous vous recommandons de suivre les mêmes bonnes pratiques que celles que nous recommandons pour les mises à niveau de versions majeures. Comme pour les nouvelles versions majeures, les nouvelles versions mineures peuvent également comporter des améliorations de l’optimiseur, telles que des corrections, qui peuvent entraîner des régressions du plan de requête. Pour assurer la stabilité du plan, nous vous recommandons d’utiliser l’extension Query Plan Management (QPM) comme indiqué dans [Assurer la stabilité du plan après une mise à niveau majeure de la version](AuroraPostgreSQL.Optimize.BestPractice.md#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade).
### Console
**Pour mettre à niveau la version de moteur de votre cluster de bases de données Aurora PostgreSQL**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Bases de données**, puis le cluster de bases de données que vous souhaitez mettre à niveau.
1. Sélectionnez **Modify**. La page **Modify DB cluster (Modifier le cluster DB)** s’affiche.
1. Dans le champ **Version du moteur**, sélectionnez la nouvelle version.
1. Choisissez **Continuer** et vérifiez le récapitulatif des modifications.
1. Pour appliquer les modifications immédiatement, choisissez **Appliquer immédiatement**. La sélection de cette option peut entraîner une interruption de service dans certains cas. Pour plus d’informations, consultez [Modification d’un cluster de bases de données Amazon Aurora](Aurora.Modifying.md).
1. Sur la page de confirmation, examinez vos modifications. Si elles sont correctes, choisissez **Modifier le cluster** pour enregistrer vos modifications.
Ou choisissez **Retour** pour revoir vos modifications, ou choisissez **Annuler** pour les annuler.
### AWS CLI
Pour mettre à niveau la version du moteur d'un cluster de base de données, utilisez la [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI commande avec les paramètres suivants :
+ `--db-cluster-identifier` : nom de votre cluster de bases de données Aurora PostgreSQL.
+ `--engine-version` : numéro de version du moteur de base de données vers lequel effectuer la mise à niveau. Pour plus d'informations sur les versions valides du moteur, utilisez la AWS CLI [ describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)commande.
+ `--no-apply-immediately` : appliquer les modifications pendant le créneau de maintenance suivant. Pour appliquer les modifications immédiatement, utilisez plutôt `--apply-immediately`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-cluster \
--db-cluster-identifier mydbcluster \
--engine-version new_version \
--no-apply-immediately
```
Pour Windows :
```
aws rds modify-db-cluster ^
--db-cluster-identifier mydbcluster ^
--engine-version new_version ^
--no-apply-immediately
```
### API RDS
Pour mettre à niveau la version du moteur d'un cluster de base de données, utilisez l'DBClusteropération [Modifier](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Spécifiez les paramètres suivants :
+ `DBClusterIdentifier` : nom du cluster de bases de données, par exemple *`mydbcluster`*.
+ `EngineVersion` : numéro de version du moteur de base de données vers lequel effectuer la mise à niveau. Pour plus d'informations sur les versions valides du moteur, utilisez l'opération [DBEngineDescribe les versions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html).
+ `ApplyImmediately` : si des modifications doivent être appliquées immédiatement ou au cours du prochain créneau de maintenance. Pour appliquer les modifications immédiatement, définissez la valeur sur `true`. Pour appliquer les modifications pendant le créneau de maintenance suivant, définissez la valeur sur `false`.
# Mise à niveau des extensions PostgreSQL
La mise à niveau de votre cluster de base de données Aurora PostgreSQL vers une nouvelle version majeure ou mineure ne met pas à niveau les extensions PostgreSQL en même temps. Pour la plupart des extensions, vous mettez à niveau l'extension une fois la mise à niveau de la version majeure ou mineure terminée. Toutefois, dans certains cas, vous mettez à niveau l'extension avant de mettre à niveau le moteur de base de données Aurora PostgreSQL. Pour obtenir plus d'informations, consultez [list of extensions to update](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#upgrade-extensions) dans [Test d’une mise à niveau de votre cluster de bases de données de production vers une nouvelle version majeure](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary).
L'installation des extensions PostgreSQL exige des privilèges `rds_superuser`. En règle générale, un utilisateur `rds_superuser` délègue les autorisations sur des extensions spécifiques aux utilisateurs concernés (rôles) afin de faciliter la gestion d'une extension donnée. Cela signifie que la mise à niveau de toutes les extensions de votre cluster de base de données Aurora PostgreSQL peut impliquer plusieurs utilisateurs différents (rôles). Gardez cela à l'esprit en particulier si vous souhaitez automatiser le processus de mise à niveau à l'aide de scripts. Pour plus d'informations sur les privilèges et les rôles PostgreSQL, veuillez consulter [Sécurité avec Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md).
**Note**
Pour plus d'informations sur la mise à jour de l'extension PostGIS, consultez [Gestion des données spatiales avec l’extension PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md) ([Étape 6 : Mettre à niveau l’extension PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)).
Pour mettre à jour l'extension `pg_repack`, supprimez l'extension, puis créez la nouvelle version dans l'instance de base de données mise à niveau. Pour plus d’informations, consultez [pg\$1repack installation](https://reorg.github.io/pg_repack/) dans la documentation `pg_repack`.
Pour mettre à jour une extension après une mise à niveau du moteur, utilisez la commande `ALTER EXTENSION UPDATE`.
```
ALTER EXTENSION extension_name UPDATE TO 'new_version';
```
Pour afficher une liste des extensions actuellement installées, utilisez le catalogue [pg\$1extension](https://www.postgresql.org/docs/current/catalog-pg-extension.html) PostgreSQL dans la commande suivante.
```
SELECT * FROM pg_extension;
```
Pour afficher une liste des versions d’extensions spécifiques disponibles pour votre installation, utilisez la vue [ pg\$1available\$1extension\$1versions](https://www.postgresql.org/docs/current/view-pg-available-extension-versions.html) PostgreSQL dans la commande suivante.
```
SELECT * FROM pg_available_extension_versions;
```
## Technique de blue/green mise à niveau alternative
Dans certains cas, votre priorité absolue est d’effectuer une bascule immédiate de l’ancien cluster vers un cluster mis à niveau. Dans de telles situations, vous pouvez utiliser un processus en plusieurs étapes qui exécute les anciens et les nouveaux clusters side-by-side. Dans ce cas, répliquez les données de l’ancien cluster au nouveau jusqu’à ce que ce dernier soit prêt à prendre le relais. Pour en savoir plus, consultez [Utilisation d' (Amazon Aurora Blue/Green Deployments) pour les mises à jour de bases de données](blue-green-deployments.md).