Mise à niveau des clusters de base de données Amazon SQL Aurora Postgrer - Amazon Aurora
Présentation des processus de mise à niveauObtention d'une liste des cibles de mise à niveau disponiblesComment effectuer une mise à niveau de version majeureAvant d'effectuer une mise à niveau d'une version mineureComment effectuer des mises à niveau de versions mineures et appliquer des correctifs Mise à niveau des extensions Postgre SQLTechnique alternative de mise à niveau bleu/vert

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 SQL Aurora Postgrer

Amazon Aurora ne met à disposition les nouvelles versions du moteur de SQL base de données Postgre Régions AWS qu'après des tests approfondis. Vous pouvez mettre à niveau vos clusters de SQL base de données Aurora Postgre vers la nouvelle version lorsqu'elle sera disponible dans votre région.

Selon la version d'Aurora Postgre SQL que votre cluster de base de données exécute actuellement, 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 base de données Aurora Postgre SQL 11.15 vers Aurora Postgre SQL 13.6 est une mise à niveau de version majeure. La mise à niveau d'un cluster de base de données Aurora Postgre SQL 13.3 vers Aurora Postgre SQL 13.7 est une mise à niveau de version mineure. Dans les rubriques suivantes, vous apprendrez comment effectuer les deux types de mises à niveau.

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

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 et les correctifs des versions mineures ne sont disponibles qu'une fois qu'Aurora Postgre les a SQL testés et approuvés.

Les mises à niveau de versions mineures peuvent être appliquées automatiquement par Aurora. Lorsque vous créez un nouveau cluster de SQL base de données Aurora Postgre, l'option Activer la mise à niveau des versions mineures est présélectionnée. À moins de désactiver cette option, les mises à niveau des versions mineures sont appliquées automatiquement pendant 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 base de données Aurora pour l'utiliser, consultez Mises à niveau automatiques des versions mineures pour les clusters de base de données Aurora.

Si l'option de mise à niveau automatique des versions mineures n'est pas définie pour votre cluster de SQL base de données Aurora Postgre, votre Aurora Postgre SQL n'est pas automatiquement mis à niveau vers la nouvelle version mineure. Au lieu de cela, lorsqu'une nouvelle version mineure est publiée dans votre cluster de SQL base de données Aurora Postgre Région AWS et qu'il exécute une ancienne version mineure, Aurora vous invite à effectuer une mise à 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 Postgre vous SQL invite à appliquer tous les correctifs en ajoutant une recommandation aux tâches de maintenance de votre cluster de base de données Aurora PostgreSQL. Pour de plus amples informations, veuillez consulter Comment effectuer des mises à niveau de versions mineures et appliquer des correctifs.

Note

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. Veillez à appliquer les correctifs de sécurité à votre cluster de SQL base de données Aurora Postgre lorsqu'ils seront disponibles dans le cadre de vos tâches de maintenance en attente.

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. Toutefois, après SQL les versions 14.3.3, 13.7.3, 12.11.3, 11.16.3, 10.21.3 d'Aurora Postgre et les autres versions supérieures de ces versions mineures et des versions majeures plus récentes, le processus de mise à niveau utilise la fonctionnalité patching () sans interruption de service. ZDP Cette fonctionnalité réduit les pannes et les élimine complètement dans la plupart des cas. Pour de plus amples informations, veuillez consulter Mises à niveau de versions mineures et application de correctifs sans temps d'arrêt.

Note

ZDPn'est pas pris en charge dans les cas suivants :

  • Lorsque les clusters de SQL base de données Aurora Postgre sont configurés commeAurora Serverless v1.

  • Lorsque les clusters de SQL base de données Aurora Postgre sont configurés en tant que base de données globale Aurora dans la base de données secondaire Régions AWS.

  • Lors de la mise à niveau des instances de lecteur dans la base de données globale Aurora.

  • Lors des correctifs et mises à niveau du système d'exploitation.

ZDPest pris en charge pour les clusters de SQL base de données Aurora Postgre configurés en tant queAurora Serverless v2.

Mises à niveau de version majeure.

Contrairement aux mises à niveau et aux correctifs des versions mineures, Aurora Postgre SQL ne propose pas d'option de mise à niveau automatique des versions majeures. Les nouvelles SQL versions majeures de Postgre 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 la section Test d'une mise à niveau de votre cluster de base de données de production vers une nouvelle version majeure Avant de mettre à niveau les instances de base de données de vos clusters de SQL base de données Aurora Postgre. 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 SQL base de données Aurora Postgre vers la nouvelle version.

Le processus de mise à niveau implique la possibilité d'une brève interruption lorsque toutes les instances du cluster sont mises à niveau vers la nouvelle version. 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 de plus amples informations, veuillez consulter Comment effectuer une mise à niveau de version majeure.

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 SQL base de données Aurora Postgre 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 Les classements pris en charge dans Aurora PostgreSQL.

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 SQL base de données Aurora Postgre en vous interrogeant Région AWS à l'aide de la describe-db-engine-versions AWS CLI commande suivante.

Pour LinuxmacOS, ou Unix :

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version version-number \
  --query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \
  --output text

Dans 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 Postgre SQL version 12.10, exécutez la commande suivante : AWS CLI

Pour LinuxmacOS, ou Unix :

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version 12.10 \
  --query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \
  --output text

Dans Windows :

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version 12.10 ^
  --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
  --output text

Dans le tableau suivant, vous trouverez les cibles de mise à niveau des versions majeures et mineures pour les différentes versions de la SQL base de données Aurora Postgre. Pour garantir la compatibilité, toutes les versions ne sont pas proposées comme cibles de mise à niveau. Aurora Postgre SQL introduit de nouvelles fonctionnalités et des corrections de bogues à chaque publication trimestrielle de version mineure. Pour plus d'informations sur les versions SQL mineures d'Aurora Postgre, consultez les notes de publication d'Aurora SQL Postgre.

Version source actuelle Cibles de mise à niveau
16,3

Aucun
16,2 16,3
16,1 16,3, 16,2
15,7 16,3
15,6

16,3, 16,2

15,7

15,5

16,3, 16,2, 16,1

15,7, 15,6

15,4

16,3, 16,2, 16,1

15,7, 15,6, 15,5

15,3

16,3, 16,2, 16,1

15,7, 15,6, 15,5, 15,4

15,2

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3

14,12

16,3

15,7

14,11

16,3, 16,2

15,6

14,12

14,10

16,3, 16,2, 16,1

15,7, 15,6, 15,5

14,12, 14,11

14,9

16,3, 16,2, 16,1

15,7, 15,6, 15,5, 15,4

14,12, 14,11, 14,10

14,8

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12, 14,11, 14,10, 14,9

14,7

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8

14,6

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7

14,5

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7, 14,6

14,4

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7, 14,6, 14,5

14,3

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7, 14,6, 14,5, 14,4

13,15

16,3

15,7

14,12

13,14

16,3, 16,2

15,7, 15,6

14,11

13,15

13,13

16,3, 16,2, 16,1

15,7, 15,6, 15,5

14,12, 14,11, 14,10

13,15, 13,14

13,12

16,3, 16,2, 16,1

15,7, 15,6, 15,5, 15,4

14,12, 14,11, 14,10, 14,9

13,15, 13,14, 13,13

13,11

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3

14,12 , 14,11, 14,10, 14,9, 14,8

13,15, 13,14, 13,13, 13,12

13,10

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7

13,14, 13,13, 13,12, 13,11

13,9

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7, 14,6

13,14, 13,11, 13,10

13,8

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7, 14,6, 14,5

13,14 , 13,13, 13,12, 13,11, 13,10, 13,9

13,7

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7, 14,6, 14,5, 14,4, 14,3

13,14 , 13,13, 13,12, 13,11, 13,10, 13,9, 13,8

12,19

16,3

15,7

14,12

13,15

12,18

16,3, 16,2

15,7, 15,6

14,12, 14,11

13,15, 13,14

12,17

16,3, 16,2, 16,1

15,7, 15,6, 15,5

14,12, 14,11, 14,10

13,15, 13,14, 13,13

12,16

16,3, 16,2, 16,1

15,7, 15,6, 15,5, 15,4

14,12, 14,11, 14,10, 14,9

13,15, 13,14, 13,13, 13,12

12,15

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3

14,12 , 14,11, 14,10, 14,9, 14,8

13,15 , 13,14, 13,13, 13,12, 13,11

12,14

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7

13,15 , 13,14, 13,13, 13,12, 13,11, 13,10

12,15

12,13

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7, 14,6

13,15 , 13,14, 13,13, 13,12, 13,11, 13,10, 13,9

12,19 , 12,18, 12,17, 12,16, 12,15, 12,14

12,12

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7, 14,6, 14,5

13,15 , 13,14, 13,13, 13,12, 13,11, 13,10, 13,9, 13,8

12,19 , 12,18, 12,17, 12,16, 12,15, 12,14, 12,13

12,11

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7, 14,5, 14,4, 14,3

13,15 , 13,14, 13,13, 13,12, 13,10, 13,9, 13,8, 13,7

12,19 , 12,18, 12,17, 12,16, 12,15, 12,14, 12,13, 12,12

12,9

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7

13,14 , 13,13, 13,12, 13,11, 13,10, 13,9, 13,8, 13,7

12,17 , 12,16, 12,15, 12,14, 12,13, 12,12, 12,11

11,21

16,3, 16,2, 16,1

15,7, 15,6, 15,5, 15,4

14,12, 14,11, 14,10, 14,9

13,15, 13,14, 13,13, 13,12

12,19, 12,18, 12,17, 12,16

11.9

16,3, 16,2, 16,1

15,7 , 15,6, 15,5, 15,4, 15,3, 15,2

14,12 , 14,11, 14,10, 14,9, 14,8, 14,7, 14,6

13,15 , 13,14, 13,13, 13,12, 13,11, 13,10, 13,9

12,19 , 12,18, 12,17, 12,16, 12,15, 12,14, 12,13, 12,12, 12,11, 12,09

11,21

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 Postgre SQL 13. Si votre cluster de SQL base de données Aurora Postgre utilise actuellement une classe d'instance db.r4, vous devez passer à db.r5 avant d'essayer de procéder à la mise à niveau. Pour plus d'informations sur les classes d'instance de base de données, y compris celles qui sont basées sur Graviton2 et celles qui sont basées sur Intel, reportez-vous à la section Classes d'instances de base de données Amazon Aurora.

Comment effectuer 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 plus de détails, consultez Obtenir une liste des versions disponibles dans votre Région AWS.

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

  3. 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 plus de détails, consultez Mise à niveau du SQL moteur Aurora Postgre vers une nouvelle version majeure.

Note

Vous pouvez effectuer une mise à niveau majeure de Babelfish pour les versions basées sur Aurora Postgre SQL 13 à partir de la version 13.6 vers les versions basées sur Aurora Postgre SQL 14 à partir de la version 14.6. Babelfish pour Aurora Postgre SQL 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 SQL base de données Aurora Postgre en vous interrogeant à Région AWS l'aide de la describe-db-engine-versions AWS CLI commande suivante.

Pour LinuxmacOS, ou Unix :

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version version-number \
  --query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}' \
  --output text

Dans 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 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 base 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 à l'aide de l'extension Query Plan Management (QPM), comme indiqué dansAssurer la stabilité du plan après une mise à niveau majeure de la version.

Avant de mettre à niveau vos clusters de SQL base de données Aurora Postgre 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 base 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 base de données ou ces deux éléments pour la nouvelle version du moteur de base de données.

    2. Créez votre propre groupe de paramètres personnalisé pour la nouvelle version du moteur de base de données.

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

  2. 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* 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*. L'utilitaire pg_upgrade (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_upgrade dans la documentation de SQL Postgre.

      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');

    • Si vous mettez à niveau un cluster de base de données Aurora Postgre SQL version 10.18 ou ultérieure sur lequel l'pgRoutingextension est installée, supprimez l'extension avant de passer à la version 12.4 ou supérieure.

      Si vous effectuez une mise à niveau d'une version SQL 10.x d'Aurora Postgre sur laquelle l'extension 1.4.3 est installée, supprimez l'extension avant de passer à une pg_repack version supérieure.

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

  4. Supprimez des emplacements logiques de réplication.

    Le processus de mise à niveau ne peut pas se poursuivre si le cluster de SQL base de données Aurora Postgre 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 logiques ne sont pas nécessaires, vous pouvez les supprimer en procédant comme suit SQL :

    SELECT pg_drop_replication_slot(slot_name);

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

  5. Effectuez une sauvegarde.

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

  6. 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 de plus amples informations, veuillez consulter Mise à niveau des extensions Postgre SQL. Pour en savoir plus sur la mise à niveau de PostGIS, consultezÉtape 6 : mise à niveau de l'GISextension Post.

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

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

    La SQL version 10 de Postgre ne prend pas en charge ce type de unknown données. 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 trouver le type de unknown données dans votre base de données afin de pouvoir supprimer ces colonnes ou les remplacer par des types de données compatibles, utilisez le SQL code 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');

  9. Procédez à un essai de mise à niveau.

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

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

  10. Mettez à niveau votre instance de production.

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

    Note

    Au cours du processus de mise à niveau, Aurora Postgre SQL prend un instantané du cluster de base de données si la période de rétention des sauvegardes du cluster est supérieure à 0. Vous ne pouvez pas point-in-time restaurer votre cluster pendant 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 plus d'informations sur une mise à niveau en cours, vous pouvez utiliser Amazon RDS pour consulter deux journaux produits par l'utilitaire pg_upgrade. Il s'agit des journaux pg_upgrade_internal.log et pg_upgrade_server.log. Amazon Aurora ajoute un horodatage au nom de fichier de ces journaux. Vous pouvez consultez ces journaux comme tout autre journal. Pour de plus amples informations, veuillez consulter Surveillance des fichiers journaux Amazon Aurora.

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

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 SQL instances de base de données Postgre. 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 plus d'informations, consultez ANALYZEla SQL documentation Postgre.

    Note

    Exécutez-le ANALYZE sur votre système après la mise à niveau pour éviter les problèmes de performances.

  • Si vous êtes passé à la SQL version 10 de Postgre, exécutez-le 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 les index de hachage non valides, exécutez la commande suivante SQL 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 SQL moteur Aurora Postgre vers une nouvelle version majeure

Lorsque vous lancez le processus de mise à niveau vers une nouvelle version majeure, Aurora Postgre SQL prend un instantané du cluster de base 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é, vous pouvez trouver cet instantané parmi les instantanés manuels répertoriés sous Instantanés de la RDS console. Le nom du snapshot inclut preupgrade comme préfixe le nom de votre cluster de SQL base de données Aurora Postgre, la version source, la version cible, ainsi que la date et l'horodatage, comme indiqué 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 base 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 base de données Aurora à différents moments. Pour en savoir plus, consultez Restauration à partir d'un instantané de cluster de base de données et Restauration d'un cluster de base de données à une date définie. Cependant, Aurora Postgre SQL ne prend pas en charge l'utilisation d'un instantané pour restaurer une version mineure précédente.

Au cours du processus de mise à niveau de la version majeure, Aurora alloue un volume et clone le cluster de base de données Aurora SQL Postgre source. Si la mise à niveau échoue pour une raison quelconque, Aurora Postgre SQL 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 Postgre SQL annule la mise à niveau, tenez compte des points suivants :

  • 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 Postgre SQL nettoie le volume supplémentaire une fois que la période de conservation des sauvegardes du cluster a dépassé la date de 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 constituent votre cluster, Aurora Postgre SQL utilise l'utilitaire pg_upgrade. 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 SQL utilitaire Postgre, consultez pg_upgrade dans la documentation Postgre. SQL

Vous pouvez mettre à niveau votre cluster de SQL base de données Aurora Postgre vers une nouvelle version en utilisant le AWS Management Console AWS CLI, le ou le RDSAPI.

Pour mettre à niveau la version de moteur d'un cluster de base de données

  1. Connectez-vous à la RDS console Amazon AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans le panneau de navigation, choisissez Bases de données, puis le cluster de base de données que vous souhaitez mettre à niveau.

  3. Sélectionnez Modify. La page Modify DB cluster (Modifier le cluster DB) s'affiche.

  4. Dans le champ Version du moteur, sélectionnez la nouvelle version.

  5. Choisissez Continuer et vérifiez le récapitulatif des modifications.

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

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

Pour mettre à niveau la version du moteur d'un cluster de base de données, utilisez la modify-db-cluster AWS CLI commande. Spécifiez les paramètres suivants :

  • --db-cluster-identifier : nom du cluster de base 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-versionscommande.

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

Exemple

Pour LinuxmacOS, ou Unix :

aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --engine-version new_version \
    --allow-major-version-upgrade \
    --no-apply-immediately

Dans Windows :

aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --engine-version new_version ^
    --allow-major-version-upgrade ^
    --no-apply-immediately

Pour mettre à niveau la version du moteur d'un cluster de base de données, utilisez l'odifyDBClusteropération M. Spécifiez les paramètres suivants :

  • DBClusterIdentifier— Le nom du cluster de base 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 D escribeDBEngine Versions.

  • 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 base de données global Aurora, le processus de mise à niveau met à niveau tous les clusters de base de données qui composent votre base de données globale Aurora en même temps. Il le fait pour s'assurer que chacun exécute la même SQL version d'Aurora Postgre. 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 indiqué dansTest d'une mise à niveau de votre cluster de base de données de production vers une nouvelle version majeure. 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. indiqué Test d'une mise à niveau de votre cluster de base de données de production vers une nouvelle version majeure dans le

Si un objectif de point de récupération (RPO) est défini pour le paramètre de votre cluster de base de données SQL global Aurora Postgre, assurez-vous de réinitialiser le rds.global_db_rpo paramètre avant de procéder à la mise à niveau. Le processus de mise à niveau de la 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 SQL globales Aurora Postgre et RPO consultezGestion des RPOs bases de données globales SQL basées sur Aurora Postgre.

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 SQL moteur Aurora Postgre vers une nouvelle version majeure. Assurez-vous de choisir l'élément de niveau supérieur dans la liste des bases de données de la RDS console, Base de données globale, comme indiqué dans l'image suivante.

Image de console montrant une base de données globale Aurora, un Aurora Serverless cluster de bases de données et un autre cluster de base de SQL données Aurora Postgre

Comme pour toute modification, vous pouvez confirmer que vous souhaitez que le processus se poursuive lorsque vous y êtes invité.

Image de console montrant une invite à confirmer le processus de mise à niveau pour un cluster de SQL base de données Aurora Postgre

Plutôt que d'utiliser la console, vous pouvez démarrer le processus de mise à niveau en utilisant le AWS CLI ou le RDSAPI. Comme pour la console, vous utilisez le cluster de base de données global Aurora plutôt que l'un de ses composants, comme suit :

  • Utilisez la modify-global-cluster AWS CLI commande pour démarrer la mise à niveau de votre base de données globale Aurora à l'aide du AWS CLI.

  • Utilisez le ModifyGlobalClusterAPIpour démarrer la mise à niveau.

Avant d'effectuer une mise à niveau d'une version mineure

Nous vous recommandons d'effectuer les actions suivantes pour réduire le temps d'arrêt lors d'une mise à niveau de version mineure :

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 Postgre effectue SQL des tests pour s'assurer que les problèmes de sécurité connus, les bogues et les autres problèmes apparus après la sortie de la version communautaire mineure ne perturbent pas la stabilité globale du SQL parc Aurora Postgre.

Au fur et à mesure qu'Aurora Postgre SQL met à disposition de nouvelles versions mineures, les instances qui constituent votre cluster de SQL base de données Aurora Postgre peuvent être automatiquement mises à niveau pendant la période de maintenance spécifiée. Pour que cela se produise, l'option Activer la mise à niveau automatique des versions mineures de votre SQL cluster de base de données Aurora Postgre doit être activée. Toutes les instances de base de données qui constituent votre cluster de SQL base de données Aurora Postgre doivent avoir l'option de mise à niveau automatique des versions mineures (AMVu) activée afin que la mise à niveau mineure soit appliquée à l'ensemble du cluster.

Astuce

Assurez-vous que l'option Activer la mise à niveau automatique des versions mineures est activée pour toutes les instances de SQL base de données Postgre qui constituent votre cluster de SQL base de données Aurora Postgre. Cette option doit être activée pour que chaque instance du cluster de base de données fonctionne. 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 base de données Aurora.

Vous pouvez vérifier la valeur de l'option Activer la mise à niveau automatique des versions mineures pour tous vos clusters de SQL base de données Aurora Postgre à l'aide de la describe-db-instances AWS CLI commande avec la requête 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 illustrée 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 base de données Aurora pour l'utiliser, consultez Mises à niveau automatiques des versions mineures pour les clusters de base de données Aurora.

Vous pouvez mettre à niveau vos clusters de SQL base de données Aurora Postgre vers de nouvelles versions mineures soit en répondant à des tâches de maintenance, soit en modifiant le cluster pour utiliser la nouvelle version.

Vous pouvez identifier les mises à niveau ou les correctifs disponibles pour vos clusters de SQL base de données Aurora Postgre en utilisant la RDS console et en ouvrant le menu 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.

Pour en savoir plus sur la gestion d'un cluster de base 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 base de données Amazon Aurora.

Mises à niveau de versions mineures et application de correctifs sans temps d'arrêt

La mise à niveau d'un cluster de SQL base de données Aurora Postgre implique la possibilité d'une panne. 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 base 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é patching (ZDP) sans interruption de service améliore le processus de mise à niveau. AinsiZDP, les mises à niveau des versions mineures et les correctifs peuvent être appliqués avec un impact minimal sur votre cluster de SQL base de données Aurora Postgre. ZDPest utilisé lors de l'application de correctifs ou de mises à niveau de versions mineures plus récentes aux SQL versions d'Aurora Postgre et aux autres versions supérieures de ces versions mineures et de nouvelles versions majeures. C'est-à-dire que la mise à niveau vers de nouvelles versions mineures à partir de l'une de ces versions est utiliséeZDP.

Le tableau suivant indique les SQL versions d'Aurora Postgre et les classes d'instances de base de ZDP données disponibles :

Version Classes d'instances db.r* Classes d'instances db.t* Classes d'instances db.x* Classe d'instance db.serverless
Version 10.21.0 et versions 10.21 ultérieures Oui Oui Oui N/A
Version 11.16.0 et versions 11.16 ultérieures Oui Oui Oui N/A
Version 11.17 et versions ultérieures Oui Oui Oui N/A
Version 12.11.0 et versions 12.11 ultérieures Oui Oui Oui N/A
Version 12.12 et versions ultérieures Oui Oui Oui N/A
Version 13.7.0 et versions 13.7 ultérieures Oui Oui Oui N/A
Version 13.8 et versions ultérieures Oui Oui Oui Oui
Version 14.3.1 et versions 14.3 ultérieures Oui Oui Oui N/A
Version 14.4.0 et versions 14.4 ultérieures Oui Oui Oui N/A
Version 14.5 et versions ultérieures Oui Oui Oui Oui
Version 15.3 et versions ultérieures Oui Oui Oui Oui

ZDPfonctionne en préservant les connexions client actuelles à votre cluster de SQL base de données Aurora Postgre tout au long du processus de SQL mise à niveau d'Aurora Postgre. Toutefois, dans les cas suivants, les connexions seront interrompues ZDP pour être terminées :

  • Des requêtes ou des transactions de longue durée sont en cours.

  • Les instructions du langage de définition des données (DDL) sont en cours d'exécution.

  • Des tables temporaires ou des verrous de table sont utilisés

  • Toutes les sessions sont écoutées sur des canaux de notification.

  • Un curseur au statut « WITH HOLD » est en cours d'utilisation.

  • TLSv1Les connexions 3.3 ou TLSv1 1.1 sont en cours d'utilisation.

Pendant le processus de mise à niveau à l'aide deZDP, 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 tout temps d'arrêt de courte durée sans défaillance et pourra réessayer les nouvelles transactions après la mise à niveau.

Une fois l'ZDPopération terminée, les sessions d'application sont maintenues, à l'exception de celles dont les connexions ont été interrompues, et le moteur de base de données redémarre alors que la mise à niveau est toujours en cours. 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 interruption de service (ZDP) peut échouer. Par exemple, les modifications de paramètres qui se trouvent dans un pending état de votre cluster de SQL base de données Aurora Postgre ou de ses instances interfèrent avecZDP.

Vous pouvez trouver les statistiques et les événements relatifs ZDP aux opérations sur la page Événements de la console. Les événements incluent le début et la ZDP 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.

Mise à niveau du SQL moteur Aurora Postgre vers une nouvelle version mineure

Vous pouvez mettre à niveau votre cluster de SQL base de données Aurora Postgre vers une nouvelle version mineure à l'aide de la console, du AWS CLI, ou du RDSAPI. 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 garantir la stabilité du plan, nous vous recommandons d'utiliser l'extension Query Plan Management (QPM) comme indiqué dansAssurer la stabilité du plan après une mise à niveau majeure de la version.

Pour mettre à niveau la version du moteur de votre cluster de SQL base de données Aurora Postgre

  1. Connectez-vous à la RDS console Amazon AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans le panneau de navigation, choisissez Bases de données, puis le cluster de base de données que vous souhaitez mettre à niveau.

  3. Sélectionnez Modify. La page Modify DB cluster (Modifier le cluster DB) s'affiche.

  4. Dans le champ Version du moteur, sélectionnez la nouvelle version.

  5. Choisissez Continuer et vérifiez le récapitulatif des modifications.

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

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

Pour mettre à niveau la version du moteur d'un cluster de base de données, utilisez la modify-db-cluster AWS CLI commande avec les paramètres suivants :

  • --db-cluster-identifier— Le nom de votre cluster de SQL base de données Aurora Postgre.

  • --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-versionscommande.

  • --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 LinuxmacOS, ou Unix :

aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --engine-version new_version \
    --no-apply-immediately

Dans Windows :

aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --engine-version new_version ^
    --no-apply-immediately

Pour mettre à niveau la version du moteur d'un cluster de base de données, utilisez l'odifyDBClusteropération M. Spécifiez les paramètres suivants :

  • DBClusterIdentifier— Le nom du cluster de base 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 D escribeDBEngine Versions.

  • 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 Postgre SQL

La mise à niveau de votre SQL cluster de base de données Aurora Postgre vers une nouvelle version majeure ou mineure ne met pas à niveau les SQL extensions Postgre 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 SQL base de données Aurora Postgre. Pour obtenir plus d'informations, consultez list of extensions to update dans Test d'une mise à niveau de votre cluster de base de données de production vers une nouvelle version majeure.

L'installation des SQL extensions Postgre nécessite des rds_superuser privilèges. 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 tâche de mise à niveau de toutes les extensions de votre cluster de SQL base de données Aurora Postgre peut impliquer de nombreux utilisateurs (rôles) différents. 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 SQL privilèges et les rôles de Postgre, consultezSécurité avec Amazon Aurora Postgre SQL.

Note

Pour plus d'informations sur la mise à jour de GIS l'extension Post, consultez Gestion des données spatiales avec l'GISextension Post (Étape 6 : mise à niveau de l'GISextension Post).

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, veuillez consulter pg_repack installation 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 répertorier les extensions actuellement installées, utilisez le catalogue Postgre SQL pg_extension dans la commande suivante.

SELECT * FROM pg_extension;

Pour afficher la liste des versions d'extension spécifiques disponibles pour votre installation, utilisez la vue Postgre SQL pg_available_extension_versions dans la commande suivante. 

SELECT * FROM pg_available_extension_versions;

Technique alternative de mise à niveau bleu/vert

Dans certains cas, votre priorité absolue est d'effectuer une commutation 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 de plus amples informations, veuillez consulter Utilisation d'Amazon RDS Blue/Green Deployments pour les mises à jour de bases de données.