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.
# Amazon RDS pour PostgreSQL
Amazon RDS prend en charge les instances de bases de données qui exécutent plusieurs versions de PostgreSQL. Pour obtenir la liste des versions disponibles, consultez [Versions de base de données PostgreSQL disponibles](PostgreSQL.Concepts.General.DBVersions.md).
Vous pouvez créer des instances de bases de données et des instantanés de base de données, ainsi que des restaurations et des sauvegardes à un moment donné. Les instances de base de données qui exécutent PostgreSQL prennent en charge les déploiements Multi-AZ, les réplicas en lecture et les IOPS provisionnés, et peuvent être créées au sein d'un cloud privé virtuel (VPC). Vous pouvez également utiliser le protocole SSL pour vous connecter à une instance de base de données exécutant PostgreSQL.
Avant de créer une instance de base de données, assurez-vous d'avoir effectué les étapes de la section [Configuration de votre environnement Amazon RDS](CHAP_SettingUp.md).
Vous pouvez utiliser une application cliente SQL standard quelconque pour exécuter les commandes pour l'instance à partir de votre ordinateur client. De telles applications incluent pgAdmin, un outil d'administration et de développement Open Source fréquemment utilisé pour PostgreSQL, ou psql, un utilitaire de ligne de commande inclus dans une installation PostgreSQL. Pour offrir une expérience de service géré, Amazon RDS ne fournit pas l'accès hôte aux instances de base de données. Il restreint également l’accès à certaines procédures système et tables qui requièrent des privilèges avancés. Amazon RDS prend en charge l’accès aux bases de données sur une instance de base de données en utilisant toute application cliente SQL standard. Amazon RDS ne permet pas d'accès de l'hôte direct à une instance de base de données via Telnet ou Secure Shell (SSH).
Amazon RDS pour PostgreSQL est conforme à de nombreuses normes du secteur. Par exemple, vous pouvez utiliser des bases de données Amazon RDS pour PostgreSQL afin de développer des applications conformes à la loi HIPAA et de stocker les informations relatives aux soins de santé. Cela inclut le stockage des informations de santé protégées (PHI, Protected Health Information) selon les termes d'un Accord d'association commerciale (BAA, Business Associate Agreement) conclu avec AWS. Amazon RDS pour PostgreSQL respecte également les exigences de sécurité du Programme fédéral de gestion des risques et des autorisations (FedRAMP) Amazon RDS pour PostgreSQL a obtenu auprès du conseil d’autorisation commun (Joint Authorization Board, JAB) l’autorisation provisoire d’opérer (Provisional Authority to Operate, P-ATO) à niveau d’impact élevé du FedRAMP au sein des régions AWS GovCloud (US). Pour plus d’informations sur les normes de conformité prises en charge, consultez [Conformité du Cloud AWS](https://aws.amazon.com/compliance/).
Pour importer des données PostgreSQL dans une instance de base de données, suivez les informations fournies dans la section [Importation de données dans PostgreSQL sur Amazon RDS](PostgreSQL.Procedural.Importing.md).
**Important**
Si vous rencontrez un problème avec votre instance de base de données RDS pour PostgreSQL, votre agent de support AWS peut avoir besoin de plus d’informations sur l’état de vos bases de données. L’objectif est de garantir qu’AWS Support obtienne les informations requises le plus rapidement possible.
Vous pouvez utiliser PG Collector pour rassembler de précieuses informations de base de données dans un fichier HTML consolidé. Pour plus d’informations sur PG Collector, comment l’exécuter et comment télécharger le rapport HTML, consultez [PG Collector](https://github.com/awslabs/pg-collector).
En cas d’exécution réussie et sauf indication contraire, le script renvoie la sortie dans un format HTML lisible. Ce script est conçu pour exclure toutes les données ou informations de sécurité du contenu HTML susceptible de compromettre votre activité. De plus, il n’apporte aucune modification à la base de données ou à son environnement. Toutefois, si vous trouvez dans le contenu HTML des informations que vous ne souhaitez pas partager, n’hésitez pas à supprimer les informations problématiques avant de charger le contenu HTML. Lorsque le contenu HTML est acceptable, chargez-le dans la section des pièces jointes des détails du cas de votre dossier de support.
**Topics**
+ [
# Tâches courantes de gestion pour Amazon RDS for PostgreSQL
](CHAP_PostgreSQL.CommonTasks.md)
+ [
# Utilisation de l’environnement de version préliminaire de base de données
](working-with-the-database-preview-environment.md)
+ [
# Versions de base de données PostgreSQL disponibles
](PostgreSQL.Concepts.General.DBVersions.md)
+ [
# Présentation du processus de publication incrémentielle de RDS pour PostgreSQL
](PostgreSQL.Concepts.General.ReleaseProcess.md)
+ [
# Versions de l'extension PostgreSQL prises en charge
](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md)
+ [
# Utilisation des fonctions PostgreSQL prises en charge par Amazon RDS pour PostgreSQL
](PostgreSQL.Concepts.General.FeatureSupport.md)
+ [
# Connexion à une instance de base de données exécutant le moteur de base de données PostgreSQL
](USER_ConnectToPostgreSQLInstance.md)
+ [
# Sécurisation des connexions à RDS pour PostgreSQL avec SSL/TLS
](PostgreSQL.Concepts.General.Security.md)
+ [
# Utilisation de l’authentification Kerberos avec Amazon RDS pour PostgreSQL
](postgresql-kerberos.md)
+ [
# Utilisation d'un serveur DNS personnalisé pour l'accès réseau sortant.
](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md)
+ [
# Mises à niveau du moteur de base de données RDS pour PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.md)
+ [
# Mise à niveau d'une version du moteur d'instantané de base de données PostgreSQL
](USER_UpgradeDBSnapshot.PostgreSQL.md)
+ [
# Utilisation de réplicas en lecture pour Amazon RDS pour PostgreSQL
](USER_PostgreSQL.Replication.ReadReplicas.md)
+ [
# Amélioration des performances des requêtes pour RDS pour PostgreSQL avec Lectures optimisées pour Amazon RDS
](USER_PostgreSQL.optimizedreads.md)
+ [
# Importation de données dans PostgreSQL sur Amazon RDS
](PostgreSQL.Procedural.Importing.md)
+ [
# Exportation de données à partir d’une instance de base de données RDS pour PostgreSQL vers Amazon S3
](postgresql-s3-export.md)
+ [
# Invocation d'une AWS Lambda fonction depuis une instance de base de données
](PostgreSQL-Lambda.md)
+ [
# Tâches courantes d’administration de bases de données pour Amazon RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.md)
+ [
# Réglage avec les événements d'attente pour RDS for PostgreSQL
](PostgreSQL.Tuning.md)
+ [
# Optimisation de RDS pour PostgreSQL Aurora PostgreSQL DevOps
](PostgreSQL.Tuning_proactive_insights.md)
+ [
# Utilisation des extensions PostgreSQL avec Amazon RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Extensions.md)
+ [
# Utilisation des encapsuleurs de données externes pris en charge pour Amazon RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md)
+ [
# Utilisation de Trusted Language Extensions pour PostgreSQL
](PostgreSQL_trusted_language_extension.md)
# Tâches courantes de gestion pour Amazon RDS for PostgreSQL
Vous trouverez ci-dessous les tâches courantes de gestion que vous exécutez avec une instance de base de données Amazon RDS for PostgreSQL, avec des liens vers la documentation appropriée relative à chaque tâche.
| Type de tâche | Documentation |
| --- | --- |
| **Configuration d'Amazon RDS pour la première utilisation** Vous devez remplir quelques conditions préalables avant de créer votre instance de base de données. Par exemple, des instances de bases de données sont créées par défaut avec un pare-feu qui empêche d'y accéder. Vous devez créer un groupe de sécurité avec les adresses IP et la configuration réseau voulues pour accéder à l'instance de base de données. | [Configuration de votre environnement Amazon RDS](CHAP_SettingUp.md) |
| **Présentation des instances de bases de données d'Amazon RDS** Si vous créez une instance de base de données à des fins de production, vous devez comprendre comment les classes d'instance, les types de stockage et les IOPS provisionnées fonctionnent dans Amazon RDS. | [Classes d'instances de base de données ](Concepts.DBInstanceClass.md) [Types de stockage Amazon RDS](CHAP_Storage.md#Concepts.Storage) [Stockage SSD à IOPS provisionnées](CHAP_Storage.md#USER_PIOPS) |
| **Recherche des versions de PostgreSQL disponibles** Amazon RDS prend en charge plusieurs versions de PostgreSQL. | [Versions de base de données PostgreSQL disponibles](PostgreSQL.Concepts.General.DBVersions.md) |
| **Configuration de la haute disponibilité et de la prise en charge du basculement** Une instance de base de données de production doit utiliser des déploiements multi-AZ. Les déploiements Multi-AZ améliorent la disponibilité, la durabilité des donnés et la tolérance aux pannes pour les instances de bases de données. | [Configuration et gestion d’un déploiement multi-AZ pour Amazon RDS](Concepts.MultiAZ.md) |
| **Présentation du réseau Amazon Virtual Private Cloud (VPC)** Si votre AWS compte possède un VPC par défaut, votre instance de base de données est automatiquement créée dans le VPC par défaut. Dans certains cas, votre compte peut ne pas avoir de VPC par défaut, et vous pouvez souhaiter que l'instance de base de données soit dans un VPC. Dans ce cas, créez le VPC et les groupes de sous-réseau avant de créer l'instance de base de données. | [Utilisation d’une instance de base de données dans un VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md) |
| **Importation de données dans Amazon RDS PostgreSQL** Vous pouvez utiliser différents outils pour importer des données dans votre instance de base de données PostgreSQL sur Amazon RDS. | [Importation de données dans PostgreSQL sur Amazon RDS](PostgreSQL.Procedural.Importing.md) |
| **Configuration des réplicas en lecture (principaux et de secours) en lecture seule** RDS pour PostgreSQL prend en charge les répliques de lecture dans la AWS même région et dans une région AWS différente de celle de l'instance principale. | [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md) [Utilisation de réplicas en lecture pour Amazon RDS pour PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md) [Création d'une réplique de lecture dans un autre Région AWS](USER_ReadRepl.XRgn.md) |
| **Présentation des groupes de sécurité** Par défaut, les instances de bases de données sont créées avec un pare-feu qui empêche d'y accéder. Pour fournir l'accès via ce pare-feu, vous modifiez les règles entrantes pour le groupe de sécurité du VPC associé au VPC hébergeant l'instance de base de données. | [Contrôle d’accès par groupe de sécurité](Overview.RDSSecurityGroups.md) |
| **Configuration des fonctionnalités et des groupes de paramètres** Pour modifier les paramètres par défaut de votre instance de base de données, créez un groupe de paramètres de base de données personnalisé et modifiez les paramètres. Si vous procédez de la sorte avant de créer votre instance de base de données, vous pouvez choisir votre groupe de paramètres de base de données personnalisé lorsque vous créez l'instance. | [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md) |
| **Connexion à votre instance de base de données PostgreSQL** Après avoir créé un groupe de sécurité et l'avoir associé à une instance de base de données, vous pouvez vous connecter à l'instance de base de données en utilisant une application cliente SQL standard quelconque telle que `psql` ou `pgAdmin`. | [Connexion à une instance de base de données exécutant le moteur de base de données PostgreSQL](USER_ConnectToPostgreSQLInstance.md) [Utilisation de SSL avec une instance de base de données PostgreSQL](PostgreSQL.Concepts.General.SSL.md) |
| **Sauvegarde et restauration de votre instance de base de données** Vous pouvez configurer votre instance de base de données pour que les sauvegardes soient exécutées automatiquement ou que les instantanés soient créés manuellement, puis que les instances soient restaurées à partir des sauvegardes ou des instantanés. | [Sauvegarde, restauration et exportation de données](CHAP_CommonTasks.BackupRestore.md) |
| **Surveillance de l'activité et des performances de votre instance de base de données** Vous pouvez surveiller une instance de base de données PostgreSQL à l'aide des métriques, des événements et de la surveillance améliorée d' CloudWatch Amazon RDS. | [Affichage des métriques dans la console Amazon RDS](USER_Monitoring.md) [Affichage d’événements Amazon RDS](USER_ListEvents.md) |
| **Mise à niveau de la version de base de données PostgreSQL** Vous pouvez procéder à la mise à niveau des versions majeures et mineures de votre instance de base de données PostgreSQL. | [Mises à niveau du moteur de base de données RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md) [Choix d’une mise à niveau de version majeure RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md) |
| **Utilisation des fichiers journaux** Vous pouvez accéder aux fichiers journaux de votre instance de base de données PostgreSQL. | [Fichiers journaux de base de données RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md) |
| **Présentation des bonnes pratiques pour les instances de bases de données PostgreSQL** Découvrez certaines des meilleures pratiques pour l'utilisation de PostgreSQL sur Amazon RDS. | [Bonnes pratiques pour utiliser les moteurs de stockage PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL) |
Vous trouverez ci-dessous une liste d'autres sections de ce guide qui peuvent vous aider à comprendre et à utiliser les fonctions importantes de RDS for PostgreSQL :
+ [Comprendre les rôles et les autorisations PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [Contrôle de l'accès utilisateur à la base de données PostgreSQLContrôle de l'accès utilisateur à PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [Utilisation de paramètres sur votre instance de base de données RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
+ [Utilisation de mécanismes de journalisation pris en charge par RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [Utilisation de la fonction autovacuum de PostgreSQL sur Amazon RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [Utilisation d'un serveur DNS personnalisé pour l'accès réseau sortant.](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md)
# Utilisation de l’environnement de version préliminaire de base de données
La communauté PostgreSQL publie continuellement de nouvelles versions et extensions PostgreSQL, y compris des versions bêta. Cela donne aux utilisateurs de PostgreSQL la possibilité d'essayer de façon anticipée une nouvelle version de PostgreSQL. Pour en savoir plus sur le processus de publication des versions bêta par la communauté PostgreSQL, consultez [Beta Information](https://www.postgresql.org/developer/beta/) (Informations relatives aux versions bêta) dans la documentation PostgreSQL. De même, Amazon RDS propose certaines versions bêta de PostgreSQL sous forme de préversions. Cela vous permet de créer des instances de base de données à l’aide de la préversion et de tester ses fonctionnalités dans l’environnement de version préliminaire de base de données.
Les instances de base de données RDS pour PostgreSQL dans l’environnement de version préliminaire de base de données sont similaires sur le plan fonctionnel à d’autres instances RDS pour PostgreSQL. Toutefois, vous ne pouvez pas utiliser une préversion pour la production.
Retenez bien les limites importantes suivantes :
+ Toutes les instances de base de données sont supprimées 60 jours après leur création, en même temps que leurs sauvegardes et leurs instantanés.
+ Vous ne pouvez créer une instance de base de données que dans un cloud privé virtuel (VPC) basé sur un service Amazon VPC.
+ Vous ne pouvez utiliser que les stockages SSD à usage général et les stockages SSD à IOPS provisionnées.
+ Vous ne pouvez pas obtenir d'aide auprès du AWS Support pour les instances de base de données. [Vous pouvez plutôt publier vos questions sur la communauté de AWS questions-réponses gérée,AWS Re:post.](https://repost.aws/tags/TAsibBK6ZeQYihN9as4S_psg/amazon-relational-database-service)
+ Vous ne pouvez pas copier un instantané d’instance de base de données dans un environnement de production.
Les options suivantes sont prises en charge par la préversion.
+ Vous pouvez créer des instances de base de données à l'aide des types d'instance M6i, R6i, M6g, M5, T3, R6g et R5 uniquement. Pour plus d’informations sur les classes d’instance RDS, consultez [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).
+ Vous pouvez utiliser à la fois des déploiements mono-AZ et multi-AZ.
+ Vous pouvez utiliser les fonctions de vidage et de chargement PostgreSQL standard pour exporter des bases de données depuis ou importer des bases de données vers l’environnement de version préliminaire de base de données.
**Topics**
+ [
## Fonctions non prises en charge dans l’environnement de version préliminaire de base de données
](#preview-environment-exclusions)
+ [
## PostgreSQL version 17 dans l’environnement de version préliminaire de base de données
](#PostgreSQL.Concepts.General.version17)
+ [
# Création d’une nouvelle instance de base de données dans l’environnement de version préliminaire de base de données
](create-db-instance-in-preview-environment.md)
## Fonctions non prises en charge dans l’environnement de version préliminaire de base de données
Les fonctions suivantes ne sont pas disponibles dans l’environnement de version préliminaire de base de données :
+ Copie d’instantanés entre Régions
+ Réplicas en lecture entre Régions
## PostgreSQL version 17 dans l’environnement de version préliminaire de base de données
**Note**
Il s’agit de la documentation d’aperçu pour Amazon RDS PostgreSQL version 17. Elle est susceptible d’être modifiée.
PostgreSQL version 17.0 est maintenant disponible dans l’environnement de version préliminaire de base de données Amazon RDS. PostgreSQL version 17.0 contient plusieurs améliorations qui sont décrites dans la documentation PostgreSQL suivante : [PostgreSQL 17 Released\$1](https://www.postgresql.org/docs/17/release-17.html)
Pour plus d’informations sur l’environnement de version préliminaire de base de données, consultez [Utilisation de l’environnement de version préliminaire de base de données](#working-with-the-database-preview-environment). Pour accéder à l'environnement de prévisualisation depuis la console, sélectionnez [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/).
# Création d’une nouvelle instance de base de données dans l’environnement de version préliminaire de base de données
Utilisez la procédure suivante pour créer une instance de base de données dans l'environnement en préversion.
**Pour créer une instance de base de données dans l'environnement de prévisualisation de base 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. Choisissez **Dashboard (Tableau de bord)** dans le panneau de navigation.
1. Sur la page Tableau de bord, recherchez la section **Environnement de version préliminaire de base de données**, comme illustré dans l’image suivante.
![\[Section d’environnement en préversion avec un lien affiché dans la console RDS, dans Tableau de bord\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/preview-environment-dashboard.png)
Vous pouvez accéder directement à l'[environnement de prévisualisation de base de données](https://us-east-2.console.aws.amazon.com/rds-preview/home?region=us-east-2#). Avant de poursuivre, vous devez reconnaître et accepter les limites.
![\[Boîte de dialogue sur les limites de l'environnement en préversion\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/preview-environment-console.png)
1. Pour créer l'instance de base de données RDS for PostgreSQL, suivez le même processus que pour créer n'importe quelle instance de base de données Amazon RDS. Pour plus d'informations, consultez la procédure [Console](USER_CreateDBInstance.md#USER_CreateDBInstance.CON) dans [Création d’une instance de base de données](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
Pour créer une instance dans l'environnement en préversion de base de données via l'API RDS ou AWS CLI, utilisez le point de terminaison suivant.
```
rds-preview.us-east-2.amazonaws.com
```
# Versions de base de données PostgreSQL disponibles
Amazon RDS prend en charge les instances de bases de données qui exécutent plusieurs éditions de PostgreSQL. Vous pouvez spécifier toute version de PostgreSQL actuellement disponible lors de la création d'une instance de base de données. Vous pouvez spécifier la version majeure (telle que PostgreSQL 14), et toute version mineure disponible pour la version majeure spécifiée. Si aucune version n'est spécifiée, Amazon RDS utilise par défaut une version disponible, généralement la version la plus récente. Si une version majeure est spécifiée, mais qu’une version mineure ne l’est pas, Amazon RDS utilise par défaut une version récente de la version majeure que vous avez spécifiée.
Pour voir la liste des versions disponibles, ainsi que les valeurs par défaut pour les instances de base de données nouvellement créées, utilisez la [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI commande. Par exemple, pour afficher la version par défaut du moteur PostgreSQL, utilisez la commande suivante :
```
aws rds describe-db-engine-versions --default-only --engine postgres
```
Pour plus d’informations sur les versions PostgreSQL prises en charge sur Amazon RDS, consultez [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/Welcome.html). Vous pouvez également consulter les informations relatives aux dates de support des principales versions du moteur en exécutant la AWS CLI commande [describe-db-major-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-major-engine-versions.html) ou en utilisant l'opération d'API [DBMajorEngineVersionsDescribe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBMajorEngineVersions.html) RDS.
Si vous n’êtes pas prêt à effectuer une mise à niveau manuelle vers une nouvelle version majeure de moteur avant la date de fin du support standard RDS, Amazon RDS inscrira automatiquement vos bases de données au support étendu Amazon RDS après la date de fin du support standard RDS. Vous pouvez ensuite continuer à exécuter RDS pour PostgreSQL version 11 ou ultérieure. Pour plus d'informations, consultez [Support étendu Amazon RDS avec Amazon RDS](extended-support.md) et [Tarification d'Amazon RDS](https://aws.amazon.com/rds/pricing/).
## Versions obsolètes pour Amazon RDS for PostgreSQL
Notez les versions obsolètes suivantes :
+ RDS pour PostgreSQL 10 est devenu obsolète en février 2023.
+ RDS pour PostgreSQL 9.6 est devenu obsolète en mars 2022.
+ RDS pour PostgreSQL 9.5 est devenu obsolète en mars 2021.
[Pour en savoir plus sur la politique d'obsolescence de RDS pour PostgreSQL, consultez Amazon RDS. FAQs](https://aws.amazon.com/rds/faqs/) Pour plus d’informations sur les versions de PostgreSQL, consultez [Versioning Policy](https://www.postgresql.org/support/versioning/)dans la documentation PostgreSQL.
# Présentation du processus de publication incrémentielle de RDS pour PostgreSQL
RDS pour PostgreSQL fournit des correctifs de sécurité, des améliorations de performances et de nouvelles fonctionnalités par le biais de versions incrémentielles, tout en préservant la compatibilité des versions mineures. Ces versions sont étiquetées R1, R2, R3, etc.
**Convention de dénomination des versions de publication**
+ La version initiale d’une version mineure est R1. Elle inclut parfois de nouvelles fonctionnalités, des extensions ou des mises à niveau d’extensions existantes.
+ Les versions ultérieures (R2, R3 et versions ultérieures) incluent :
+ Mises à jour de sécurité
+ Améliorations des performances
+ Correctifs de bogues
+ Mises à jour des extensions
## Avantages du processus de publication incrémentielle de RDS pour PostgreSQL
Le processus de publication incrémentielle offre les avantages suivants :
+ Adoption rapide des nouvelles versions de la communauté PostgreSQL tout en gérant séparément les améliorations spécifiques à RDS dans les versions suivantes. Cela rationalise le processus de publication et garantit une livraison plus rapide des mises à jour critiques.
+ Accès aux corrections de bugs, aux nouvelles fonctionnalités, aux mises à jour de sécurité et aux mises à jour des extensions tout en maintenant la compatibilité avec la version mineure de PostgreSQL.
## Gestion des mises à jour de publication
Amazon RDS vous informe des nouvelles versions incrémentielles par le biais d’actions de maintenance en attente dans la AWS Management Console. Vous pouvez mettre à jour votre base de données à l’aide de l’une des méthodes suivantes :
+ Activez les mises à jour automatiques pendant les fenêtres de maintenance planifiées.
+ Appliquez les mises à jour manuellement par le biais d’actions de maintenance en attente.
+ Utilisez Blue/Green des déploiements avec réplication physique pour minimiser les temps d'arrêt. Pour plus d’informations, consultez [Déploiements bleu/vert prenant en charge la mise à niveau de version mineure de RDS pour PostgreSQL](https://aws.amazon.com/about-aws/whats-new/2024/11/rds-blue-green-deployments-upgrade-rds-postgresql/).
Avant de mettre à jour votre base de données, tenez compte des points suivants :
+ Le redémarrage de la base de données est nécessaire pour les mises à jour, sauf si vous utilisez des déploiements bleu/vert avec réplication physique.
+ Certaines versions incrémentielles sont obligatoires, en particulier celles qui incluent des correctifs de sécurité.
Pour plus d'informations sur la mise à jour de votre instance de base de données Amazon RDS, consultez [Extensions de confiance PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.Extensions.Trusted) et [apply-pending-maintenance-action](https://docs.aws.amazon.com/cli/latest/reference/rds/apply-pending-maintenance-action.html).
# Versions de l'extension PostgreSQL prises en charge
RDS pour PostgreSQL prend en charge de nombreuses extensions PostgreSQL. La communauté PostgreSQL les appelle parfois des modules. Les extensions complètent les fonctionnalités fournies par le moteur PostgreSQL. Vous trouverez une liste des extensions prises en charge par Amazon RDS dans le groupe de paramètres de base de données par défaut pour cette version de PostgreSQL. Vous pouvez également consulter la liste actuelle des extensions utilisant `psql` en affichant le paramètre `rds.extensions` comme dans l'exemple suivant.
```
SHOW rds.extensions;
```
**Note**
Les paramètres ajoutés à une version mineure peuvent s'afficher de manière incorrecte lors de l'utilisation du paramètre `rds.extensions` dans `psql`.
À partir de RDS pour PostgreSQL 13, certaines extensions peuvent être installées par des utilisateurs de bases de données autres que le `rds_superuser`. On les appelle des *extensions de confiance*. Pour en savoir plus, consultez [Extensions de confiance PostgreSQL](#PostgreSQL.Concepts.General.Extensions.Trusted).
Certaines versions de RDS pour PostgreSQL prennent en charge le paramètre `rds.allowed_extensions`. Ce paramètre permet à un `rds_superuser` de limiter les extensions qui peuvent être installées dans l’instance de base de données RDS pour PostgreSQL. Pour plus d’informations, consultez [Restriction de l'installation des extensions PostgreSQL](#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Pour obtenir la liste des extensions et des versions de PostgreSQL prises en charge par chaque version disponible de RDS pour PostgreSQL, consultez [Extensions PostgreSQL prises en charge par Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) dans *Notes de mise à jour d’Amazon RDS pour PostgreSQL*.
## Restriction de l'installation des extensions PostgreSQL
Vous pouvez restreindre les extensions pouvant être installées sur une instance de base de données PostgreSQL. Par défaut, ce paramètre n'est pas défini. Par conséquent, toute extension prise en charge peut être ajoutée si l'utilisateur dispose des autorisations appropriées. Pour ce faire, définissez le paramètre `rds.allowed_extensions` sur une chaîne de noms d'extension séparés par des virgules. En ajoutant une liste d’extensions à ce paramètre, vous identifiez explicitement les extensions que votre instance de base de données RDS pour PostgreSQL peut utiliser. Seules ces extensions peuvent alors être installées dans l'instance de base de données PostgreSQL.
La chaîne par défaut du paramètre `rds.allowed_extensions` est « \$1 », ce qui signifie que toute extension disponible pour la version du moteur peut être installée. La modification du paramètre `rds.allowed_extensions` ne nécessite pas de redémarrage de la base de données, car il s'agit d'un paramètre dynamique.
Le moteur d'instance de base de données PostgreSQL doit être l'une des versions suivantes pour que vous puissiez utiliser le paramètre `rds.allowed_extensions` :
+ Toutes les versions de PostgreSQL 16
+ PostgreSQL 15 et toutes les versions supérieures
+ PostgreSQL 14 et toutes les versions ultérieures
+ PostgreSQL 13.3 et versions mineures ultérieures
+ PostgreSQL 12.7 et versions mineures ultérieures
Pour voir quelles installations d'extension sont autorisées, utilisez la commande psql suivante.
```
postgres=> SHOW rds.allowed_extensions;
rds.allowed_extensions
------------------------
*
```
Si une extension a été installée avant d'être exclue de la liste dans le paramètre `rds.allowed_extensions`, l'extension peut toujours être utilisée normalement, et les commandes telles que `ALTER EXTENSION` et `DROP EXTENSION` resteront opérationnelles. Cependant, une fois qu'une extension est restreinte, les commandes `CREATE EXTENSION` de l'extension restreinte échouent.
L'installation des dépendances d'extension avec `CREATE EXTENSION CASCADE` sont également restreintes. L'extension et ses dépendances doivent être spécifiées dans `rds.allowed_extensions`. Si une installation de dépendance d'extension échoue, l'instruction `CREATE EXTENSION CASCADE` échouera dans son intégralité.
Si une extension n'est pas incluse avec le paramètre `rds.allowed_extensions`, vous verrez une erreur telle que la suivante si vous essayez de l'installer.
```
ERROR: permission denied to create extension "extension-name"
HINT: This extension is not specified in "rds.allowed_extensions".
```
## Extensions de confiance PostgreSQL
L'installation de la plupart des extensions PostgreSQL nécessite de privilèges `rds_superuser`. PostgreSQL 13 introduit des extensions d'approbation, ce qui réduit la nécessité d'accorder des privilèges `rds_superuser` aux utilisateurs réguliers. Cette fonction permet aux utilisateurs d'installer de nombreuses extensions s'ils disposent du privilège `CREATE` sur la base de données actuelle, sans exiger le rôle `rds_superuser`. Pour plus d'informations, consultez la commande SQL [CREATE EXTENSION (CRÉER UNE EXTENSION)](https://www.postgresql.org/docs/current/sql-createextension.html) dans la documentation PostgreSQL.
La liste suivante répertorie les extensions qui peuvent être installées par un utilisateur qui possède le privilège `CREATE` sur la base de données actuelle, sans exiger le rôle `rds_superuser` :
+ bool\$1plperl
+ [btree\$1gin](http://www.postgresql.org/docs/current/btree-gin.html)
+ [btree\$1gist](http://www.postgresql.org/docs/current/btree-gist.html)
+ [citext](http://www.postgresql.org/docs/current/citext.html)
+ [cube](http://www.postgresql.org/docs/current/cube.html)
+ [dict\$1int](http://www.postgresql.org/docs/current/dict-int.html)
+ [fuzzystrmatch](http://www.postgresql.org/docs/current/fuzzystrmatch.html)
+ [hstore](http://www.postgresql.org/docs/current/hstore.html)
+ [ intarray](http://www.postgresql.org/docs/current/intarray.html)
+ [isn](http://www.postgresql.org/docs/current/isn.html)
+ jsonb\$1plperl
+ [ltree](http://www.postgresql.org/docs/current/ltree.html)
+ [pg\$1trgm](http://www.postgresql.org/docs/current/pgtrgm.html)
+ [pgcrypto](http://www.postgresql.org/docs/current/pgcrypto.html)
+ [plperl](https://www.postgresql.org/docs/current/plperl.html)
+ [plpgsql](https://www.postgresql.org/docs/current/plpgsql.html)
+ [pltcl](https://www.postgresql.org/docs/current/pltcl-overview.html)
+ [tablefunc](http://www.postgresql.org/docs/current/tablefunc.html)
+ [tsm\$1system\$1rows](https://www.postgresql.org/docs/current/tsm-system-rows.html)
+ [tsm\$1system\$1time](https://www.postgresql.org/docs/current/tsm-system-time.html)
+ [unaccent](http://www.postgresql.org/docs/current/unaccent.html)
+ [uuid-ossp](http://www.postgresql.org/docs/current/uuid-ossp.html)
Pour obtenir la liste des extensions et des versions de PostgreSQL prises en charge par chaque version disponible de RDS pour PostgreSQL, consultez [ Extensions PostgreSQL prises en charge par Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) dans *Notes de mise à jour d’Amazon RDS pour PostgreSQL*.
# Utilisation des fonctions PostgreSQL prises en charge par Amazon RDS pour PostgreSQL
Amazon RDS pour PostgreSQL prend en charge la plupart des fonctionnalités les plus courantes de PostgreSQL. Par exemple, PostgreSQL dispose d'une fonction d'autovacuum qui effectue une maintenance de routine sur la base de données. La fonction d'autovacuum est active par défaut. Bien que vous puissiez désactiver cette fonction, nous vous recommandons vivement de la conserver active. Comprendre cette fonction et ce que vous pouvez faire pour vous assurer qu'elle fonctionne comme il se doit est une tâche de base de tout DBA. Pour de plus amples informations sur l’autovacuum, consultez [Utilisation de la fonction autovacuum de PostgreSQL sur Amazon RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md). Pour en savoir plus sur les autres tâches DBA courantes, [Tâches courantes d’administration de bases de données pour Amazon RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md).
RDS pour PostgreSQL prend également en charge les extensions qui ajoutent des fonctionnalités importantes à l’instance de base de données. Par exemple, vous pouvez utiliser l'extension PostGIS pour travailler avec des données spatiales ou utiliser l'extension pg\$1cron pour planifier la maintenance depuis l'instance elle-même. Pour plus d’informations sur les extensions PostgreSQL, consultez [Utilisation des extensions PostgreSQL avec Amazon RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.md).
Les wrappers de données externes sont un type d’extension spécifique conçu pour permettre à votre instance de base de données RDS pour PostgreSQL de fonctionner avec d’autres bases de données commerciales ou types de données. Pour de plus amples informations sur les wrappers de données externes prises en charge par RDS pour PostgreSQL, consultez [Utilisation des encapsuleurs de données externes pris en charge pour Amazon RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md).
Ci-dessous, vous trouverez des informations sur certaines autres fonctionnalités prises en charge par RDS pour PostgreSQL.
**Topics**
+ [
# Types de données et énumérations personnalisés avec RDS for PostgreSQL
](PostgreSQL.Concepts.General.FeatureSupport.AlterEnum.md)
+ [
# Déclencheurs d'évènements pour RDS for PostgreSQL
](PostgreSQL.Concepts.General.FeatureSupport.EventTriggers.md)
+ [
# Grandes pages pour RDS pour PostgreSQL
](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md)
+ [
# Réplication logique pour Amazon RDS pour PostgreSQL
](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md)
+ [
# Configuration de l'authentification IAM pour les connexions de réplication logiques
](PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.md)
+ [
# Disque RAM pour le stats\$1temp\$1directory
](PostgreSQL.Concepts.General.FeatureSupport.RamDisk.md)
+ [
# Espaces de table pour RDS for PostgreSQL
](PostgreSQL.Concepts.General.FeatureSupport.Tablespaces.md)
+ [
# Classements RDS pour PostgreSQL pour EBCDIC et autres migrations mainframe.
](PostgreSQL.Collations.mainframe.migration.md)
+ [
# Gestion de la synchronisation des emplacements logiques pour RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.pglogical.slot.synchronization.md)
# Types de données et énumérations personnalisés avec RDS for PostgreSQL
PostgreSQL prend en charge la création de types de données personnalisés et l'utilisation d'énumérations. Pour de plus amples informations sur la création et l'utilisation d'énumérations et d'autres types de données, veuillez consulter [Types énumérés](https://www.postgresql.org/docs/14/datatype-enum.html) dans la documentation PostgreSQL.
Voici un exemple de création d'un type en tant qu'énumération, puis d'insertion de valeurs dans une table.
```
CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple');
CREATE TYPE
CREATE TABLE t1 (colors rainbow);
CREATE TABLE
INSERT INTO t1 VALUES ('red'), ( 'orange');
INSERT 0 2
SELECT * from t1;
colors
--------
red
orange
(2 rows)
postgres=> ALTER TYPE rainbow RENAME VALUE 'red' TO 'crimson';
ALTER TYPE
postgres=> SELECT * from t1;
colors
---------
crimson
orange
(2 rows)
```
# Déclencheurs d'évènements pour RDS for PostgreSQL
Toutes les versions actuelles de PostgreSQL prennent en charge les déclencheurs d'événements, tout comme toutes les versions disponibles de RDS for PostgreSQL. Vous pouvez utiliser le compte d'utilisateur principal (par défaut, `postgres`) pour créer, modifier, renommer et supprimer des déclencheurs d'évènements. Les déclencheurs d'évènements sont au niveau de l'instance de base de données, de sorte qu'ils peuvent s'appliquer à toutes les bases de données sur une instance.
Par exemple, le code suivant crée un déclencheur d'évènement qui imprime l'utilisateur actuel à la fin de chaque commande DDL.
```
CREATE OR REPLACE FUNCTION raise_notice_func()
RETURNS event_trigger
LANGUAGE plpgsql AS
$$
BEGIN
RAISE NOTICE 'In trigger function: %', current_user;
END;
$$;
CREATE EVENT TRIGGER event_trigger_1
ON ddl_command_end
EXECUTE PROCEDURE raise_notice_func();
```
Pour plus d'informations sur les déclencheurs d'évènements PostgreSQL, consultez [Déclencheurs d'évènements](https://www.postgresql.org/docs/current/static/event-triggers.html) dans la documentation de PostgreSQL.
Il existe plusieurs restrictions quant à l'utilisation de déclencheurs d'évènements PostgreSQL sur Amazon RDS. Cela inclut les éléments suivants :
+ Vous ne pouvez pas créer de déclencheurs d'évènements sur les réplicas en lecture. En revanche, vous pouvez créer de déclencheurs d'évènements sur une source de réplica en lecture. Les déclencheurs d'évènements sont ensuite copiés sur le réplica en lecture. Les déclencheurs d'évènements sur le réplica en lecture ne s'activent pas sur le réplica en lecture lorsque les modifications sont poussées depuis la source. En revanche, si le réplica en lecture est promu, les déclencheurs d'évènements existants s'activent lorsque des opérations de base de données ont lieu.
+ Pour effectuer une mise à niveau de version majeure vers une instance de base de données PostgreSQL qui utilise des déclencheurs d'évènements, vous devez supprimer les déclencheurs d'évènements avant de procéder à la mise à niveau de l'instance.
# Grandes pages pour RDS pour PostgreSQL
Les *Huge pages* (Grandes pages) sont une fonction de gestion de la mémoire qui réduit la surcharge lorsqu'une instance de base de données fonctionne avec de gros morceaux de mémoire contigus, tels que ceux utilisés par les tampons partagés. Cette fonction PostgreSQL est prise en charge par toutes les versions actuellement disponibles de RDS pour PostgreSQL. Vous allouez de grandes pages pour votre application en utilisant des appels à la mémoire partagée `mmap` ou `SYSV`. RDS pour PostgreSQL prend en charge les tailles de pages de 4 Ko et de 2 Mo.
Vous pouvez activer ou désactiver les Grandes pages en modifiant la valeur du paramètre `huge_pages`. La fonction est activée par défaut pour toutes les classes d'instances de base de données autres que les classes micro, petites et medium.
RDS pour PostgreSQL utilise les grandes pages en fonction de la mémoire partagée disponible. Si l'instance de base de données ne peut pas utiliser les grandes pages en raison des contraintes de mémoire partagée, Amazon RDS empêche le démarrage de l'instance de base de données. Dans ce cas, Amazon RDS affecte au statut de l'instance de base de données un état indiquant l'incompatibilité des paramètres. Dans ce cas, vous pouvez affecter la valeur « `huge_pages` » au paramètre `off` pour autoriser Amazon RDS à démarrer l'instance de bases de données.
Le paramètre `shared_buffers` est essentiel pour définir le groupe de mémoire partagée requis pour utiliser les grandes pages. La valeur par défaut du paramètre `shared_buffers` utilise une macro de paramètres de base de données. Cette macro définit un pourcentage du total des 8 Ko pages disponibles pour la mémoire de l'instance de base de données. Lorsque vous utilisez des grandes pages, celles-ci se trouvent avec les grandes pages. Amazon RDS affecte à une instance de base de données dans un état indiquant l'incompatibilité des paramètres si les paramètres de mémoire partagée définis requièrent plus de 90 % de la mémoire de l'instance de base de données.
Pour en savoir plus sur la gestion de la mémoire PostgreSQL, consultez [Resource Consumption](https://www.postgresql.org/docs/current/static/runtime-config-resource.html) dans la documentation PostgreSQL.
# Réplication logique pour Amazon RDS pour PostgreSQL
Dès la version 10.4, RDS pour PostgreSQL prend en charge la syntaxe SQL de publication et d’abonnement qui a été introduite dans PostgreSQL 10. Pour en savoir plus, consultez [Réplication logique](https://www.postgresql.org/docs/current/logical-replication.html) dans la documentation PostgreSQL.
**Note**
Outre la fonctionnalité de réplication logique native de PostgreSQL introduite dans PostgreSQL 10, RDS pour PostgreSQL prend également en charge l’extension `pglogical`. Pour plus d’informations, consultez [Utilisation de pglogical pour synchroniser les données entre les instances](Appendix.PostgreSQL.CommonDBATasks.pglogical.md).
Ci-dessous, vous trouverez des informations sur la configuration de la réplication logique pour une instance de base de données RDS pour PostgreSQL.
**Topics**
+ [
## Compréhension de la réplication logique et du décodage logique
](#PostgreSQL.Concepts.General.FeatureSupport.LogicalDecoding)
+ [
## Utilisation des emplacements de réplication logique
](#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplicationSlots)
+ [
## Réplication des données au niveau des tables à l’aide de la réplication logique
](#PostgreSQL.Concepts.LogicalReplication.Tables)
## Compréhension de la réplication logique et du décodage logique
RDS pour PostgreSQL prend en charge le streaming des modifications WAL (write-ahead log) à l’aide d’emplacements de réplication logique PostgreSQL. Il prend également en charge l'utilisation du décodage logique. Vous pouvez configurer des emplacements logiques de réplication sur votre instance et diffuser les modifications de base de données à travers ces emplacements pour un client comme `pg_recvlogical`. Les emplacements logiques de réplication sont créés au niveau de la base de données et prennent en charge les connexions de réplication avec une base de données unique.
Les clients les plus courants pour la réplication logique PostgreSQL AWS Database Migration Service sont les hôtes gérés de manière personnalisée sur une instance Amazon EC2. L'emplacement de réplication logique ne contient aucune information sur le récepteur du flux. De plus, il n'est pas nécessaire que la cible soit une base de données de réplica. Si vous configurez un emplacement de réplication logique et que vous ne lisez pas à partir de l'emplacement, les données peuvent être écrites dans le stockage de votre instance de base de données et le remplir rapidement.
La réplication logique et le décodage logique PostgreSQL sur Amazon RDS sont activés avec un paramètre, un type de connexion de réplication et un rôle de sécurité. Le client pour le décodage logique peut être n'importe quel client capable d'établir une connexion de réplication avec une base de données sur une instance de base de données PostgreSQL.
**Pour activer le décodage logique pour une instance de base de données RDS pour PostgreSQL**
1. Assurez-vous que le compte utilisateur que vous utilisez possède les rôles suivants :
+ Le rôle `rds_superuser` de manière à ce que vous puissiez activer la réplication logique
+ Le rôle `rds_replication` pour accorder les autorisations de gérer des emplacements logiques et de diffuser les données à l'aide d'emplacements logiques
1. Définissez le paramètre statique `rds.logical_replication` sur 1. Dans le cadre de l'application de ce paramètre, configurez également les paramètres `wal_level`, `max_wal_senders`, `max_replication_slots` et `max_connections`. Ces modifications de paramètres peuvent accroître la génération WAL de sorte que vous ne devez définir le paramètre `rds.logical_replication` que lorsque vous utilisez des emplacements logiques.
1. Redémarrez l'instance de base de données pour que le paramètre statique `rds.logical_replication` prenne effet.
1. Créez un emplacement de réplication logique comme expliqué dans la section suivante. Cela nécessite que vous précisiez un plugin de décodage. Actuellement, RDS pour PostgreSQL prend en charge les plugins de sortie test\$1decoding et wal2json fournis avec PostgreSQL.
Pour plus d'informations sur le décodage logique PostgreSQL, consultez la [ documentation PostgreSQL](https://www.postgresql.org/docs/current/static/logicaldecoding-explanation.html).
## Utilisation des emplacements de réplication logique
Vous pouvez utiliser les commandes SQL pour utiliser les emplacements logiques. Par exemple, la commande suivante crée un emplacement logique nommé `test_slot` à l'aide du plugin de sortie PostgreSQL par défaut `test_decoding`.
```
SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding');
slot_name | xlog_position
-----------------+---------------
regression_slot | 0/16B1970
(1 row)
```
Pour lister les emplacements logiques, utilisez la commande suivante.
```
SELECT * FROM pg_replication_slots;
```
Pour supprimer un emplacement logique, utilisez la commande suivante.
```
SELECT pg_drop_replication_slot('test_slot');
pg_drop_replication_slot
-----------------------
(1 row)
```
Pour plus d'exemples sur l'utilisation des emplacements de réplication logique, consultez [ Exemples de décodage logique](https://www.postgresql.org/docs/9.5/static/logicaldecoding-example.html) dans la documentation PostgreSQL.
Après avoir créé l'emplacement de réplication logique, vous pouvez commencer le streaming. L'exemple suivant montre comment le décodage logique est contrôlé par le protocole de streaming. Celui-ci utilise le programme pg\$1recvlogical, qui est inclus dans la distribution PostgreSQL. Cela nécessite que l'authentification du client soit configurée pour autoriser les connexions de réplication.
```
pg_recvlogical -d postgres --slot test_slot -U postgres
--host -instance-name.111122223333.aws-region.rds.amazonaws.com
-f - --start
```
Pour afficher le contenu de la vue `pg_replication_origin_status`, interrogez la fonction `pg_show_replication_origin_status`.
```
SELECT * FROM pg_show_replication_origin_status();
local_id | external_id | remote_lsn | local_lsn
----------+-------------+------------+-----------
(0 rows)
```
## Réplication des données au niveau des tables à l’aide de la réplication logique
Vous pouvez utiliser la réplication logique pour répliquer les données des tables sources vers les tables cibles dans RDS pour PostgreSQL. La réplication logique effectue d’abord un chargement initial des données existantes à partir des tables sources, puis continue à répliquer les modifications en cours.
1.
**Création des tables source**
Connectez-vous à la base de données source de votre instance de base de données RDS pour PostgreSQL :
```
source=> CREATE TABLE testtab (slno int primary key);
CREATE TABLE
```
1.
**Insertion des données dans les tables sources**
```
source=> INSERT INTO testtab VALUES (generate_series(1,1000));
INSERT 0 1000
```
1.
**Création d’une publication pour les tables sources**
+ Créez une publication pour les tables sources :
```
source=> CREATE PUBLICATION testpub FOR TABLE testtab;
CREATE PUBLICATION
```
+ Utilisez une requête SELECT pour vérifier les détails de la publication créée :
```
source=> SELECT * FROM pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
--------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
115069 | testpub | 16395 | f | t | t | t | t | f
(1 row)
```
+ Vérifiez que les tables sources sont ajoutées à la publication :
```
source=> SELECT * FROM pg_publication_tables;
pubname | schemaname | tablename
---------+------------+-----------
testpub | public | testtab
(1 rows)
```
+ Pour répliquer toutes les tables d’une base de données, utilisez :
```
CREATE PUBLICATION testpub FOR ALL TABLES;
```
+ Si la publication est déjà créée pour une table individuelle et que vous devez ajouter une nouvelle table, vous pouvez exécuter la requête ci-dessous pour ajouter de nouvelles tables dans la publication existante :
```
ALTER PUBLICATION add table ;
```
1.
**Connexion à la base de données cible et création de tables cibles**
+ Connectez-vous à la base de données cible dans l’instance de base de données cible. Créez les tables cibles portant les mêmes noms que les tables sources :
```
target=> CREATE TABLE testtab (slno int primary key);
CREATE TABLE
```
+ Assurez-vous qu’aucune donnée n’est présente dans les tables cibles en exécutant une requête SELECT sur les tables cibles :
```
target=> SELECT count(*) FROM testtab;
count
-------
0
(1 row)
```
1.
**Création et vérification de l’abonnement dans la base de données cible**
+ Créez l’abonnement dans la base de données cible :
```
target=> CREATE SUBSCRIPTION testsub
CONNECTION 'host= port=5432 dbname= user= password='
PUBLICATION testpub;
NOTICE: Created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
+ Utilisez une requête SELECT pour vérifier que l’abonnement est activé :
```
target=> SELECT oid, subname, subenabled, subslotname, subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16434 | testsub | t | testsub | {testpub}
(1 row)
```
+ Lorsque l’abonnement est créé, il charge toutes les données des tables sources vers les tables cibles. Exécutez une requête SELECT sur les tables cibles pour vérifier que les données initiales sont chargées :
```
target=> SELECT count(*) FROM testtab;
count
-------
1000
(1 row)
```
1.
**Vérification du slot de réplication dans la base de données source**
La création d’un abonnement dans la base de données cible crée un slot de réplication dans la base de données source. Vérifiez les détails du slot de réplication en exécutant la requête SELECT suivante sur la base de données source :
```
source=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size
----------+----------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------
testsub | pgoutput | logical | 115048 | source | f | t | 846 | | 6945 | 58/B4000568 | 58/B40005A0 | reserved |
(1 row)
```
1.
**Test de la réplication**
+ Vérifiez si les modifications apportées aux données dans les tables sources sont répliquées dans les tables cibles en insérant des lignes dans les tables sources :
```
source=> INSERT INTO testtab VALUES(generate_series(1001,2000));
INSERT 0 1000
source=> SELECT count(*) FROM testtab;
count
-------
2000
(1 row)
```
+ Vérifiez le nombre de lignes dans les tables cibles pour confirmer que les nouveaux inserts sont répliqués :
```
target=> SELECT count(*) FROM testtab;
count
-------
2000
(1 row)
```
1.
**Actualisation de l’abonnement après l’ajout de tables**
+ Lorsque vous ajoutez de nouvelles tables à une publication existante, il est obligatoire d’actualiser l’abonnement pour que les modifications prennent effet :
```
ALTER SUBSCRIPTION REFRESH PUBLICATION;
```
+ Cette commande récupère les informations de table manquantes auprès du diffuseur de publication et lance la réplication des tables qui ont été ajoutées aux publications faisant l’objet d’un abonnement depuis la création ou la dernière actualisation de l’abonnement.
# Configuration de l'authentification IAM pour les connexions de réplication logiques
À partir des versions 11 et supérieures de RDS pour PostgreSQL, vous pouvez Gestion des identités et des accès AWS utiliser l'authentification (IAM) pour les connexions de réplication. Cette fonctionnalité améliore la sécurité en vous permettant de gérer l'accès à la base de données à l'aide de rôles IAM plutôt que de mots de passe. Elle fonctionne à la fois au niveau de la granularité du cluster et de l'instance et suit le même modèle de sécurité que l'authentification IAM standard.
L'authentification IAM pour les connexions de réplication est une fonctionnalité optionnelle. Pour l'activer, définissez le `rds.iam_auth_for_replication` paramètre sur 1 dans votre cluster de base de données ou votre groupe de paramètres de base de données. Comme il s'agit d'un paramètre dynamique, votre cluster ou instance de base de données n'a pas besoin de redémarrer, ce qui vous permet de tirer parti de l'authentification IAM avec les charges de travail existantes sans interruption de service. Avant d'activer cette fonctionnalité, vous devez remplir les conditions requises répertoriées ci-dessous.
**Topics**
+ [
## Prérequis
](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites)
+ [
## Activation de l'authentification IAM pour les connexions de réplication
](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Enabling)
+ [
## Désactivation de l'authentification IAM pour les connexions de réplication
](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Disabling)
+ [
## Limites et considérations
](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Limitations)
## Prérequis
Pour utiliser l'authentification IAM pour les connexions de réplication, vous devez satisfaire à toutes les exigences suivantes :
+ Votre instance de base de données RDS pour PostgreSQL doit être de version 11 ou ultérieure.
+ Sur votre instance de base de données RDS pour PostgreSQL de votre éditeur :
+ Activez l'authentification de base de données IAM. Pour de plus amples informations, veuillez consulter [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
+ Activez la réplication logique en définissant le `rds.logical_replication` paramètre sur 1.
Dans la réplication logique, l'éditeur est la base de données RDS source pour PostgreSQL qui envoie les données à la base de données des abonnés. Pour de plus amples informations, veuillez consulter [Réplication logique pour Amazon RDS pour PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md).
**Note**
L'authentification IAM et la réplication logique doivent être activées sur l'instance de base de données RDS pour PostgreSQL de votre éditeur. Si l'une ou l'autre n'est pas activée, vous ne pouvez pas utiliser l'authentification IAM pour les connexions de réplication.
## Activation de l'authentification IAM pour les connexions de réplication
Procédez comme suit pour activer l'authentification IAM pour la connexion de réplication.
**Pour activer l'authentification IAM pour les connexions de réplication**
1. Vérifiez que votre cluster ou instance de base de données RDS pour PostgreSQL répond à toutes les conditions requises pour l'authentification IAM avec des connexions de réplication. Pour en savoir plus, consultez [Prérequis](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites).
1. Configurez le `rds.iam_auth_for_replication` paramètre en fonction de votre configuration de RDS pour PostgreSQL :
+ Pour les instances de base de données RDS pour PostgreSQL : modifiez votre groupe de paramètres de base de données.
+ Pour les clusters multi-AZ : modifiez le groupe de paramètres de votre cluster de base de données.
`rds.iam_auth_for_replication`Réglé sur 1. Il s'agit d'un paramètre dynamique qui prend effet immédiatement sans nécessiter de redémarrage.
**Note**
Les clusters multi-AZ utilisent uniquement des groupes de paramètres de cluster de base de données. Les groupes de paramètres d'instance individuels ne peuvent pas être modifiés dans les clusters multi-AZ.
1. Connectez-vous à votre base de données et accordez les rôles nécessaires à votre utilisateur de réplication :
Les commandes SQL suivantes octroient les rôles nécessaires pour activer l'authentification IAM pour les connexions de réplication :
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
Après avoir effectué ces étapes, l'utilisateur spécifié doit utiliser l'authentification IAM pour les connexions de réplication.
**Important**
Lorsque vous activez cette fonctionnalité, les utilisateurs possédant à la fois des `rds_replication` rôles `rds_iam` et des rôles doivent utiliser l'authentification IAM pour les connexions de réplication. Cela s'applique que les rôles soient attribués directement à l'utilisateur ou hérités par le biais d'autres rôles.
## Désactivation de l'authentification IAM pour les connexions de réplication
Vous pouvez désactiver l'authentification IAM pour les connexions de réplication en utilisant l'une des méthodes suivantes :
+ Définissez le `rds.iam_auth_for_replication` paramètre sur 0 dans votre groupe de paramètres de base de données pour les instances de base de données ou dans le groupe de paramètres de cluster de base de données pour les clusters multi-AZ.
+ Vous pouvez également désactiver l'une de ces fonctionnalités sur votre cluster ou instance de base de données RDS pour PostgreSQL :
+ Désactivez la réplication logique en définissant le `rds.logical_replication` paramètre sur 0
+ Désactiver l'authentification IAM
Lorsque vous désactivez cette fonctionnalité, les connexions de réplication peuvent utiliser des mots de passe de base de données pour l'authentification.
**Note**
Les connexions de réplication pour les utilisateurs n'ayant pas le `rds_iam` rôle peuvent utiliser l'authentification par mot de passe même lorsque la fonctionnalité est activée.
## Limites et considérations
Tenez compte des limites et considérations suivantes lors de l'utilisation de l'authentification IAM pour les connexions de réplication logiques :
+ Cette fonctionnalité n'est disponible que pour les versions 11 et supérieures de RDS pour PostgreSQL.
+ L'éditeur doit prendre en charge l'authentification IAM pour les connexions de réplication.
+ Le jeton d'authentification IAM expire au bout de 15 minutes par défaut. Il se peut que vous deviez actualiser les connexions de réplication de longue durée avant l'expiration du jeton.
# Disque RAM pour le stats\$1temp\$1directory
Vous pouvez utiliser le paramètre RDS pour PostgreSQL `rds.pg_stat_ramdisk_size` pour spécifier la mémoire système allouée à un disque RAM afin de stocker le code PostgreSQL `stats_temp_directory`. Le paramètre de disque RAM est disponible uniquement dans RDS pour PostgreSQL version 14 et les versions antérieures.
Dans le cadre de certaines charges de travail, la définition de ce paramètre peut améliorer les performances et réduire les I/O exigences. Pour plus d’informations sur le paramètre `stats_temp_directory`, consultez la [documentation sur PostgreSQL](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY).
Pour activer un disque RAM pour votre `stats_temp_directory`, définissez le paramètre `rds.pg_stat_ramdisk_size` sur une valeur littérale entière dans le groupe de paramètres utilisé par votre instance de base de données. Ce paramètre est indiqué en Mo, vous devez donc utiliser une valeur entière. Les expressions, formules et fonctions ne sont pas valides pour le paramètre `rds.pg_stat_ramdisk_size`. Veillez à réinitialiser l'instance de base de données pour que la modification prenne effet. Pour plus d’informations sur la définition des paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Par exemple, la AWS CLI commande suivante définit le paramètre du disque RAM sur 256 Mo.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name pg-95-ramdisk-testing \
--parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot"
```
Après le redémarrage, exécutez la commande suivante pour afficher le statut de `stats_temp_directory`.
```
postgres=> SHOW stats_temp_directory;
```
La commande devrait renvoyer le résultat suivant.
```
stats_temp_directory
---------------------------
/rdsdbramdisk/pg_stat_tmp
(1 row)
```
# Espaces de table pour RDS for PostgreSQL
RDS for PostgreSQL prend en charge les espaces de table à des fins de compatibilité. Comme tout le stockage se trouve sur un seul volume logique, vous ne pouvez pas utiliser de tablespaces pour le I/O fractionner ou l'isoler. Nos évaluations et notre expérience indiquent qu'un seul volume logique constitue la meilleure configuration dans la plupart des cas d'utilisation.
Pour créer et utiliser des espaces de table avec votre instance de base de données RDS for PostgreSQL, vous avez besoin du rôle `rds_superuser`. Le compte utilisateur principal de votre instance de base de données RDS for PostgreSQL (par défaut, `postgres`) est membre de ce rôle. Pour de plus amples informations, veuillez consulter [Comprendre les rôles et les autorisations PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Si vous spécifiez un nom de fichier lors de la création d'un espace de table, le préfixe du chemin est `/rdsdbdata/db/base/tablespace`. L'exemple suivant montre comment placer les fichiers d'espace de table dans `/rdsdbdata/db/base/tablespace/data`. Cet exemple suppose qu'un utilisateur `dbadmin` (rôle) existe et qu'il se soit vu accorder le rôle `rds_superuser` nécessaire à l'utilisateur des espaces de table.
```
postgres=> CREATE TABLESPACE act_data
OWNER dbadmin
LOCATION '/data';
CREATE TABLESPACE
```
Pour en savoir plus sur les espaces de table PostgreSQL, veuillez consulter [Tablespaces](https://www.postgresql.org/docs/current/manage-ag-tablespaces.html) dans la documentation PostgreSQL.
# Classements RDS pour PostgreSQL pour EBCDIC et autres migrations mainframe.
Les versions 10 et ultérieures de RDS pour PostgreSQL comprennent la version 60.2 d'ICU, qui est basée sur Unicode 10.0 et inclut les classements du référentiel de données localisées commun d'Unicode, CLDR 32. Ces bibliothèques d'internationalisation logicielle garantissent que les codages de caractères sont présentés de manière cohérente, quel que soit le système d'exploitation ou la plateforme. Pour obtenir plus d'informations sur le CLDR-32 d'Unicode, consultez la section [CLDR 32 Release Note](https://cldr.unicode.org/index/downloads/cldr-32) (Note de mise à jour du CLDR 32) sur le site Web du CLDR d'Unicode. Vous pouvez en savoir plus sur les composants d'internationalisation pour Unicode (ICU) sur le site Web du [comité technique ICU (ICU-TC)](https://icu.unicode.org/home). Pour plus d'informations sur ICU-60, consultez la section [Download ICU 60](https://icu.unicode.org/download/60) (Télécharger ICU 60).
À partir de la version 14.3, RDS pour PostgreSQL inclut également des classements qui facilitent l'intégration des données et la conversion des systèmes basés sur EBCDIC. Le code d'échange décimal codé binaire étendu ou *EBCDIC* est couramment utilisé par les systèmes d'exploitation mainframe. Ces classements fournis par Amazon RDS sont étroitement définis pour trier uniquement les caractères Unicode qui correspondent directement aux pages de code EBCDIC. Les caractères sont triés dans l'ordre des points de code EBCDIC pour permettre la validation des données après la conversion. Ces classements ne comprennent pas les formes dénormalisées, ni les caractères Unicode qui ne correspondent pas directement à un caractère de la page de code EBCDIC source.
Les mappages de caractères entre les pages de code EBCDIC et les points de code Unicode sont basées sur les tables publiées par IBM. Le jeu complet est disponible auprès d'IBM sous forme de [fichier compressé](http://download.boulder.ibm.com/ibmdl/pub/software/dw/java/cdctables.zip) à télécharger. RDS pour PostgreSQL a utilisé ces mappages avec les outils fournis par l’ICU pour créer les classements listés dans les tableaux de cette section. Les noms de classement comprennent une langue et un pays, comme l'exige l'ICU. Cependant, les pages de codes EBCDIC ne précisent pas les langues, et certaines pages de codes EBCDIC couvrent plusieurs pays. Cela signifie que les parties langue et pays des noms de classement dans la table sont arbitraires et qu'elles ne doivent pas nécessairement correspondre à la locale actuelle. En d'autres termes, le numéro de page de code est la partie la plus importante du nom du classement dans ce tableau. Vous pouvez utiliser tous les classements répertoriés dans les tableaux suivants dans n'importe quelle base de données RDS pour PostgreSQL.
+ [Unicode to EBCDIC collations table](#ebcdic-table)— Certains outils de migration des données du mainframe utilisent LATIN1 ou permettent d'encoder et LATIN9 de traiter des données en interne. Ces outils utilisent des schémas aller-retour pour préserver l'intégrité des données et prendre en charge la conversion inverse. Les classements de ce tableau peuvent être utilisés par des outils qui traitent les données à l'aide d'un LATIN1 codage, ce qui ne nécessite pas de manipulation particulière.
+ [Unicode to LATIN9 collations table](#latin9-table) : vous pouvez utiliser ces classements dans n’importe quelle base de données RDS pour PostgreSQL.
Dans le tableau suivant, vous trouverez les classements disponibles dans RDS pour PostgreSQL qui font correspondre les pages de code EBCDIC aux points de code Unicode. Nous vous recommandons d'utiliser les classements de ce tableau pour le développement d'applications qui nécessitent un classement basé sur l'ordre des pages de code IBM.
| Nom du classement PostgreSQL | Description du mappage code-page et de l'ordre de tri |
| --- | --- |
| da-DK-cp277-x-icu | Les caractères Unicode qui mappent directement à la page de code EBCDIC 277 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 277 d'IBM. |
| de-DE-cp273-x-icu | Les caractères Unicode qui mappent directement à la page de code EBCDIC 273 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 273 d'IBM. |
| en-GB-cp285-x-icu | Les caractères Unicode qui mappent directement à la page de code EBCDIC 285 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 285 d'IBM. |
| en-US-cp037-x-icu | Les caractères Unicode qui mappent directement à la page de code EBCDIC 037 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 37 d'IBM. |
| es-ES-cp284-x-icu | Les caractères Unicode qui mappent directement à la page de code EBCDIC 284 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 284 d'IBM. |
| fi-FI-cp278-x-icu | Les caractères Unicode qui mappent directement à la page de code EBCDIC 278 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 278 d'IBM. |
| fr-FR-cp297-x-icu | Les caractères Unicode qui mappent directement à la page de code EBCDIC 297 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 297 d'IBM. |
| it-IT-cp280-x-icu | Les caractères Unicode qui mappent directement à la page de code EBCDIC 280 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 280 d'IBM. |
| nl-BE-cp500-x-icu | Les caractères Unicode qui mappent directement à la page de code EBCDIC 500 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 500 d'IBM. |
Amazon RDS fournit un ensemble de classements supplémentaires qui trient les points de code Unicode associés à des LATIN9 caractères à l'aide des tables publiées par IBM, dans l'ordre des points de code d'origine conformément à la page de code EBCDIC des données sources.
| Nom du classement PostgreSQL | Description du mappage code-page et de l'ordre de tri |
| --- | --- |
| DA-DK-CP1142 m-x-icu | Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de code IBM EBCDIC 1142 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1142 |
| DE-DE-CP1141 m-x-icu | Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de code IBM EBCDIC 1141 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1141 |
| FR-GB-CP1146 m-x-icu | Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de code IBM EBCDIC 1146 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1146 |
| EN-US-CP1140 m-x-icu | Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de code IBM EBCDIC 1140 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1140 |
| ES-ES-CP1145 m-x-icu | Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de code IBM EBCDIC 1145 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1145 |
| fi-Fi-CP1143 m-x-icu | Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de code IBM EBCDIC 1143 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1143 |
| FR-FR-CP1147 m-x-icu | Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de code IBM EBCDIC 1147 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1147 |
| IT-IT-CP1144 m-x-icu | Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de code IBM EBCDIC 1144 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1144 |
| NL-BE-CP1148 m-x-icu | Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de code IBM EBCDIC 1148 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1148 |
Dans ce qui suit, vous trouverez un exemple d'utilisation d'un classement RDS pour PostgreSQL.
```
db1=> SELECT pg_import_system_collations('pg_catalog');
pg_import_system_collations
-----------------------------
36
db1=> SELECT '¤' < 'a' col1;
col1
------
t
db1=> SELECT '¤' < 'a' COLLATE "da-DK-cp277-x-icu" col1;
col1
------
f
```
Nous vous recommandons d'utiliser les classements dans le [Unicode to EBCDIC collations table](#ebcdic-table) et [Unicode to LATIN9 collations table](#latin9-table) pour le développement d'applications qui nécessitent un classement basé sur l'ordre des pages de code IBM. Les classements suivants (suffixés par la lettre « b ») sont également visibles dans les outils d'intégration et de migration de données du mainframe`pg_collation`, mais ils sont destinés à être utilisés par ces outils pour cartographier des pages de code AWS présentant des décalages de points de code spécifiques et nécessitant un traitement spécial lors du classement. En d'autres termes, l'utilisation des classements suivants n'est pas recommandée.
+ DA-DK-277 b-x-icu
+ DA-DK-1142 b-x-icu
+ DE-DE-CP273 b-x-icu
+ DE-DE-CP1141 b-x-icu
+ FR-GB-CP1146 b-x-icu
+ FR-GB-CP285 b-x-icu
+ en-US-CP037 b-x-icu
+ EN-US-CP1140 b-x-icu
+ ES-ES-CP1145 b-x-icu
+ ES-ES-CP284 b-x-icu
+ fi-Fi-CP1143 b-x-icu
+ FR-FR-CP1147 b-x-icu
+ FR-FR-CP297 b-x-icu
+ IT-IT-CP1144 b-x-icu
+ IT-IT-CP280 b-x-icu
+ NL-BE-CP1148 b-x-icu
+ NL-BE-CP500 b-x-icu
Pour en savoir plus sur la migration d'applications depuis des environnements mainframe vers des environnements mainframe AWS, voir [Qu'est-ce que la modernisation des AWS mainframes ?](https://docs.aws.amazon.com/m2/latest/userguide/what-is-m2.html) .
Pour plus d’informations sur la gestion des classements dans PostgreSQL, consultez [Collation Support](https://www.postgresql.org/docs/current/collation.html) (Prise en charge des classements) dans la documentation de PostgreSQL.
# Gestion de la synchronisation des emplacements logiques pour RDS pour PostgreSQL
Depuis la version communautaire de PostgreSQL 17, une nouvelle fonctionnalité permettant de synchroniser automatiquement les emplacements de réplication logiques entre les serveurs principaux et les serveurs de secours a été introduite via le paramètre `sync_replication_slots` ou la fonction `pg_sync_replication_slots()` associée, qui synchronise manuellement les emplacements lors de l’exécution.
Ces fonctionnalités sont disponibles à partir de RDS pour PostgreSQL 17. Une configuration typique comporte une instance principale et son [réplica en lecture](USER_PostgreSQL.Replication.ReadReplicas.md), ainsi qu’un abonné de réplication logique à l’instance principale.
Assurez-vous que l’abonnement est créé avec l’option de basculement définie sur true :
```
CREATE SUBSCRIPTION subname CONNECTION 'host=...' PUBLICATION pubname WITH (failover = true);
```
Cela crée un emplacement logique sur le diffuseur de publication avec le basculement activé.
```
postgres=> SELECT slot_name, slot_type, failover FROM pg_catalog.pg_replication_slots;
slot_name | slot_type | failover
-----------+-----------+----------
subname | logical | t
(1 row)
```
En activant la synchronisation des emplacements, tous les emplacements de réplication logiques de basculement sur l’instance principale sont automatiquement créés sur les instances de secours physiques et sont synchronisés périodiquement. Assurez-vous que les valeurs suivantes ont été définies par le biais de [groupes de paramètres](USER_WorkingWithParamGroups.Associating.md) :
+ `rds.logical_replication` doit être égal à `1` pour activer la réplication logique
+ `hot_standby_feedback` doit être égal à `1` sur l’instance de secours
+ `rds.logical_slot_sync_dbname` sur l’instance de secours doit être défini sur un nom de base de données valide
La valeur par défaut du paramètre est `postgres`. Si l’instance de publication logique possède la base de données `postgres`, il n’est pas nécessaire de modifier le paramètre par défaut.
+ `synchronized_standby_slots` sur l’instance principale doit être réglé sur l’emplacement de réplication physique de l’instance de secours destinée à être synchronisée
+ `sync_replication_slots` doit être égal à `1` pour activer la synchronisation automatique
Avec un emplacement d’abonnement activé par le basculement et les valeurs de paramètres ci-dessus, lorsqu’une instance de secours est promue, l’abonné peut modifier son abonnement à cette instance nouvellement promue et poursuivre la réplication logique de manière fluide.
# Connexion à une instance de base de données exécutant le moteur de base de données PostgreSQL
Après qu'Amazon RDS a provisionné votre instance de base de données, vous pouvez utiliser n'importe quelle application cliente SQL standard pour vous connecter à l'instance. Avant de pouvoir vous connecter, l'instance de base de données doit être disponible et accessible. La méthode utilisée pour créer l'instance de base de données Amazon RDS détermine s'il est possible ou non de vous y connecter depuis l'extérieur du VPC :
+ Si vous avez créé votre instance de base de données comme étant *publique*, les appareils et les instances Amazon EC2 extérieurs au VPC peuvent se connecter à votre base de données.
+ Si vous avez créé votre instance de base de données comme étant *privée*, seuls les appareils et instances Amazon EC2 à l'intérieur du VPC peuvent se connecter à votre base de données.
Pour vérifier si votre instance de base de données est publique ou privée, utilisez l' AWS Management Console onglet **Connectivité et sécurité** pour votre instance. Sous **Security** (Sécurité), vous pouvez trouver la valeur « Publicly accessible (Accessible publiquement) », avec No (Non) pour privé, Yes (Oui) pour public.
Pour en savoir plus sur les différentes configurations Amazon RDS et Amazon VPC, et comment elles affectent l'accessibilité, consultez [Scénarios d’accès à une instance de base de données d’un VPC](USER_VPC.Scenarios.md).
**Contents**
+ [
## Installation du client psql
](#install-psql)
+ [
## Recherche des informations de connexion pour une instance de base de données RDS pour PostgreSQL
](#postgresql-endpoint)
+ [
# Utilisation de pgAdmin pour se connecter à une instance de base de données RDS pour PostgreSQL
](USER_ConnectToPostgreSQLInstance.pgAdmin.md)
+ [
# Utilisation de psql pour connecter votre RDS à votre instance de base de données PostgreSQL
](USER_ConnectToPostgreSQLInstance.psql.md)
+ [
# Connexion à RDS pour PostgreSQL avec le pilote JDBC Amazon Web Services (AWS)
](PostgreSQL.Connecting.JDBCDriver.md)
+ [
# Connexion à RDS pour PostgreSQL avec le pilote Python Amazon Web Services (AWS)
](PostgreSQL.Connecting.PythonDriver.md)
+ [
# Résolution des problèmes de connexion à votre instance RDS pour PostgreSQL
](USER_ConnectToPostgreSQLInstance.Troubleshooting.md)
+ [
## Erreur – IRRÉCUPÉRABLE : le nom de la base de données *name* n'existe pas
](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-DBname)
+ [
## Erreur – Impossible de se connecter au serveur : la connexion a expiré
](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-timeout)
+ [
## Erreurs liées aux règles d'accès du groupe de sécurité
](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules)
## Installation du client psql
Pour vous connecter à votre instance de base de données à partir d'une instance EC2, vous pouvez installer un client PostgreSQL sur l'instance EC2. Pour installer la dernière version du client psql sur Amazon Linux 2023, exécutez la commande suivante :
```
sudo dnf install postgresql
```
Pour installer la dernière version du client psql sur Amazon Linux 2, exécutez la commande suivante :
```
sudo yum install -y postgresql
```
Pour installer la dernière version du client psql sur Ubuntu, exécutez la commande suivante :
```
sudo apt install -y postgresql-client
```
## Recherche des informations de connexion pour une instance de base de données RDS pour PostgreSQL
Si l'instance de base de données est disponible et accessible, vous pouvez vous connecter en fournissant les informations suivantes à l'application cliente SQL :
+ Point de terminaison de l'instance de base de données servant de nom d'hôte (nom DNS) pour l'instance.
+ Le port au niveau duquel l'instance de base de données écoute. Le port par défaut pour PostgreSQL est 5432.
+ Le nom d'utilisateur et le mot de passe de l'instance de base de données. Le « nom d'utilisateur principal » par défaut pour PostgreSQL est `postgres`.
+ Nom et mot de passe de la base de données (Nom de base de données).
Vous pouvez obtenir ces informations à l'aide de la AWS Management Console AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)commande ou de l'DBInstancesopération Amazon RDS API [Describe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html).
**Pour trouver le point de terminaison, le numéro de port et le nom de la base de données à l'aide du AWS Management Console**
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. Ouvrez la console RDS et choisissez **Bases de données** pour afficher une liste de vos instances de bases de données.
1. Choisissez le nom de l'instance de base de données PostgreSQL pour afficher ses détails.
1. Dans l'onglet **Connectivity & security (Connectivité et sécurité)**, copiez le point de terminaison. Notez également le numéro du port. Vous avez besoin du point de terminaison et du numéro de port pour vous connecter à l'instance de base de données.
![\[Obtenir le point de terminaison à partir de la console RDS\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/PostgreSQL-endpoint.png)
1. Sous l'onglet **Configuration**, indiquez le nom de la base de données. Si vous avez créé une base de données lors de la création de l’instance RDS pour PostgreSQL, le nom apparaît sous « Nom de base de données ». Si vous n'avez pas créé de base de données, le nom de la base de données est remplacé par un tiret (‐).
![\[Obtenir le nom de la base de données à partir de la console RDS\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/PostgreSQL-db-name.png)
Voici deux façons de se connecter à une instance de base de données PostgreSQL. Le premier exemple utilise pgAdmin, célèbre outil open source d'administration et de développement pour PostgreSQL. Le second exemple utilise psql, utilitaire de ligne de commande qui fait partie d'une installation PostgreSQL.
# Utilisation de pgAdmin pour se connecter à une instance de base de données RDS pour PostgreSQL
Vous pouvez utiliser l’outil open source pgAdmin pour vous connecter à votre instance de base de données RDS pour PostgreSQL. Vous pouvez télécharger et utiliser pgAdmin à partir de l'adresse [http://www.pgadmin.org/](http://www.pgadmin.org/) sans disposer d'une instance locale de PostgreSQL sur votre ordinateur client.
**Pour vous connecter à votre instance de base de données RDS pour PostgreSQL à l’aide de pgAdmin**
1. Lancez l’application pgAdmin sur votre ordinateur client.
1. Dans l'onglet **Tableau de bord**, choisissez **Add New Server (Ajouter un nouveau serveur)**.
1. Dans la boîte de dialogue **Create - Server (Créer - Serveur)**, entrez un nom sur l'onglet **Général** pour identifier le serveur dans pgAdmin.
1. Dans l'onglet **Connexion**, tapez les informations suivantes depuis votre instance de base de données :
+ Pour **Hôte**, tapez le point de terminaison, par exemple `mypostgresql.c6c8dntfzzhgv0.us-east-2.rds.amazonaws.com`.
+ Pour **Port**, tapez le port attribué.
+ Dans le champ **Nom d'utilisateur**, saisissez le nom d'utilisateur indiqué lors de la création de l'instance de base de données (si vous avez modifié le « nom d'utilisateur principal » par défaut, `postgres`).
+ Pour **Mot de passe**, tapez le mot de passe entré lors de la création de l'instance de base de données.
![\[Tapez le mot de passe entré lors de la création de l’instance de base de données.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/Postgres-Connect01.png)
1. Choisissez **Enregistrer**.
Si vous rencontrez des problèmes de connexion, consultez [Résolution des problèmes de connexion à votre instance RDS pour PostgreSQL](USER_ConnectToPostgreSQLInstance.Troubleshooting.md).
1. Pour accéder à la base de données dans le navigateur pgAdmin, développez **Serveurs**, l'instance de base de données et **Bases de données**. Choisissez le nom de la base de données de l'instance de base de données.
![\[Choisissez le nom de la base de données de l’instance de base de données dans le navigateur pgAdmin.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/Postgres-Connect02.png)
1. Pour ouvrir un panneau dans lequel vous pouvez entrer des commandes SQL, choisissez **Outils**, **Query Tool (Outil de requête)**.
# Utilisation de psql pour connecter votre RDS à votre instance de base de données PostgreSQL
Vous pouvez utiliser une instance locale de l'utilitaire de ligne de commande psql pour vous connecter à une instance de base de données RDS for PostgreSQL. Vous devez avoir installé PostgreSQL ou le client psql sur votre ordinateur client.
Vous pouvez télécharger le client PostgreSQL depuis le site Web de [PostgreSQL](https://www.postgresql.org/download/). Pour installer psql, suivez les instructions spécifiques à votre version du système d'exploitation.
Pour vous connecter à votre instance de base de données RDS for PostgreSQL, vous devez fournir les informations sur l'hôte (DNS), les informations d'identification de l'accès et le nom de la base de données.
Utilisez l'un des formats suivants pour vous connecter à votre instance de base de données RDS for PostgreSQL. Lorsque vous vous connectez, vous êtes invité à entrer un mot de passe. Pour les tâches de traitement par lots ou les scripts, utilisez l'option `--no-password`. Cette option est définie pour l'ensemble de la session.
**Note**
Une tentative de connexion avec `--no-password` échoue lorsque le serveur exige une authentification par mot de passe et qu'aucun mot de passe n'est disponible auprès d'autres sources. Pour plus d'informations, consultez la [documentation de psql](https://www.postgresql.org/docs/13/app-psql.html).
Si vous vous connectez à cette instance de base de données pour la première fois ou si vous n'avez pas encore créé de base de données pour cette instance RDS for PostgreSQL, vous pouvez vous connecter à la base de données **postgres** à l'aide du « nom d'utilisateur principal » et du mot de passe.
Pour Unix, utilisez le format suivant.
```
psql \
--host= \
--port= \
--username= \
--password \
--dbname=
```
Pour Windows, utilisez le format suivant.
```
psql ^
--host= ^
--port= ^
--username= ^
--password ^
--dbname=
```
Par exemple, la commande suivante se connecte à une base de données appelée `mypgdb` sur une instance de base de données PostgreSQL appelée `mypostgresql` à l'aide d'informations d'identification fictives.
```
psql --host=mypostgresql.c6c8mwvfdgv0.us-west-2.rds.amazonaws.com --port=5432 --username=awsuser --password --dbname=mypgdb
```
# Connexion à RDS pour PostgreSQL avec le pilote JDBC Amazon Web Services (AWS)
Le pilote JDBC Amazon Web Services (AWS) est conçu comme un wrapper JDBC avancé. Ce wrapper complète et étend les fonctionnalités d’un pilote JDBC existant. Le pilote est compatible avec le pilote communautaire pgJDBC.
Pour installer le pilote AWS JDBC, ajoutez le fichier .jar du pilote AWS JDBC (situé dans l'application`CLASSPATH`) et conservez les références au pilote communautaire correspondant. Mettez à jour le préfixe d’URL de connexion correspondant comme suit :
+ `jdbc:postgresql://` sur `jdbc:aws-wrapper:postgresql://`
Pour plus d'informations sur le pilote AWS JDBC et des instructions complètes pour son utilisation, consultez le référentiel de pilotes [JDBC Amazon Web Services (AWS)](https://github.com/awslabs/aws-advanced-jdbc-wrapper). GitHub
# Connexion à RDS pour PostgreSQL avec le pilote Python Amazon Web Services (AWS)
Le pilote Python Amazon Web Services (AWS) est conçu comme un wrapper Python avancé. Ce wrapper complète et étend les fonctionnalités du pilote open source Psycopg. Le pilote AWS Python prend en charge les versions 3.8 et ultérieures de Python. Vous pouvez installer le package `aws-advanced-python-wrapper` à l’aide de la commande `pip`, en même temps que les packages `psycopg` open source.
Pour plus d'informations sur le pilote AWS Python et des instructions complètes pour son utilisation, consultez le [ GitHub référentiel de pilotes Python Amazon Web Services (AWS)](https://github.com/awslabs/aws-advanced-python-wrapper).
# Résolution des problèmes de connexion à votre instance RDS pour PostgreSQL
**Topics**
+ [
## Erreur – IRRÉCUPÉRABLE : le nom de la base de données *name* n'existe pas
](#USER_ConnectToPostgreSQLInstance.Troubleshooting-DBname)
+ [
## Erreur – Impossible de se connecter au serveur : la connexion a expiré
](#USER_ConnectToPostgreSQLInstance.Troubleshooting-timeout)
+ [
## Erreurs liées aux règles d'accès du groupe de sécurité
](#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules)
## Erreur – IRRÉCUPÉRABLE : le nom de la base de données *name* n'existe pas
Si vous recevez une erreur telle que `FATAL: database name does not exist` lorsque vous tentez de vous connecter, essayez d'utiliser le nom par défaut de la base de données **postgres** pour l'option `--dbname`.
## Erreur – Impossible de se connecter au serveur : la connexion a expiré
Si vous ne parvenez pas à vous connecter à l'instance de base de données, l'erreur la plus courante est `Could not connect to server: Connection timed out.` Si vous recevez cette erreur, procédez comme suit :
+ Vérifiez que le nom d'hôte utilisé est le point de terminaison de l'instance de base de données et que le numéro de port utilisé est correct.
+ Assurez-vous que l'accessibilité publique de l'instance de base de données est définie sur **Oui** pour autoriser les connexions externes. Pour modifier le paramètre **Accès public**, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
+ Assurez-vous que l'utilisateur qui se connecte à la base de données dispose d'un accès CONNECT à celle-ci. Vous pouvez utiliser la requête suivante pour fournir un accès de connexion à la base de données.
```
GRANT CONNECT ON DATABASE database name TO username;
```
+ Vérifiez que le groupe de sécurité affecté à l'instance de base de données possède les règles pour autoriser l'accès via tout pare-feu que votre connexion peut traverser. Par exemple, si l'instance de base de données a été créée à l'aide du port par défaut 5432, votre entreprise peut disposer de règles de pare-feu bloquant les connexions à ce port depuis les appareils externes à l'entreprise.
Pour résoudre ce problème, modifiez l'instance de base de données afin qu'elle utilise un autre port. De plus, assurez-vous que les groupes de sécurité appliqués à l'instance de base de données autorisent les connexions au nouveau port. Pour modifier le paramètre **Port de la base de données**, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
+ Vérifiez si le port que vous essayez d’utiliser est déjà occupé par une instance locale de PostgreSQL ou par un autre service exécuté sur votre ordinateur. Par exemple, si une base de données PostgreSQL locale s’exécute sur le même port (la valeur par défaut est 5432), cela peut faire échouer la connexion à l’instance de base de données RDS pour PostgreSQL. Assurez-vous que le port est libre ou essayez de vous connecter avec un autre numéro de port si possible.
+ Consultez également [Erreurs liées aux règles d'accès du groupe de sécurité](#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules).
## Erreurs liées aux règles d'accès du groupe de sécurité
Le problème de connexion qui intervient le plus fréquemment concerne les règles d'accès du groupe de sécurité assigné à l'instance de base de données. Si vous avez utilisé le groupe de sécurité par défaut lorsque vous avez créé l'instance de base de données, ce groupe de sécurité ne dispose vraisemblablement pas de règles d'accès vous autorisant à accéder à l'instance.
Pour que la connexion s'établisse, le groupe de sécurité que vous avez assigné à l'instance de base de données à sa création doit autoriser l'accès à l'instance de base de données. Par exemple, si l'instance de base de données a été créée à l'intérieur d'un VPC, elle doit avoir un groupe de sécurité VPC qui autorise les connexions. Déterminez si l'instance de base de données a été créée à l'aide d'un groupe de sécurité qui interdit les connexions depuis l'appareil ou l'instance Amazon EC2 où l'application s'exécute.
Vous pouvez ajouter ou modifier une règle entrante dans le groupe de sécurité. La sélection de **Mon IP** comme **Source** permet d'accéder à l'instance de base de données à partir de l'adresse IP détectée dans votre navigateur. Pour plus d'informations, consultez [Créer un groupe de sécurité qui autorise l'accès à votre instance de base de données dans votre VPC](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup).
Sinon, si l'instance de base de données a été créée à l'extérieur d'un VPC, elle doit avoir un groupe de sécurité de bases de données qui autorise ces connexions.
Pour plus d’informations sur les groupes de sécurité Amazon RDS, consultez [Contrôle d’accès par groupe de sécurité](Overview.RDSSecurityGroups.md).
# Sécurisation des connexions à RDS pour PostgreSQL avec SSL/TLS
RDS for PostgreSQL prend en charge le chiffrement au moyen du protocole SSL pour les instances de bases de données PostgreSQL. En utilisant SSL, vous pouvez chiffrer une connexion PostgreSQL entre vos applications et vos instances de bases de données PostgreSQL. Vous pouvez également forcer toutes les connexions à votre instance de base de données PostgreSQL à utiliser SSL. RDS for PostgreSQL prend également en charge le protocole TLS (Transport Layer Security), le protocole qui succède à SSL.
Pour en savoir plus sur Amazon RDS et la protection des données, y compris le chiffrement des connexions à l'aide de SSL/TLS, veuillez consulter [Protection des données dans Amazon RDS](DataDurability.md).
**Topics**
+ [
# Utilisation de SSL avec une instance de base de données PostgreSQL
](PostgreSQL.Concepts.General.SSL.md)
+ [
# Mise à jour des applications pour se connecter aux instances de base de données PostgreSQL à l'aide de nouveaux certificats SSL/TLS
](ssl-certificate-rotation-postgresql.md)
# Utilisation de SSL avec une instance de base de données PostgreSQL
Amazon RDS prend en charge le chiffrement SSL pour les instances de bases de données PostgreSQL. En utilisant SSL, vous pouvez chiffrer une connexion PostgreSQL entre vos applications et vos instances de bases de données PostgreSQL. Par défaut, RDS pour PostgreSQL utilise et attend de tous les clients qu’ils se connectent en utilisant SSL/TLS, mais vous pouvez également l’exiger. RDS pour PostgreSQL prend en charge le protocole TLS (Transport Layer Security) versions 1.1, 1.2 et 1.3.
Pour obtenir des informations générales sur la prise en charge de SSL et les bases de données PostgreSQL, consultez [SSL Support](https://www.postgresql.org/docs/11/libpq-ssl.html) dans la documentation PostgreSQL. Pour plus d’informations sur l’utilisation d’une connexion SSL sur JDBC, consultez [Configuring the Client](https://jdbc.postgresql.org/documentation/head/ssl-client.html) dans la documentation PostgreSQL.
Le support SSL est disponible dans toutes les AWS régions pour PostgreSQL. Amazon RDS crée un certificat SSL pour votre instance de base de données PostgreSQL lors de la création de celle-ci. Si vous activez la vérification du certificat SSL, ce dernier inclut le point de terminaison de l'instance de base de données en tant que nom commun du certificat SSL pour assurer une protection contre les attaques par usurpation.
**Topics**
+ [
## Connexion à une instance de base de données PostgreSQL via SSL
](#PostgreSQL.Concepts.General.SSL.Connecting)
+ [
## Exiger une connexion SSL à une instance de base de données PostgreSQL
](#PostgreSQL.Concepts.General.SSL.Requiring)
+ [
## Détermination du statut de la connexion SSL
](#PostgreSQL.Concepts.General.SSL.Status)
+ [
## Suites de chiffrement SSL dans RDS pour PostgreSQL
](#PostgreSQL.Concepts.General.SSL.Ciphers)
## Connexion à une instance de base de données PostgreSQL via SSL
**Pour se connecter à une instance de base de données PostgreSQL via SSL**
1. Téléchargez le certificat.
Pour plus d’informations sur le téléchargement de certificats, consultez [](UsingWithRDS.SSL.md).
1. Connectez-vous à votre instance de base de données PostgreSQL sur SSL.
Lors de la connexion avec SSL, votre client peut choisir de vérifier ou pas la chaîne du certificat. Si vos paramètres de connexion spécifient `sslmode=verify-ca` ou `sslmode=verify-full`, votre client nécessite que les certificats de l'autorité de certification RDS soient dans leur magasin d'approbations ou référencés dans l'URL de connexion. L'exigence nécessite de vérifier la chaîne du certificat qui signe le certificat de votre base de données.
Quand un client, tel que psql ou JDBC, est configuré avec la prise en charge du protocole SSL, le comportement par défaut est le suivant : le client essaie d'abord de se connecter à la base de données avec le protocole SSL. En cas d'impossibilité, le client revient à la connexion sans protocole SSL. Le mode `sslmode` utilisé par défaut diffère selon qu'il s'agit de clients libpq (comme psql) ou de clients JDBC. Les clients basés sur libpq et JDBC sont basés sur `prefer` par défaut.
Utilisez le paramètre `sslrootcert` pour référencer le certificat, par exemple, `sslrootcert=rds-ssl-ca-cert.pem`.
L'exemple suivant montre comment utiliser `psql` pour se connecter à une instance de base de données PostgreSQL en utilisant SSL avec vérification du certificat.
```
$ psql "host=db-name.555555555555.ap-southeast-1.rds.amazonaws.com
port=5432 dbname=testDB user=testuser sslrootcert=rds-ca-rsa2048-g1.pem sslmode=verify-full"
```
## Exiger une connexion SSL à une instance de base de données PostgreSQL
Vous pouvez exiger que les connexions à votre instance de base de données PostgreSQL utilisent SSL en utilisant le paramètre `rds.force_ssl`. La valeur par défaut du paramètre `rds.force_ssl` est définie sur 1 (activé) pour RDS pour PostgreSQL versions 15 et ultérieures. Pour les autres versions majeures 14 et antérieures de RDS pour PostgreSQL, la valeur par défaut de ce paramètre est 0 (désactivé). Vous pouvez définir le `rds.force_ssl` paramètre sur 1 (activé) SSL/TLS pour exiger les connexions à votre cluster de bases de données. Vous pouvez affecter au paramètre `rds.force_ssl` la valeur 1 (activé) pour exiger SSL pour les connexions à votre instance de base de données.
Pour modifier la valeur de ce paramètre, vous devez créer un groupe de paramètres de base de données personnalisé. Vous modifiez ensuite la valeur de `rds.force_ssl` dans votre groupe de paramètres de base de données personnalisé sur `1` pour activer cette fonction. Si vous préparez le groupe de paramètres de base de données personnalisé avant de créer votre instance de base de données RDS pour PostgreSQL, vous pouvez le choisir (au lieu d’un groupe de paramètres par défaut) pendant le processus de création. Si vous effectuez cette opération alors que votre instance de base de données RDS pour PostgreSQL est déjà en cours d’exécution, vous devez redémarrer l’instance pour que celle-ci utilise le groupe de paramètres personnalisés. Pour de plus amples informations, veuillez consulter [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Lorsque la fonction `rds.force_ssl` est active sur votre instance de base de données, les tentatives de connexion qui n'utilisent pas SSL sont rejetées avec le message suivant :
```
$ psql -h db-name.555555555555.ap-southeast-1.rds.amazonaws.com port=5432 dbname=testDB user=testuser
psql: error: FATAL: no pg_hba.conf entry for host "w.x.y.z", user "testuser", database "testDB", SSL off
```
## Détermination du statut de la connexion SSL
Le statut chiffré de votre connexion est affiché dans la page d'accueil d'ouverture de session lorsque vous vous connectez à l'instance de base de données :
```
Password for user master:
psql (10.3)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
postgres=>
```
Vous pouvez également charger l'extension `sslinfo`, puis appeler la fonction `ssl_is_used()` pour déterminer si SSL est utilisé. La fonction renvoie `t` si la connexion utilise SSL ; sinon, elle renvoie `f`.
```
postgres=> CREATE EXTENSION sslinfo;
CREATE EXTENSION
postgres=> SELECT ssl_is_used();
ssl_is_used
---------
t
(1 row)
```
Pour obtenir des informations plus détaillées, vous pouvez utiliser la requête suivante pour obtenir des informations via `pg_settings` :
```
SELECT name as "Parameter name", setting as value, short_desc FROM pg_settings WHERE name LIKE '%ssl%';
Parameter name | value | short_desc
----------------------------------------+-----------------------------------------+-------------------------------------------------------
ssl | on | Enables SSL connections.
ssl_ca_file | /rdsdbdata/rds-metadata/ca-cert.pem | Location of the SSL certificate authority file.
ssl_cert_file | /rdsdbdata/rds-metadata/server-cert.pem | Location of the SSL server certificate file.
ssl_ciphers | HIGH:!aNULL:!3DES | Sets the list of allowed SSL ciphers.
ssl_crl_file | | Location of the SSL certificate revocation list file.
ssl_dh_params_file | | Location of the SSL DH parameters file.
ssl_ecdh_curve | prime256v1 | Sets the curve to use for ECDH.
ssl_key_file | /rdsdbdata/rds-metadata/server-key.pem | Location of the SSL server private key file.
ssl_library | OpenSSL | Name of the SSL library.
ssl_max_protocol_version | | Sets the maximum SSL/TLS protocol version to use.
ssl_min_protocol_version | TLSv1.2 | Sets the minimum SSL/TLS protocol version to use.
ssl_passphrase_command | | Command to obtain passphrases for SSL.
ssl_passphrase_command_supports_reload | off | Also use ssl_passphrase_command during server reload.
ssl_prefer_server_ciphers | on | Give priority to server ciphersuite order.
(14 rows)
```
Vous pouvez également recueillir toutes les informations sur l’utilisation SSL de votre instance de base de données RDS pour PostgreSQL par processus, client et application en utilisant la requête suivante :
```
SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
FROM pg_stat_ssl
JOIN pg_stat_activity
ON pg_stat_ssl.pid = pg_stat_activity.pid
ORDER BY ssl;
Database name | User name | ssl | client_addr | application_name | backend_type
---------------+-----------+-----+----------------+------------------------+------------------------------
| | f | | | autovacuum launcher
| rdsadmin | f | | | logical replication launcher
| | f | | | background writer
| | f | | | checkpointer
| | f | | | walwriter
rdsadmin | rdsadmin | t | 127.0.0.1 | | client backend
rdsadmin | rdsadmin | t | 127.0.0.1 | PostgreSQL JDBC Driver | client backend
postgres | postgres | t | 204.246.162.36 | psql | client backend
(8 rows)
```
Pour identifier le chiffrage utilisé pour votre connexion SSL, vous pouvez utiliser la requête suivante :
```
postgres=> SELECT ssl_cipher();
ssl_cipher
--------------------
DHE-RSA-AES256-SHA
(1 row)
```
Pour en savoir plus sur l'option `sslmode`, consultez [Database connection control functions](https://www.postgresql.org/docs/11/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) (Fonctions de contrôle des connexions aux bases de données) dans la *documentation de PostgreSQL*.
## Suites de chiffrement SSL dans RDS pour PostgreSQL
Le paramètre de configuration PostgreSQL [ssl\$1ciphers](https://www.postgresql.org/docs/current/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SSL) précise les catégories de suites de chiffrement autorisées pour les connexions SSL vers la base de données lors de l’utilisation de TLS 1.2 et versions antérieures.
Dans RDS pour PostgreSQL 16 et versions ultérieures, vous pouvez modifier le paramètre `ssl_ciphers` pour utiliser des valeurs spécifiques issues des suites de chiffrement autorisées. Il s’agit d’un paramètre dynamique qui ne nécessite pas le redémarrage de l’instance de base de données. Pour consulter les suites de chiffrement autorisées, utilisez la console Amazon RDS ou la commande CLI AWS suivante :
```
aws rds describe-db-parameters --db-parameter-group-name --region --endpoint-url --output json | jq '.Parameters[] | select(.ParameterName == "ssl_ciphers")'
```
Le tableau suivant répertorie à la fois les suites de chiffrement par défaut et les suites de chiffrement autorisées pour les versions qui prennent en charge les configurations personnalisées.
| Version du moteur PostgreSQL | Valeurs par défaut de la suite ssl\$1cipher | Valeurs de la suite ssl\$1cipher personnalisées autorisées |
| --- | --- | --- |
| 18 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 17 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 16 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 15 | HIGH:\$1aNULL:\$13DES | ssl\$1ciphers personnalisé n’est pas pris en charge |
| 14 | HIGH:\$1aNULL:\$13DES | ssl\$1ciphers personnalisé n’est pas pris en charge |
| 13 | HIGH:\$1aNULL:\$13DES | ssl\$1ciphers personnalisé n’est pas pris en charge |
| 12 | HIGH:\$1aNULL:\$13DES | ssl\$1ciphers personnalisé n’est pas pris en charge |
| 11.4 et versions mineures ultérieures | HIGH:MEDIUM:\$13DES:\$1aNULL:\$1RC4 | ssl\$1ciphers personnalisé n’est pas pris en charge |
| 11.1, 11.2 | HIGH:MEDIUM:\$13DES:\$1aNULL | ssl\$1ciphers personnalisé n’est pas pris en charge |
| 10.9 et versions mineures ultérieures | HIGH:MEDIUM:\$13DES:\$1aNULL:\$1RC4 | ssl\$1ciphers personnalisé n’est pas pris en charge |
| 10.7 et versions mineures inférieures | HIGH:MEDIUM:\$13DES:\$1aNULL | ssl\$1ciphers personnalisé n’est pas pris en charge |
Pour configurer toutes les connexions d’instance afin d’utiliser la suite de chiffrement`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`, modifiez votre groupe de paramètres comme indiqué dans l’exemple suivant :
```
aws rds modify-db-parameter-group --db-parameter-group-name --parameters "ParameterName='ssl_ciphers',ParameterValue='TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384',ApplyMethod=immediate"
```
Cet exemple utilise un chiffrement ECDSA, qui oblige votre instance à utiliser une autorité de certification avec cryptographie à courbe elliptique (ECC) pour établir une connexion. Pour plus d’informations sur les autorités de certification fournies par Amazon RDS, consultez [Autorités de certification](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/singWithRDS.SSL.html#UsingWithRDS.SSL.RegionCertificateAuthorities).
Vous pouvez vérifier les chiffrements utilisés à l’aide des méthodes décrites dans la section [Détermination de l’état de la connexion SSL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Concepts.General.SSL.html#PostgreSQL.Concepts.General.SSL.Status).
Les chiffrements peuvent avoir des noms différents selon le contexte :
+ Les chiffrements autorisés que vous pouvez configurer dans votre groupe de paramètres sont désignés par leur nom IANA.
+ Les bannières de connexion `sslinfo` et `psql` font référence aux chiffrements utilisant leur nom OpenSSL.
Par défaut, la valeur de `ssl_max_protocol_version` dans RDS pour PostgreSQL 16 et versions ultérieures est TLS v1.3. Vous devez définir la valeur de ce paramètre sur TLS v1.2, car TLS v1.3 n’utilise pas les configurations de chiffrement spécifiées dans le paramètre `ssl_ciphers`. Lorsque vous définissez la valeur sur TLS v1.2, les connexions utilisent uniquement les chiffrements que vous définissez dans `ssl_ciphers`.
```
aws rds modify-db-parameter-group --db-parameter-group-name --parameters "ParameterName='ssl_max_protocol_version',ParameterValue='TLSv1.2',ApplyMethod=immediate"
```
Pour garantir que les connexions à la base de données utilisent le protocole SSL, définissez `rds.force_ssl parameter` sur 1 dans votre groupe de paramètres. Pour plus d’informations sur les paramètres et les groupes de paramètres, consultez [Groupes de paramètres pour Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html).
# Mise à jour des applications pour se connecter aux instances de base de données PostgreSQL à l'aide de nouveaux certificats SSL/TLS
Certificats utilisés pour Secure Socket Layer ou Transport Layer Security (SSL/TLS) typically have a set lifetime. When service providers update their Certificate Authority (CA) certificates, clients must update their applications to use the new certificates. Following, you can find information about how to determine if your client applications use SSL/TLSpour vous connecter à votre instance de base de données Amazon RDS for PostgreSQL). Vous trouverez également des informations sur la façon de vérifier si ces applications vérifient le certificat du serveur lorsqu'elles se connectent.
**Note**
Une application cliente configurée pour vérifier le certificat du serveur avant la SSL/TLS connexion doit disposer d'un certificat CA valide dans le trust store du client. Mettez à jour le magasin de confiance du client lorsque cela est nécessaire pour de nouveaux certificats.
Une fois que vous avez mis à jour les certificats de l'autorité de certification dans les magasins d'approbations des applications clientes, vous pouvez soumettre les certificats de vos instances de bases de données à une rotation. Nous vous recommandons vivement de tester ces procédures dans un environnement de développement ou intermédiaire avant de les implémenter dans vos environnements de production.
Pour plus d’informations sur la rotation de certificats, consultez [Rotation de votre SSL/TLS certificat](UsingWithRDS.SSL-certificate-rotation.md). Pour en savoir plus sur le téléchargement de certificats, consultez [](UsingWithRDS.SSL.md). Pour plus d'informations sur l'utilisation SSL/TLS avec les instances de base de données PostgreSQL, consultez. [Utilisation de SSL avec une instance de base de données PostgreSQL](PostgreSQL.Concepts.General.SSL.md)
**Topics**
+ [
## Contrôle de la connexion des applications aux instances de bases de données PostgreSQL avec le protocole SSL
](#ssl-certificate-rotation-postgresql.determining-server)
+ [
## Contrôle de la nécessité d’une vérification du certificat du client pour qu’il puisse se connecter
](#ssl-certificate-rotation-postgresql.determining-client)
+ [
## Mise à jour du magasin d’approbations de votre application
](#ssl-certificate-rotation-postgresql.updating-trust-store)
+ [
## Utilisation de SSL/TLS connexions pour différents types d'applications
](#ssl-certificate-rotation-postgresql.applications)
## Contrôle de la connexion des applications aux instances de bases de données PostgreSQL avec le protocole SSL
Dans la configuration de l'instance de base de données, vérifiez la valeur du paramètre `rds.force_ssl`. Par défaut, le paramètre `rds.force_ssl` est défini sur `0` (désactivé) pour les instances de base de données utilisant des versions de PostgreSQL antérieures à la version 15. Par défaut, `rds.force_ssl` est défini sur `1` (activé) pour les instances de base de données utilisant des versions de PostgreSQL version 15 et ultérieures majeures. Si le `rds.force_ssl` paramètre est défini sur `1` (activé), les clients doivent l'utiliser SSL/TLS pour les connexions. Pour plus d'informations sur les groupes de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Si vous utilisez RDS PostgreSQL version 9.5 ou ultérieure et que `rds.force_ssl` n'est pas défini sur `1` (activé), interrogez la vue `pg_stat_ssl` afin de vérifier les connexions à l'aide du protocole SSL. Par exemple, la requête suivante retourne uniquement les connexions SSL et les informations sur les clients utilisant un protocole SSL.
```
SELECT datname, usename, ssl, client_addr
FROM pg_stat_ssl INNER JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid
WHERE ssl is true and usename<>'rdsadmin';
```
Seules les lignes utilisant SSL/TLS des connexions sont affichées avec des informations sur la connexion. Voici un exemple de sortie.
```
datname | usename | ssl | client_addr
----------+---------+-----+-------------
benchdb | pgadmin | t | 53.95.6.13
postgres | pgadmin | t | 53.95.6.13
(2 rows)
```
La requête n'affiche que les connexions actives au moment de la requête. L'absence de résultats n'implique pas forcément qu'aucune application n'utilise de connexions SSL. D’autres connexions SSL peuvent avoir été établies à un moment différent.
## Contrôle de la nécessité d’une vérification du certificat du client pour qu’il puisse se connecter
Quand un client, tel que psql ou JDBC, est configuré avec la prise en charge du protocole SSL, le comportement par défaut est le suivant : le client essaie d’abord de se connecter à la base de données avec le protocole SSL. En cas d’impossibilité, le client revient à la connexion sans protocole SSL. Le mode `sslmode` utilisé par défaut pour les clients libpq (comme psql) et JDBC est défini sur `prefer`. Le certificat sur le serveur n’est vérifié que lorsque `sslrootcert` est fourni avec `sslmode` défini sur `verify-ca` ou `verify-full`. En cas de non-validité du certificat, une erreur est déclenchée.
Utilisez `PGSSLROOTCERT` pour vérifier le certificat avec la variable d’environnement `PGSSLMODE`, avec `PGSSLMODE` défini sur `verify-ca` ou `verify-full`.
```
PGSSLMODE=verify-full PGSSLROOTCERT=/fullpath/ssl-cert.pem psql -h pgdbidentifier.cxxxxxxxx.us-east-2.rds.amazonaws.com -U masteruser -d postgres
```
Utilisez l’argument `sslrootcert` pour vérifier le certificat ayant `sslmode` comme format de chaîne de connexion, avec `sslmode` défini sur `verify-ca` ou `verify-full`.
```
psql "host=pgdbidentifier.cxxxxxxxx.us-east-2.rds.amazonaws.com sslmode=verify-full sslrootcert=/full/path/ssl-cert.pem user=masteruser dbname=postgres"
```
Par exemple, dans le cas précédent, si vous utilisez un certificat racine non valide, une erreur similaire à celle qui suit s'affiche sur votre client.
```
psql: SSL error: certificate verify failed
```
## Mise à jour du magasin d’approbations de votre application
Pour plus d'informations sur la mise à jour du trust store pour les applications PostgreSQL, [consultez la section Connexions TCP/IP sécurisées avec](https://www.postgresql.org/docs/current/ssl-tcp.html) SSL dans la documentation de PostgreSQL.
Pour plus d’informations sur le téléchargement du certificat racine, consultez [](UsingWithRDS.SSL.md).
Pour obtenir des exemples de scripts qui importent des certificats, consultez [Exemple de script pour importer les certificats dans votre magasin d’approbations](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-sample-script).
**Note**
Lors de la mise à jour du magasin d’approbations, vous pouvez conserver les certificats plus anciens en complément de l’ajout des nouveaux certificats.
## Utilisation de SSL/TLS connexions pour différents types d'applications
Vous trouverez ci-dessous des informations sur l'utilisation SSL/TLS des connexions pour différents types d'applications :
+ **psql**
Le client est appelé depuis la ligne de commande en spécifiant des options comme chaîne de connexion ou comme variables d’environnement. Pour SSL/TLS les connexions, les options pertinentes sont `sslmode` (variable d'environnement`PGSSLMODE`), `sslrootcert` (variable d'environnement`PGSSLROOTCERT`).
Pour obtenir la liste complète des options, consultez [Parameter Key Words](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PARAMKEYWORDS) dans la documentation PostgreSQL. Pour obtenir la liste complète des variables d’environnement, consultez [Environment Variables](https://www.postgresql.org/docs/current/libpq-envars.html) dans la documentation PostgreSQL.
+ **pgAdmin**
Ce client basé sur un navigateur est une interface plus conviviale pour se connecter à une base de données PostgreSQL.
Pour plus d’informations sur la configuration des connexions, consultez la [documentation pgAdmin](https://www.pgadmin.org/docs/pgadmin4/latest/server_dialog.html).
+ **JDBC**
JDBC permet de se connecter à la base de données avec des applications Java.
Pour obtenir des informations générales sur la connexion à une base de données PostgreSQL avec JDBC, consultez [Connecting to the Database](https://jdbc.postgresql.org/documentation/use/#connecting-to-the-database) (Connexion à la base de données) dans la documentation du pilote JDBC PostgreSQL. Pour obtenir des informations sur la connexion avec un protocole SSL/TLS, consultez [Configuring the client](https://jdbc.postgresql.org/documentation/ssl/#configuring-the-client) (Configuration du client) dans la documentation du pilote JDBC PostgreSQL.
+ **Python**
est une bibliothèque Python bien connue pour se connecter aux bases de données PostgreSQ `psycopg2`.
Pour plus d’informations sur l’utilisation de `psycopg2`, consultez la [documentation psycopg2](https://pypi.org/project/psycopg2/). Pour obtenir un bref didacticiel sur la connexion à une base de données PostgreSQL, consultez [Psycopg2 Tutorial](https://wiki.postgresql.org/wiki/Psycopg2_Tutorial). Vous trouverez des informations sur les options acceptées par la commande de connexion dans [The psycopg2 module content](http://initd.org/psycopg/docs/module.html#module-psycopg2).
**Important**
Une fois que vous avez déterminé que vos connexions à la base de données utilisent SSL/TLS et que vous avez mis à jour votre magasin de confiance d'applications, vous pouvez mettre à jour votre base de données pour utiliser les certificats rds-ca-rsa 2048-g1. Pour obtenir des instructions, consultez l’étape 3 dans [Mise à jour de votre certificat CA en modifiant votre instance de base de données ou votre cluster](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-updating).
# Utilisation de l’authentification Kerberos avec Amazon RDS pour PostgreSQL
Vous pouvez utiliser Kerberos pour authentifier les utilisateurs lorsqu’ils se connectent à votre instance de base de données qui exécute PostgreSQL. Pour ce faire, configurez votre instance de de base de données à utiliser AWS Directory Service for Microsoft Active Directory pour l'authentification Kerberos. AWS Directory Service for Microsoft Active Directory est également appelé AWS Managed Microsoft AD. C'est une fonctionnalité disponible avec Directory Service. Pour en savoir plus, consultez [Qu'est-ce que c'est Directory Service ?](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html) dans le *Guide AWS Directory Service d'administration*.
Pour commencer, créez un AWS Managed Microsoft AD répertoire pour stocker les informations d'identification des utilisateurs. Vous fournissez ensuite à votre instance de base de données PostgreSQL le domaine d’Active Directory ainsi que d’autres informations. Lorsque les utilisateurs s’authentifient auprès de l’instance de de bases de données PostgreSQL, les demandes d’authentification sont transférées vers l’annuaire AWS Managed Microsoft AD .
Vous pouvez gagner du temps et de l’argent en conservant toutes les informations d’identification dans le même annuaire. Vous avez un endroit centralisé de stockage et de gestion des informations d’identification pour plusieurs instances de base de données. L’utilisation d’un annuaire peut également améliorer votre profil de sécurité global.
Vous pouvez également accéder aux informations d’identification à partir de votre propre annuaire Microsoft Active Directory sur site. Pour ce faire, vous créez une relation de domaine d’approbation afin que l’annuaire AWS Managed Microsoft AD approuve votre annuaire Microsoft Active Directory sur site. De cette façon, vos utilisateurs peuvent accéder à vos instances PostgreSQL avec la même expérience d’authentification unique (SSO) Windows que lorsqu’ils accèdent aux charges de travail de votre réseau sur site.
Une base de données peut utiliser l'authentification par mot de passe ou l'authentification par mot de passe avec l'authentification Kerberos ou Gestion des identités et des accès AWS (IAM). Pour plus d’informations sur l’authentification IAM, consultez [Authentification de base de données IAMpour MariaDB, MySQL et PostgreSQL](UsingWithRDS.IAMDBAuth.md).
**Note**
RDS pour PostgreSQL ne prend pas en charge l’authentification Kerberos pour les groupes Active Directory.
**Topics**
+ [
## Disponibilité des régions et des versions
](#postgresql-kerberos.RegionVersionAvailability)
+ [
## Présentation de l’authentification Kerberos pour les instances de base de données PostgreSQL
](#postgresql-kerberos-overview)
+ [
# Configuration de l’authentification Kerberos pour les instances de base de données PostgreSQL
](postgresql-kerberos-setting-up.md)
+ [
# Gestion d'une RDS pour PostgreSQL dans un domaine Active Directory
](postgresql-kerberos-managing.md)
+ [
# Connexion à PostgreSQL avec l’authentification Kerberos
](postgresql-kerberos-connecting.md)
## Disponibilité des régions et des versions
La disponibilité et la prise en charge des fonctionnalités varient selon les versions spécifiques de chaque moteur de base de données, et selon les Régions AWS. Pour obtenir plus d’informations sur la disponibilité des versions et des régions de RDS pour PostgreSQL avec authentification Kerberos, consultez [Régions et moteurs de base de données pris en charge pour l’authentification Kerberos dans Amazon RDS](Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.md).
## Présentation de l’authentification Kerberos pour les instances de base de données PostgreSQL
Pour configurer l’authentification Kerberos pour une instance de base de données PostgreSQL, exécutez les étapes suivantes, décrites plus en détails par la suite :
1. AWS Managed Microsoft AD À utiliser pour créer un AWS Managed Microsoft AD répertoire. Vous pouvez utiliser le AWS Management Console AWS CLI, le ou l' Directory Service API pour créer le répertoire. Veillez à ouvrir les ports sortants appropriés sur le groupe de sécurité de répertoire afin que le répertoire puisse communiquer avec l’instance.
1. Créez un rôle qui fournit à un accès Amazon RDS pour passer des appels vers votre AWS Managed Microsoft AD annuaire. Pour ce faire, créez un rôle Gestion des identités et des accès AWS (IAM) qui utilise la politique IAM gérée. `AmazonRDSDirectoryServiceAccess`
Pour que le rôle IAM autorise l'accès, le point de terminaison AWS Security Token Service (AWS STS) doit être activé dans la AWS région appropriée pour votre AWS compte. AWS STS les points de terminaison sont actifs par défaut dans tous les cas Régions AWS, et vous pouvez les utiliser sans autre action. Pour plus d'informations, consultez la section [Activation et désactivation AWS STS dans une AWS région](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#sts-regions-activate-deactivate) dans le guide de l'*utilisateur IAM*.
1. Créez et configurez des utilisateurs dans l' AWS Managed Microsoft AD annuaire à l'aide des outils Microsoft Active Directory. Pour plus d'informations sur la création d'utilisateurs dans votre Active Directory, voir [Gérer les utilisateurs et les groupes dans AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) dans le *Guide d'Directory Service administration*.
1. Si vous prévoyez de localiser le répertoire et l'instance de base de données dans différents AWS comptes ou clouds privés virtuels (VPCs), configurez le peering VPC. Pour plus d’informations, consultez [Qu’est-ce que l’appairage de VPC ?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) dans le *Guide d’appairage de VPC Amazon*.
1. Créez ou modifiez une instance de base de données PostgreSQL depuis la console, la CLI ou l’API RDS à l’aide de l’une des méthodes suivantes :
+ [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md)
+ [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md)
+ [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md)
+ [Restauration d’une instance de base de données à un instant précis pour Amazon RDS](USER_PIT.md)
Vous pouvez localiser l'instance de dans le même Amazon Virtual Private Cloud (VPC) que le répertoire ou dans un autre compte AWS ou VPC. Lors de la création ou de la modification de l’instance de base de données PostgreSQL, procédez comme suit :
+ Fournissez l’identifiant du domaine (identifiant `d-*`) qui a été généré lors de la création de votre annuaire.
+ Fournissez le nom du rôle IAM que vous avez créé.
+ Veillez à ce que le groupe de sécurité de l’instance de base de données puisse recevoir le trafic entrant depuis le groupe de sécurité de l’annuaire.
1. Utilisez les informations d’identification de l’utilisateur principal RDS pour vous connecter à l’instance de base de données PostgreSQL. Créez l’utilisateur dans PostgreSQL en vue de son identification externe. Les utilisateurs identifiés en externe peuvent se connecter à l’instance de base de données PostgreSQL à l’aide de l’authentification Kerberos.
# Configuration de l’authentification Kerberos pour les instances de base de données PostgreSQL
Pour configurer l’authentification Kerberos, procédez comme suit :
**Topics**
+ [
## Étape 1 : créer un répertoire à l'aide de AWS Managed Microsoft AD
](#postgresql-kerberos-setting-up.create-directory)
+ [
## Étape 2 : (Facultatif) Créez une relation de confiance entre votre Active Directory local et Directory Service
](#postgresql-kerberos-setting-up.create-trust)
+ [
## Étape 3 : créer un rôle IAM pour RDS) afin d'accéder au Directory Service
](#postgresql-kerberos-setting-up.CreateIAMRole)
+ [
## Étape 4 : Créer et configurer des utilisateurs
](#postgresql-kerberos-setting-up.create-users)
+ [
## Étape 5 : Activer le trafic entre VPC entre le répertoire et l’instance de base de données
](#postgresql-kerberos-setting-up.vpc-peering)
+ [
## Étape 6 : Créer ou modifier une de cluster de bases de données PostgreSQL
](#postgresql-kerberos-setting-up.create-modify)
+ [
## Étape 7 : Créer des utilisateurs PostgreSQL pour vos principaux Kerberos
](#postgresql-kerberos-setting-up.create-logins)
+ [
## Étape 8 : Configurer un client PostgreSQL
](#postgresql-kerberos-setting-up.configure-client)
## Étape 1 : créer un répertoire à l'aide de AWS Managed Microsoft AD
Directory Service crée un Active Directory entièrement géré dans le AWS cloud. Lorsque vous créez un AWS Managed Microsoft AD annuaire, il Directory Service crée deux contrôleurs de domaine et deux serveurs DNS pour vous. Les serveurs de répertoire sont créés dans des sous-réseaux différents d’un VPC. Cette redondance permet de s’assurer que votre annuaire reste accessible, y compris en cas de défaillance.
Lorsque vous créez un AWS Managed Microsoft AD annuaire, AWS Directory Service exécute les tâches suivantes en votre nom :
+ Configuration d’un annuaire Active Directory dans votre VPC.
+ Création d’un compte d’administrateur d’annuaire avec le nom d’utilisateur `Admin` et le mot de passe spécifié. Ce compte est utilisé pour gérer votre annuaire.
**Important**
Assurez-vous d'enregistrer ce mot de passe. Directory Service ne stocke pas ce mot de passe et il ne peut pas être récupéré ou réinitialisé.
+ Création d’un groupe de sécurité pour les contrôleurs de l’annuaire. Le groupe de sécurité doit autoriser la communication avec l’instance de base de données PostgreSQL.
Lorsque vous lancez AWS Directory Service for Microsoft Active Directory, AWS crée une unité organisationnelle (UO) qui contient tous les objets de votre répertoire. Cette unité organisationnelle, qui porte le nom NetBIOS que vous avez entré lorsque vous avez créé votre annuaire, est située dans la racine du domaine. La racine du domaine est détenue et gérée par AWS.
Le `Admin` compte créé avec votre AWS Managed Microsoft AD annuaire dispose d'autorisations pour les activités administratives les plus courantes de votre unité d'organisation :
+ Création, mise à jour et suppression des utilisateurs
+ Ajouter des ressources à votre domaine, comme des serveurs de fichiers ou d’impression, puis attribuer des autorisations pour ces ressources aux utilisateurs dans votre unité organisationnelle
+ Créez des conteneurs OUs et des conteneurs supplémentaires
+ Déléguer des autorités
+ Restaurer des objets supprimés de la corbeille Active Directory
+ Exécuter les modules Active Directory et DNS (Domain Name Service) pour Windows PowerShell sur le service Web Active Directory
Le compte `Admin` dispose également de droits pour exécuter les activités suivantes au niveau du domaine :
+ Gérer les configurations DNS (ajouter, supprimer ou mettre à jour des enregistrements, des zones et des redirecteurs)
+ Afficher les journaux d’événements DNS
+ Afficher les journaux d’événements de sécurité
**Pour créer un répertoire avec AWS Managed Microsoft AD**
1. Dans le panneau de navigation de la [console Directory Service](https://console.aws.amazon.com/directoryservicev2/), choisissez **Directories** (Répertoires), puis **Set up directory** (Configurer le répertoire).
1. Choisissez **AWS Managed Microsoft AD**. AWS Managed Microsoft AD est la seule option actuellement prise en charge pour une utilisation avec Amazon RDS.
1. Choisissez **Suivant**.
1. Sur la page **Enter directory information** (Saisir les détails du répertoire), renseignez les informations suivantes :
**Edition**
Choisissez l’édition qui correspond à vos besoins.
**Nom de DNS de l’annuaire**
Nom complet de l’annuaire, par exemple **corp.example.com**.
**Nom NetBIOS de l’annuaire**
Nom court facultatif pour l’annuaire, par exemple `CORP`.
**Description de l’annuaire**
Description facultative de l’annuaire.
**Mot de passe administrateur**
Mot de passe de l’administrateur de l’annuaire. Le processus de création d’un annuaire crée un compte d’administrateur avec le nom d’utilisateur `Admin` et ce mot de passe.
Le mot de passe de l’administrateur de l’annuaire ne peut pas contenir le terme « admin ». Le mot de passe est sensible à la casse et doit comporter entre 8 et 64 caractères. Il doit également contenir au moins un caractère de trois des quatre catégories suivantes :
+ Lettres minuscules (a–z)
+ Lettres majuscules (A–Z)
+ Chiffres (0–9)
+ Caractères non alphanumériques (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"’<>,.?/)
**Confirmer le mot de passe**
Saisissez à nouveau le mot de passe de l’administrateur.
Assurez-vous d'enregistrer ce mot de passe. Directory Service ne stocke pas ce mot de passe et il ne peut pas être récupéré ou réinitialisé.
1. Choisissez **Suivant**.
1. Sur la page **Choose VPC and subnets** (Choisir un VPC et des sous-réseaux), indiquez les informations suivantes :
**VPC**
Sélectionnez le VPC pour l’annuaire. Vous pouvez créer l’instance de base de données PostgreSQL dans ce même VPC ou dans un autre VPC.
**Sous-réseaux**
Choisissez les sous-réseaux pour les serveurs d’annuaires. Les deux sous-réseaux doivent être dans des zones de disponibilité différentes.
1. Choisissez **Suivant**.
1. Vérifiez les informations du répertoire. Si vous devez apporter des modifications, choisissez **Previous** (Précédent) et entrez ces modifications. Lorsque les informations sont correctes, choisissez **Create directory (Créer l’annuaire)**.
![\[Page de détails de l’annuaire\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/WinAuth2.png)
La création de l’annuaire prend plusieurs minutes. Lorsqu’il est créé, la valeur du champ **Statut** devient **Actif**.
Pour consulter les informations relatives à votre annuaire, choisissez l’ID de l’annuaire dans la liste. Notez la valeur de **Directory ID** (ID du répertoire). Vous en aurez besoin pour créer ou modifier votre instance de base de données PostgreSQL.
![\[Image de la page de détails\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/WinAuth3.png)
## Étape 2 : (Facultatif) Créez une relation de confiance entre votre Active Directory local et Directory Service
Si vous ne prévoyez pas d’utiliser votre propre Microsoft Active Directory sur site, passez à [Étape 3 : créer un rôle IAM pour RDS) afin d'accéder au Directory Service](#postgresql-kerberos-setting-up.CreateIAMRole).
Pour obtenir l'authentification Kerberos à l'aide de votre Active Directory local, vous devez créer une relation de domaine de confiance à l'aide d'une approbation forestière entre votre Microsoft Active Directory local et l' AWS Managed Microsoft AD annuaire (créé dans). [Étape 1 : créer un répertoire à l'aide de AWS Managed Microsoft AD](#postgresql-kerberos-setting-up.create-directory) La confiance peut être unidirectionnelle, lorsque l' AWS Managed Microsoft AD annuaire fait confiance à Microsoft Active Directory local. L’approbation peut également être bidirectionnelle. Dans ce cas, les deux Active Directory s’approuvent mutuellement. Pour plus d'informations sur la configuration des approbations [à l'aide Directory Service de la section Quand créer une relation de confiance](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html) dans le *Guide d'AWS Directory Service administration*.
**Note**
Si vous utilisez un Microsoft Active Directory local, les clients Windows se connectent en utilisant le nom de domaine du Directory Service point de terminaison plutôt que rds.amazonaws.com. Pour en savoir plus, veuillez consulter la section [Connexion à PostgreSQL avec l’authentification Kerberos](postgresql-kerberos-connecting.md).
Assurez-vous que le nom de domaine de votre Microsoft Active Directory sur site inclut un routage de suffixe DNS correspondant à la relation d’approbation nouvellement créée. La capture d’écran suivante présente un exemple.
![\[Le routage DNS correspond à l’approbation créée\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/kerberos-auth-trust.png)
## Étape 3 : créer un rôle IAM pour RDS) afin d'accéder au Directory Service
Pour qu' Amazon RDS puisse vous appeler Directory Service , votre AWS compte a besoin d'un rôle IAM qui utilise la politique IAM gérée. `AmazonRDSDirectoryServiceAccess` Ce rôle permet à Amazon RDS d’appeler Directory Service.
Lorsque vous créez une instance de base de données à l'aide de AWS Management Console et que votre compte utilisateur de console dispose de l'`iam:CreateRole`autorisation, la console crée automatiquement le rôle IAM nécessaire. Dans ce cas, le nom du rôle est `rds-directoryservice-kerberos-access-role`. Sinon, vous devez créer le rôle IAM manuellement. Lorsque vous créez ce rôle IAM`Directory Service`, choisissez et associez la politique AWS gérée `AmazonRDSDirectoryServiceAccess` à celui-ci.
Pour plus d'informations sur la création de rôles IAM pour un service, consultez la section [Création d'un rôle pour déléguer des autorisations à un AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le Guide de l'*utilisateur IAM*.
**Note**
Le rôle IAM utilisé pour l’authentification Windows pour RDS for Microsoft SQL Server ne peut pas être utilisé pour Amazon RDS pour PostgreSQL.
Vous pouvez également créer des stratégies avec les autorisations obligatoires au lieu d’utiliser la politique gérée `AmazonRDSDirectoryServiceAccess`. Dans ce cas, le rôle IAM doit avoir la politique d’approbation IAM suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.amazonaws.com",
"rds.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Le rôle doit également avoir la politique de rôle IAM suivante.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ds:DescribeDirectories",
"ds:AuthorizeApplication",
"ds:UnauthorizeApplication",
"ds:GetAuthorizedApplicationDetails"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
Pour l'opt-in Régions AWS, utilisez les principes de service spécifiques à la région dans les politiques de confiance des rôles IAM. Lorsque vous créez une stratégie d’approbation pour les services dans ces régions, indiquez le code de région dans le principal de service.
L’exemple suivant présente une stratégie d’approbation qui fait appel à des principaux de service spécifiques à la région :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.REGION-CODE.amazonaws.com",
"rds.REGION-CODE.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Remplacez REGION-CODE par le code de votre région spécifique. Utilisez par exemple les principaux de service suivants pour la région Asie-Pacifique (Melbourne) :
```
"Service": [
"directoryservice.rds.ap-southeast-4.amazonaws.com",
"rds.ap-southeast-4.amazonaws.com"
]
```
## Étape 4 : Créer et configurer des utilisateurs
Vous pouvez créer des utilisateurs à l’aide de l’outil Active Directory Users and Computers. C’est l’un des outils Active Directory Domain Services et Active Directory Lightweight Directory Services. Pour plus d’informations, consultez [Ajouter des utilisateurs et des ordinateurs au domaine Active Directory](https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/create-an-active-directory-server#add-users-and-computers-to-the-active-directory-domain) dans la documentation Microsoft. Dans ce cas, les utilisateurs sont des individus ou d’autres entités, tels que leurs ordinateurs, qui font partie du domaine et dont les identités sont conservées dans l’annuaire.
Pour créer des utilisateurs dans un Directory Service annuaire, vous devez être connecté à une instance Amazon EC2 basée sur Windows qui est membre de Directory Service l'annuaire. Parallèlement, vous devez être connecté en tant qu’utilisateur disposant de privilèges pour créer des utilisateurs. Pour plus d’informations, consultez [Créer un utilisateur](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_create_user.html) dans le *Guide d’administration AWS Directory Service *.
## Étape 5 : Activer le trafic entre VPC entre le répertoire et l’instance de base de données
Si vous avez l’intention de rechercher le répertoire et l’instance de base de données dans le même VPC, ignorez cette étape et passez à [Étape 6 : Créer ou modifier une de cluster de bases de données PostgreSQL](#postgresql-kerberos-setting-up.create-modify).
[Si vous prévoyez de localiser le répertoire et l'instance de base de données différemment VPCs, configurez le trafic inter-VPC à l'aide du peering VPC ou de Transit Gateway.AWS](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
La procédure suivante active le trafic entre les utilisateurs de VPCs l'appairage VPC. Suivez les instructions de [Qu’est-ce que l’appairage de VPC ?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) dans le *Guide de l’appairage Amazon Virtual Private Cloud*.
**Pour activer le trafic entre VPC à l’aide de l’appairage de VPC**
1. Configurez les règles de routage de VPC appropriées afin de veiller à ce que le trafic réseau puisse être acheminé dans les deux sens.
1. Veillez à ce que le groupe de sécurité de l’instance de base de données puisse recevoir le trafic entrant depuis le groupe de sécurité de l’annuaire.
1. Assurez-vous qu’il n’existe aucune règle de liste de contrôle d’accès (ACL) pour bloquer le trafic.
Si le répertoire appartient à un autre AWS compte, vous devez le partager.
**Pour partager le répertoire entre AWS comptes**
1. *Commencez à partager le répertoire avec le AWS compte dans lequel l'instance de base de données sera créée en suivant les instructions du [didacticiel : Partage de votre répertoire Microsoft AD AWS géré pour une connexion fluide à un domaine EC2 dans le Directory Service guide](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html) d'administration.*
1. Connectez-vous à la Directory Service console à l'aide du compte de l'instance de base de données et assurez-vous que le domaine possède le `SHARED` statut requis avant de continuer.
1. Lorsque vous êtes connecté à la Directory Service console à l'aide du compte de l'instance de base de données, notez la valeur de l'**ID du répertoire**. Vous utilisez cet ID d’annuaire pour joindre l’instance de base de données au domaine.
## Étape 6 : Créer ou modifier une de cluster de bases de données PostgreSQL
Créez ou modifiez une instance de base de données PostgreSQL en vue de son utilisation avec votre répertoire. Vous pouvez utiliser la console, la CLI ou l’API RDS pour associer une instance de base de données à un répertoire. Vous pouvez effectuer cette opération de différentes manières :
+ Créez une nouvelle instance de base de données PostgreSQL à l'aide de la console, de la commande [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)CLI ou de l'opération DBInstance Create [RDS](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) API. Pour obtenir des instructions, veuillez consulter [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
+ Modifiez une instance de base de données PostgreSQL existante à l'aide de la console, de la commande [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI ou de l'opération DBInstance Modify [RDS](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API. Pour obtenir des instructions, veuillez consulter [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
+ [Restaurez une instance de base de données PostgreSQL à partir d'un instantané de base de données à l'aide de la console, de la commande CLI [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) ou de l'opération Restore From RDS API. DBInstance DBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) Pour obtenir des instructions, veuillez consulter [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md).
+ Restaurez une instance de base de données PostgreSQL à point-in-time l'aide de la console, de la commande [restore-db-instance-to- point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI ou de l'opération DBInstance ToPointInTime Restore [RDS API](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html). Pour obtenir des instructions, veuillez consulter [Restauration d’une instance de base de données à un instant précis pour Amazon RDS](USER_PIT.md).
L’authentification Kerberos est uniquement prise en charge pour les instances de base de données PostgreSQL dans un VPC. L’instance de base de données peut se trouver dans le même VPC que le répertoire ou dans un autre VPC. L’instance de base de données doit utiliser un groupe de sécurité qui accepte les entrées et les sorties dans le VPC du répertoire pour permettre à l’instance de base de données de communiquer avec le répertoire.
### Console
Lorsque vous utilisez la console pour créer, modifier ou restaurer une instance de bases de données, choisissez **Mot de passe et authentification Kerberos** dans la section **Authentification de base de données**. Ensuite, choisissez **Parcourir les annuaires**. Sélectionnez le répertoire ou choisissez **Create a new directory** (Créer un nouveau répertoire) pour utiliser Directory Service.
![\[Choisissez Kerberos pour authentifier et identifier le répertoire à utiliser.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rpg-authentication-use-kerberos.png)
### AWS CLI
Lorsque vous utilisez le AWS CLI, les paramètres suivants sont requis pour que l'instance de de base de données puisse utiliser le répertoire que vous avez créé :
+ Pour le paramètre `--domain`, vous devez indiquer l’identifiant du domaine (identifiant « d-\$1 ») généré lors de la création de l’annuaire.
+ Pour le paramètre `--domain-iam-role-name`, utilisez le rôle que vous avez créé qui utilise la politique IAM gérée `AmazonRDSDirectoryServiceAccess`.
Par exemple, la commande de CLI suivante modifie une instance de base de données de façon à utiliser un répertoire.
```
aws rds modify-db-instance --db-instance-identifier mydbinstance --domain d-Directory-ID --domain-iam-role-name role-name
```
**Important**
Si vous modifiez une instance de base de données de façon à activer l’authentification Kerberos, redémarrez l’instance de base de données après avoir effectué la modification.
## Étape 7 : Créer des utilisateurs PostgreSQL pour vos principaux Kerberos
À ce stade, votre instance de base de données RDS pour PostgreSQL est jointe au domaine AWS Managed Microsoft AD . Les utilisateurs que vous avez créés dans l’annuaire dans [Étape 4 : Créer et configurer des utilisateurs](#postgresql-kerberos-setting-up.create-users) doivent être configurés en tant qu’utilisateurs de base de données PostgreSQL et bénéficier de privilèges leur permettant de se connecter à la base de données. Pour ce faire, vous devez vous connecter en tant qu’utilisateur de base de données doté de privilèges `rds_superuser`. Par exemple, si vous avez accepté les valeurs par défaut lors de la création de votre instance de base de données RDS pour PostgreSQL, vous utilisez `postgres`, comme indiqué dans les étapes suivantes.
**Pour créer des utilisateurs de base de données PostgreSQL pour les principaux Kerberos**
1. Utilisez `psql` pour vous connecter à votre point de terminaison d’instance de base de données RDS pour PostgreSQL à l’aide de `psql`. L’exemple suivant utilise le compte `postgres` par défaut pour le rôle `rds_superuser`.
```
psql --host=cluster-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Créez un nom d’utilisateur de base de données pour chaque principal Kerberos (nom d’utilisateur Active Directory) auquel vous souhaitez accorder l’accès à la base de données. Utilisez le nom d’utilisateur canonique (identité) tel que défini dans l’instance Active Directory, c’est-à-dire un `alias` en minuscule (nom d’utilisateur dans Active Directory) et le nom en majuscule du domaine Active Directory pour ce nom d’utilisateur. Le nom d’utilisateur Active Directory est un utilisateur authentifié de manière externe. Utilisez donc des guillemets autour du nom, comme indiqué ci-dessous.
```
postgres=> CREATE USER "username@CORP.EXAMPLE.COM" WITH LOGIN;
CREATE ROLE
```
1. Accordez le rôle `rds_ad` à l’utilisateur de la base de données.
```
postgres=> GRANT rds_ad TO "username@CORP.EXAMPLE.COM";
GRANT ROLE
```
Une fois que vous avez fini de créer tous les utilisateurs PostgreSQL pour vos identités utilisateur Active Directory, les utilisateurs peuvent accéder à l’instance de base de données RDS pour PostgreSQL à l’aide de leurs informations d’identification Kerberos.
Les utilisateurs de base de données qui s’authentifient à l’aide de Kerberos doivent utiliser des machines clientes membres du domaine Active Directory.
Les utilisateurs de base de données auxquels le rôle `rds_ad` a été attribué ne peuvent pas disposer également du rôle `rds_iam`. Cela s’applique également aux adhésions imbriquées. Pour plus d’informations, consultez [Authentification de base de données IAMpour MariaDB, MySQL et PostgreSQL](UsingWithRDS.IAMDBAuth.md).
## Étape 8 : Configurer un client PostgreSQL
Pour configurer un client PostgreSQL, procédez comme suit :
+ Créez un fichier krb5.conf (ou équivalent) pointant vers le domaine.
+ Vérifiez que le trafic peut circuler entre l'hôte client et Directory Service. Utilisez un utilitaire réseau tel que Netcat pour les opérations suivantes :
+ Vérifiez le trafic via DNS pour le port 53.
+ Vérifiez le trafic dépassé TCP/UDP pour le port 53 et pour Kerberos, qui inclut les ports 88 et 464 pour. Directory Service
+ Vérifiez que le trafic peut circuler entre l’hôte du client et l’instance de base de données via le port de la base de données. Par exemple, utilisez psql pour vous connecter à la base de données et y accéder.
Voici un exemple de contenu du fichier krb5.conf pour. AWS Managed Microsoft AD
```
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
```
Vous trouverez ci-après un exemple de contenu krb5.conf pour un Microsoft Active Directory sur site.
```
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
ONPREM.COM = {
kdc = onprem.com
admin_server = onprem.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
.onprem.com = ONPREM.COM
onprem.com = ONPREM.COM
.rds.amazonaws.com = EXAMPLE.COM
.amazonaws.com.rproxy.goskope.com.cn = EXAMPLE.COM
.amazon.com = EXAMPLE.COM
```
# Gestion d'une RDS pour PostgreSQL dans un domaine Active Directory
Vous pouvez utiliser la console, la CLI ou l’API RDS pour gérer votre instance de base de données et sa relation avec Microsoft Active Directory. Par exemple, vous pouvez associer un annuaire Active Directory de façon à activer l’authentification Kerberos. Vous pouvez également supprimer l’association d’un annuaire Active Directory pour désactiver l’authentification Kerberos. Vous pouvez également transférer une instance de base de données vers un autre élément de même type afin de subir une authentification en externe par un annuaire Microsoft Active Directory.
Par exemple, la CLI vous permet d’effectuer les actions suivantes :
+ Pour réessayer d'activer l'authentification Kerberos en cas d'échec d'adhésion, utilisez la commande CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html). Spécifiez l’ID d’annuaire du membre actuel pour l’option `--domain`.
+ Pour désactiver l'authentification Kerberos sur une instance de base de données, utilisez la commande [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI. Spécifiez `none` pour l’option `--domain`.
+ Pour déplacer une instance de base de données d'un domaine à un autre, utilisez la commande [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI. Spécifiez l’identifiant du nouveau domaine pour l’option `--domain`.
## Présentation de l’appartenance au domaine
Une fois que vous avez créé ou modifié votre instance de base de données, il devient membre du domaine. Vous pouvez consulter l'état de l'appartenance au domaine dans la console ou en exécutant la commande [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)CLI. Le statut de l'instance de base de données peut avoir les valeurs suivantes :
+ `kerberos-enabled` : l’instance de base de données a l’authentification Kerberos activée.
+ `enabling-kerberos`— AWS est en train d'activer l'authentification Kerberos sur cette instance de base de données.
+ `pending-enable-kerberos` : l’activation de l’authentification Kerberos est en attente sur cette instance de base de données.
+ `pending-maintenance-enable-kerberos`— AWS tentera d'activer l'authentification Kerberos sur l'instance de base de données lors de la prochaine fenêtre de maintenance planifiée.
+ `pending-disable-kerberos` : la désactivation de l’authentification Kerberos est en attente sur cette instance de base de données.
+ `pending-maintenance-disable-kerberos`— AWS tentera de désactiver l'authentification Kerberos sur l'instance de base de données lors de la prochaine fenêtre de maintenance planifiée.
+ `enable-kerberos-failed`— Un problème de configuration a AWS empêché l'activation de l'authentification Kerberos sur l'instance de base de données. Corrigez le problème de configuration avant de réémettre la commande de modification de l’instance de base de données.
+ `disabling-kerberos`— AWS est en train de désactiver l'authentification Kerberos sur cette instance de base de données.
Une demande d’activation de l’authentification Kerberos peut échouer à cause d’un problème de connectivité réseau ou d’un rôle IAM incorrect. Dans certains cas, la tentative d’activation de l’authentification Kerberos peut échouer lorsque vous créez ou modifiez une instance de base de données. Si tel est le cas, vérifiez que vous utilisez le rôle IAM correct, puis modifiez l’instance de base de données afin d’effectuer son rattachement au domaine.
**Note**
Seule l’authentification Kerberos avec RDS pour PostgreSQL envoie le trafic aux serveurs DNS du domaine. Toutes les autres demandes DNS sont traitées comme un accès réseau sortant sur vos instances de bases de données exécutant PostgreSQL. Pour plus d’informations sur l’accès réseau sortant avec RDS pour PostgreSQL, consultez [Utilisation d'un serveur DNS personnalisé pour l'accès réseau sortant.](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md).
# Connexion à PostgreSQL avec l’authentification Kerberos
Vous pouvez vous connecter à PostgreSQL via l’authentification Kerberos avec l’interface pgAdmin ou avec une CLI telle que psql. Pour plus d’informations sur la connexion, consultez [Connexion à une instance de base de données exécutant le moteur de base de données PostgreSQL](USER_ConnectToPostgreSQLInstance.md) . Pour plus d’informations sur l’obtention du point de terminaison, du numéro de port et d’autres détails nécessaires à la connexion, consultez [Se connecter à une instance DB PostgreSQL](CHAP_GettingStarted.CreatingConnecting.PostgreSQL.md#CHAP_GettingStarted.Connecting.PostgreSQL).
**Note**
L’authentification et le chiffrement GSSAPI dans PostgreSQL sont implémentés par la bibliothèque Kerberos `libkrb5.so`. Des fonctionnalités telles que `postgres_fdw` et `dblink` s’appuient également sur cette même bibliothèque pour établir des connexions sortantes nécessitant une authentification ou un chiffrement Kerberos.
## pgAdmin
Pour vous connecter à PostgreSQL avec l’authentification Kerberos en utilisant pgAdmin, procédez comme suit :
1. Lancez l’application pgAdmin sur votre ordinateur client.
1. Dans l’onglet **Dashboard** (Tableau de bord), choisissez **Add New Server** (Ajouter un nouveau serveur).
1. Dans la boîte de dialogue **Créer : serveur**, entrez un nom sur l’onglet **Général** pour identifier le serveur dans pgAdmin.
1. Dans l’onglet **Connection** (Connexion), entrez les informations suivantes à partir de votre base de données RDS pour PostgreSQL.
+ Pour **Host** (Hôte), entrez le point de terminaison de . Instance de base de données RDS pour PostgreSQL. Un point de terminaison ressemble à ce qui suit :
```
RDS-DB-instance.111122223333.aws-region.rds.amazonaws.com
```
Pour vous connecter à un Microsoft Active Directory local à partir d'un client Windows, vous devez utiliser le nom de domaine du AWS Managed Active Directory plutôt que celui du point `rds.amazonaws.com` de terminaison hôte. Supposons, par exemple, que le nom de domaine de AWS Managed Active Directory soit`corp.example.com`. Puis, pour **Host** (Hôte), le point de terminaison serait spécifié comme suit :
```
RDS-DB-instance.111122223333.aws-region.corp.example.com
```
+ Pour **Port**, entrez le port attribué.
+ Pour **Maintenance database** (Base de données de maintenance), entrez le nom de la base de données initiale à laquelle le client se connectera.
+ Pour **Username** (Nom d’utilisateur), saisissez le nom d’utilisateur que vous avez entré pour l’authentification Kerberos dans [Étape 7 : Créer des utilisateurs PostgreSQL pour vos principaux Kerberos](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins).
1. Choisissez **Enregistrer**.
## Psql
Pour vous connecter à PostgreSQL avec l’authentification Kerberos en utilisant psql, procédez comme suit :
1. A partir d’une invite de commande, exécutez la commande suivante.
```
kinit username
```
Remplacez *`username`* par le nom de l’utilisateur. À l’invite, entrez le mot de passe stocké dans le Microsoft Active Directory pour l’utilisateur.
1. Si l’instance de base de données PostgreSQL utilise un VPC accessible au public, placez une adresse IP pour le point de terminaison de votre instance de base de données dans votre fichier `/etc/hosts` sur le client EC2. Par exemple, les commandes suivantes permettent d’obtenir l’adresse IP et de la placer dans le fichier `/etc/hosts`.
```
% dig +short PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com
;; Truncated, retrying in TCP mode.
ec2-34-210-197-118.AWS-Region.compute.amazonaws.com.
34.210.197.118
% echo " 34.210.197.118 PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com" >> /etc/hosts
```
Si vous utilisez une instance Microsoft Active Directory sur site à partir d’un client Windows, vous devez vous connecter à l’aide d’un point de terminaison spécifique. Au lieu d'utiliser le domaine Amazon `rds.amazonaws.com` dans le point de terminaison hôte, utilisez le nom de domaine du AWS Managed Active Directory.
Supposons, par exemple, que le nom de domaine de votre annuaire Active Directory AWS géré soit`corp.example.com`. Alors, utilisez le format `PostgreSQL-endpoint.AWS-Region.corp.example.com` pour le point de terminaison et placez-le dans le fichier `/etc/hosts`.
```
% echo " 34.210.197.118 PostgreSQL-endpoint.AWS-Region.corp.example.com" >> /etc/hosts
```
1. Utilisez la commande psql suivante pour vous connecter à une instance de base de données PostgreSQL intégré(e) à Active Directory.
```
psql -U username@CORP.EXAMPLE.COM -p 5432 -h PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com postgres
```
Pour vous connecter au cluster de bases de données PostgreSQL à partir d’un client Windows à l’aide d’un Active Directory sur site, utilisez la commande psql suivante avec le nom de domaine de l’étape précédente (`corp.example.com`):
```
psql -U username@CORP.EXAMPLE.COM -p 5432 -h PostgreSQL-endpoint.AWS-Region.corp.example.com postgres
```
# Utilisation d'un serveur DNS personnalisé pour l'accès réseau sortant.
RDS for PostgreSQL prend en charge l'accès réseau sortant sur les instances de base de données. Il permet également la résolution DNS depuis un serveur DNS appartenant au client. Vous pouvez résoudre uniquement les deux noms de domaine complets à partir de votre instance de base de données RDS for PostgreSQL via votre serveur DNS personnalisé.
**Topics**
+ [
## Activer la résolution DNS personnalisée
](#Appendix.PostgreSQL.CommonDBATasks.CustomDNS.Enable)
+ [
## Désactivation de la résolution DNS personnalisée
](#Appendix.PostgreSQL.CommonDBATasks.CustomDNS.Disable)
+ [
## Configuration d'un serveur DNS personnalisé
](#Appendix.Oracle.CommonDBATasks.CustomDNS.Setup)
## Activer la résolution DNS personnalisée
Pour activer la résolution DNS dans votre VPC client, commencez par associer un groupe de paramètres de base de données personnalisé à votre instance RDS for PostgreSQL. Activez ensuite le paramètre `rds.custom_dns_resolution` en le définissant à la valeur 1, puis redémarrez l'instance de base de données pour que les modifications soient prises en compte.
## Désactivation de la résolution DNS personnalisée
Pour désactiver la résolution DNS dans votre VPC client, désactivez d'abord le paramètre `rds.custom_dns_resolution` de votre groupe de paramètres de base de données personnalisé en définissant sa valeur à 0. Redémarrez ensuite l'instance de base de données pour que les modifications soient prises en compte.
## Configuration d'un serveur DNS personnalisé
Une fois que votre serveur de nom DNS personnalisé est configuré, la propagation des modifications dans votre instance de base de données peut prendre jusqu'à 30 minutes. Une fois que les modifications sont propagées dans votre instance de base de données, l'ensemble du trafic réseau sortant nécessitant une recherche DNS interroge votre serveur DNS via le port 53.
**Note**
Si vous ne configurez pas de serveur DNS personnalisé et que le paramètre `rds.custom_dns_resolution` est défini sur 1, les hôtes sont résolus à l'aide d'une zone privée Amazon Route 53. Pour plus d'informations, veuillez onsulter [Utilisation des zones hébergées privées](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html).
**Pour configurer un serveur DNS personnalisé pour votre instance de base de données RDS for PostgreSQL**
1. À partir du jeu d'options du protocole de configuration d'hôte dynamique (DHCP) liées à votre VPC, définissez l'option `domain-name-servers` sur l'adresse IP de votre serveur de noms DNS. Pour plus d’informations, consultez [Jeux d’options DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html).
**Note**
L'option `domain-name-servers` autorise jusqu'à quatre valeurs, mais votre instance de base de données Amazon RDS utilise uniquement la première valeur.
1. Assurez-vous que votre serveur DNS peut résoudre toutes les requêtes de recherche, notamment les noms DNS publics, les noms DNS privés Amazon EC2 et les noms DNS spécifiés par le client. Si le trafic réseau sortant contient une recherche DNS que votre serveur DNS ne peut pas gérer, votre serveur DNS doit avoir des fournisseurs DNS en amont appropriés, configurés.
1. Configurez votre serveur DNS pour produire des réponses UDP (User Datagram Protocol) de 512 octets ou moins.
1. Configurez votre serveur DNS pour produire des réponses TCP (Transmission Control Protocol) de 1 024 octets ou moins.
1. Configurez votre serveur DNS pour permettre le trafic entrant à partir de vos instances de bases de données Amazon RDS sur le port 53. Si votre serveur DNS est dans un Amazon VPC, le VPC doit avoir un groupe de sécurité qui contient des règles entrantes qui permettent le trafic UDP et TCP sur le port 53. Si votre serveur DNS n'est pas dans un Amazon VPC, il doit avoir des paramètres de pare-feux appropriés pour permettre le trafic UDP et TCP sur le port 53.
Pour plus d'informations, veuillez consulter [Groupes de sécurité pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) et [Ajout et suppression de règles](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules).
1. Configurez le VPC de votre instance de base de données Amazon RDS for permettre le trafic sortant via le port 53. Votre serveur VPC doit avoir un groupe de sécurité qui contient des règles sortantes permettant le trafic UDP et TCP sur le port 53.
Pour de plus amples informations, veuillez consulter les sections [Groupes de sécurité pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) et [Ajout et suppression de règles](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules) dans le *Guide de l'utilisateur Amazon VPC*.
1. Assurez-vous que le chemin de routage entre l'instance de base de données Amazon RDS et le serveur DNS doit être configuré correctement pour autoriser le trafic DNS.
De plus, si l'instance de base de données Amazon RDS et le serveur DNS ne sont pas dans le même VPC, assurez-vous qu'une connexion d'appairage est établie entre eux. Pour plus d'informations, veuillez consulter [Qu'est-ce que l'appairage de VPC ?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) dans le *Guide d'appairage Amazon VPC*.
# Mises à niveau du moteur de base de données RDS pour PostgreSQL
Vous pouvez gérer deux types de mises à niveau pour votre base de données PostgreSQL :
+ Mises à jour du système d’exploitation : il peut arriver qu’Amazon RDS doive mettre à jour le système d’exploitation sous-jacent de votre base de données afin d’appliquer des correctifs de sécurité ou des modifications du système d’exploitation. Vous pouvez décider quand Amazon RDS applique les mises à jour du système d'exploitation à l'aide de la console RDS, AWS Command Line Interface (AWS CLI) ou de l'API RDS. Pour plus d’informations sur les mises à jour de SE, consultez [Appliquer des mises à jour à un d'instances de base de données](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.OSUpgrades).
+ Mises à niveau du moteur de base de données : quand Amazon RDS prend en charge une nouvelle version d’un moteur de base de données, vous pouvez mettre à niveau vos bases de données vers cette nouvelle version.
Une *base de données* dans ce contexte est une instance de base de données RDS pour PostgreSQL ou un cluster de bases de données multi-AZ.
Il existe deux types de mises à niveau de moteur pour les bases de données PostgreSQL : les mises à niveau des versions majeures et les mises à niveau des versions mineures.
**Mises à niveau de version majeure.**
Les *mises à niveau de version majeure* peuvent contenir des modifications de base de données qui ne sont pas rétrocompatibles avec les applications existantes. Par conséquent, vous devez effectuer manuellement les mises à niveau de version majeure de vos bases de données. Vous pouvez lancer une mise à niveau de version majeure en modifiant votre instance de base de données ou votre cluster de bases de données multi-AZ. Avant d’effectuer une mise à niveau de version majeure, nous vous recommandons de suivre les étapes décrites dans [Choix d’une mise à niveau de version majeure RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).
Amazon RDS gère les mises à niveau des versions majeures multi-AZ des manières suivantes :
+ **Déploiement d’instance de base de données multi-AZ** : Amazon RDS met simultanément à niveau l’instance principale et toutes les instances de secours. Votre base de données peut ne pas être disponible pendant plusieurs minutes, le temps que la mise à niveau soit terminée.
+ Déploiement de cluster de bases de données multi-AZ, RDS met simultanément à niveau les instances de lecteur et d’enregistreur. Votre base de données peut ne pas être disponible pendant plusieurs minutes, le temps que la mise à niveau soit terminée.
Si vous mettez à niveau une instance de base de données qui possède des réplicas en lecture dans la région, Amazon RDS met à niveau les réplicas ainsi que l’instance de base de données principale.
Amazon RDS ne met pas à niveau les réplicas en lecture d'un cluster de bases de données multi-AZ. Si vous effectuez une mise à niveau de version majeure d’un cluster de bases de données multi-AZ, l’état de réplication de ses réplicas en lecture devient **résilié**. Vous devez supprimer et recréer manuellement les réplicas en lecture une fois la mise à niveau terminée.
Vous pouvez minimiser le temps d'arrêt requis pour une mise à niveau de version majeure en utilisant un blue/green déploiement. Pour de plus amples informations, veuillez consulter [Utilisation d'Amazon RDS ( Blue/Green Deployments) pour les mises à jour de bases de données](blue-green-deployments.md).
**Mises à niveau de version mineure.**
En revanche, une *mise à niveau de version mineure* contient uniquement des modifications rétrocompatibles avec les applications existantes. Vous pouvez lancer manuellement une mise à niveau de version mineure en modifiant votre base de données. Vous pouvez également activer l’option **Mise à niveau automatique de versions mineures** lorsque vous créez ou modifiez une base de données. Dans ce cas, Amazon RDS met automatiquement à niveau votre base de données une fois qu’il a testé et approuvé la nouvelle version.
Amazon RDS gère les mises à niveau des versions mineures multi-AZ des manières suivantes :
+ **Déploiement d’instance de base de données multi-AZ** : Amazon RDS met simultanément à niveau l’instance principale et toutes les instances de secours. Votre base de données peut ne pas être disponible pendant plusieurs minutes, le temps que la mise à niveau soit terminée.
+ **Déploiement de cluster de bases de données multi-AZ**, RDS met à niveau toutes les instances de base de données de lecteur à la fois. Ensuite, l’une des instances de base de données de lecteur devient la nouvelle instance de base de données d’enregistreur. Amazon RDS met ensuite à niveau l’ancienne instance d’enregistreur (qui est désormais une instance de lecteur). Les clusters de bases de données multi-AZ réduisent généralement la durée d’indisponibilité des mises à niveau des versions mineures à environ 35 secondes. Lorsqu’ils sont utilisés avec le proxy RDS, ils peuvent encore réduire la durée d’indisponibilité à une seconde ou moins. Pour de plus amples informations, veuillez consulter [Proxy Amazon RDS ](rds-proxy.md). Vous pouvez également utiliser un proxy de base de données open source tel que [ProxySQL](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-of-downtime-with-proxysql-when-upgrading-amazon-rds-multi-az-deployments-with-two-readable-standbys/) ou le pilote [AWS Advanced JDBC](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-downtime-with-the-advanced-jdbc-wrapper-driver-when-upgrading-amazon-rds-multi-az-db-clusters/) Wrapper. [PgBouncer](https://aws.amazon.com/blogs/database/fast-switchovers-with-pgbouncer-on-amazon-rds-multi-az-deployments-with-two-readable-standbys-for-postgresql/)
Si votre base de données utilise des réplicas en lecture, vous devez d’abord mettre à niveau tous les réplicas en lecture avant de mettre à niveau l’instance ou le cluster source.
Pour de plus amples informations, veuillez consulter [Mises à niveau automatiques des versions mineures pour RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.Minor.md). Pour plus d’informations sur l’exécution manuelle d’une mise à niveau de version mineure, consultez [Mise à niveau manuelle de la version du moteur](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
Pour plus d'informations sur les versions du moteur de base de données et la politique de dépréciation des versions du moteur de base de données, consultez la section [Versions du moteur de base](https://aws.amazon.com/rds/faqs/#Database_Engine_Versions) de données sur Amazon RDS. FAQs
**Topics**
+ [
## Considérations relatives aux mises à niveau de PostgreSQL
](#USER_UpgradeDBInstance.PostgreSQL.Considerations)
+ [
## Recherche de cibles de mise à niveau valides
](#USER_UpgradeDBInstance.PostgreSQL.FindingTargets)
+ [
# Numéros de version PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.VersionID.md)
+ [
# Numéros de version RDS dans RDS pour PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.rds.version.md)
+ [
# Choix d’une mise à niveau de version majeure RDS pour PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)
+ [
# Comment effectuer une mise à niveau de version majeure pour RDS pour PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md)
+ [
# Mises à niveau automatiques des versions mineures pour RDS pour PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.Minor.md)
+ [
# Mise à niveau des extensions PostgreSQL dans RDS pour les bases de données RDS pour PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md)
+ [
# Surveillance des mises à niveau du moteur RDS pour PostgreSQL à l'aide d'événements
](USER_UpgradeDBInstance.PostgreSQL.Monitoring.md)
## Considérations relatives aux mises à niveau de PostgreSQL
Pour mettre à niveau vos bases de données en toute sécurité, Amazon RDS utilise l’utilitaire `pg_upgrade` décrit dans la [documentation PostgreSQL](https://www.postgresql.org/docs/current/pgupgrade.html).
Si votre période de rétention des sauvegardes est supérieure à 0, Amazon RDS crée deux instantanés de base de données pendant la mise à niveau. Le premier instantané de base de données porte sur la base de données avant que toute modification de mise à niveau soit apportée. Si la mise à niveau échoue pour vos bases de données, vous pouvez restaurer cet instantané afin de créer une base de données exécutant l’ancienne version. Le second instantané de base de données est pris à la fin de la mise à niveau. Ces instantanés de base de données sont automatiquement supprimés à l’expiration de la période de conservation des sauvegardes.
**Note**
Amazon RDS ne prend des instantanés de base de données pendant le processus de mise à niveau que si vous avez défini la période de conservation des sauvegardes de votre base de données sur un nombre supérieur à 0. Pour modifier la période de conservation des sauvegardes pour une instance de base de données, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md). Vous ne pouvez pas configurer une période de conservation personnalisée des sauvegardes pour un cluster de bases de données multi-AZ.
Quand vous effectuez une mise à niveau de version majeure d’une instance de base de donnée, tous les réplicas en lecture dans la région sont également automatiquement mis à niveau. Une fois que le flux de mise à niveau a démarré, les réplicas en lecture attendent que `pg_upgrade` se termine correctement sur l’instance de base de données principale. Ensuite, la mise à niveau de l’instance de base de données principale attend que les mises à niveau du réplica en lecture se terminent. Vous faites face à une panne tant que la mise à niveau n’est pas terminée. Quand vous effectuez une mise à niveau de version majeure d’un cluster de bases de données multi-AZ, l’état de réplication de ses réplicas en lecture devient **résilié**.
Une fois qu’une mise à niveau est terminée, vous ne pouvez pas rétablir la version précédente du moteur de base de données. Si vous souhaitez revenir à la version précédente, restaurez l’instantané de base de données pris avant la mise à niveau pour créer une nouvelle base de données.
## Recherche de cibles de mise à niveau valides
Lorsque vous utilisez le AWS Management Console pour mettre à niveau une base de données, il indique les cibles de mise à niveau valides pour la base de données. Vous pouvez également utiliser la AWS CLI commande suivante pour identifier les cibles de mise à niveau valides pour une base de données :
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version version-number \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version version-number ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Par exemple, pour identifier les cibles de mise à niveau valides pour une base de données PostgreSQL version 16.1, exécutez la commande suivante : AWS CLI
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version 16.1 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version 16.1 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
# Numéros de version PostgreSQL
La séquence de numérotation des versions du moteur de base de données PostgreSQL est la suivante :
+ Pour les PostgreSQL versions 10 et ultérieures, le format du numéro de version du moteur est *major.minor*. Le numéro de version majeure est la partie entière du numéro de version. Le numéro de version mineure est la partie fractionnaire du numéro de version.
Une mise à niveau de version majeure augmente la partie entière du numéro de version, par exemple la mise à niveau de 10.*mineure* à 11.*mineure*.
+ Pour PostgreSQL versions inférieures à 10, le format du numéro de version du moteur est *major.major.minor*. Le numéro de version majeure du moteur est à la fois l’entier et la première partie fractionnaire du numéro de version. Par exemple, 9.6 est une version majeure. Le numéro de version mineure est la troisième partie du numéro de version. Par exemple, pour la version 9.6.12, le numéro 12 est le numéro de version mineure.
Une mise à niveau majeure augmente la partie majeure du numéro de version. Par exemple, une mise à niveau de la version *9.6*.12 vers la version 11.14 est une mise à niveau de version majeure, *9.6* et *11* étant les numéros des versions majeures.
Pour en savoir plus sur la numérotation des versions de RDS Extended Support, consultez [Dénomination des versions du support étendu Amazon RDS](extended-support-versions.md#extended-support-naming).
# Numéros de version RDS dans RDS pour PostgreSQL
Les numéros de version de RDS utilisent le schéma de dénomination `major.minor.patch`. Une version de correctif RDS inclut des corrections de bogues importantes apportées à une version mineure après sa publication. Pour en savoir plus sur la numérotation des versions de RDS Extended Support, consultez [Dénomination des versions du support étendu Amazon RDS](extended-support-versions.md#extended-support-naming).
Pour identifier le numéro de version Amazon RDS de votre base de données, vous devez d'abord créer l'extension `rds_tools` à l'aide de la commande suivante :
```
CREATE EXTENSION rds_tools;
```
À partir de la version 15.2-R2 de PostgreSQL, vous pouvez déterminer le numéro de version RDS de votre base de données RDS pour PostgreSQL avec la requête SQL suivante :
```
postgres=> SELECT rds_tools.rds_version();
```
Par exemple, l’interrogation d’une base de données RDS pour PostgreSQL 15.2 renvoie ce qui suit :
```
rds_version
----------------
15.2.R2
(1 row)
```
# Choix d’une mise à niveau de version majeure RDS pour PostgreSQL
Les mises à niveau de versions majeures peuvent contenir des modifications qui ne sont pas rétrocompatibles avec les versions précédentes de la base de données. Les nouvelles fonctionnalités peuvent empêcher vos applications existantes de fonctionner correctement. Pour cette raison, Amazon RDS n’applique pas automatiquement les mises à niveau des versions majeures. Pour effectuer une mise à niveau de version majeure, vous modifiez manuellement votre base de données. Veillez à tester soigneusement toute mise à niveau pour vérifier que vos applications fonctionnent correctement avant d'appliquer la mise à niveau à vos bases de données de production. Lorsque vous effectuez une mise à niveau de version majeure de PostgreSQL, nous vous recommandons de suivre les étapes décrites dans [Comment effectuer une mise à niveau de version majeure pour RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
Lorsque vous mettez à niveau une instance de base de données mono-AZ PostgreSQL ou un déploiement d’instance de base de données multi-AZ vers sa prochaine version majeure, tous les réplicas en lecture associés à la base de données sont également mis à niveau vers cette prochaine version majeure. Dans certains cas, vous pouvez passer à une version majeure ultérieure lors de la mise à niveau. Si votre mise à niveau ignore une version majeure, les réplicas en lecture sont également mis à niveau vers cette version majeure cible. Les mises à niveau vers la version 11 qui sautent d’autres versions majeures présentent certaines limitations. Vous trouverez les détails dans les étapes décrites dans la section [Comment effectuer une mise à niveau de version majeure pour RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
La plupart des extensions PostgreSQL ne sont pas mises à jour lors d’une mise à niveau du moteur PostgreSQL. Elles doivent être mises à niveau séparément. Pour de plus amples informations, veuillez consulter [Mise à niveau des extensions PostgreSQL dans RDS pour les bases de données RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
Vous pouvez savoir quelles versions majeures sont disponibles pour votre base de données RDS pour PostgreSQL en exécutant la requête suivante : AWS CLI
```
aws rds describe-db-engine-versions --engine postgres --engine-version your-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Le tableau suivant récapitule les résultats de cette requête pour toutes les versions disponibles. Un astérisque (\$1) sur le numéro de version signifie que cette version n’est plus prise en charge. Si votre version actuelle n’est plus prise en charge, nous vous recommandons d’effectuer une mise à niveau vers la cible de mise à niveau de la version mineure la plus récente ou vers l’une des autres cibles de mise à niveau disponibles pour cette version.
| Version source actuelle | Cibles de mise à niveau |
| --- | --- |
| 17,6 | Aucune |
| 17,5 | [17,6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) |
| 17,4 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) |
| 17.3\$1, 17.2 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) |
| 17.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) |
| 16,10 | [17,6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) |
| 16,9 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16,10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) |
| 16,8 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) |
| 16.7\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16,7 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16,6 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16.5\$1, 16.4 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) |
| 16,3 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) |
| 16.2\$1, 16.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) |
| 15,14 | [17,6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16,10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) |
| 15,13 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15,14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) |
| 15.12, 15.11\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) |
| 15,10 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) |
| 15.9\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) |
| 15,8 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) |
| 15,7 | [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version167), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version165), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) |
| 15.6\$1, 15.5\$1, 15.4\$1, 15.3\$1, 15.2\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) |
| 14,19 | [17,6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16,10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [15,14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) |
| 14,18 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14,19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) |
| 14.17, 14.16\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) |
| 14,15 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) |
| 14.14\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) |
| 14,13 | [16,4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1416), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414) |
| 14,12 | [16,3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1416), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) |
| 14.11\$1, 14.10\$1, 14.9\$1, 14.8\$1, 14.7\$1, 14.6\$1, 14.5\$1, 14.4\$1, 14.3\$1, 14.2\$1, 14.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) |
| 13,22 | [17,6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16,10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [15,14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) [14,19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) |
| 13,21 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13,22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322) |
| 13.20, 13.19\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) |
| 13.18, 13.17\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) |
| 13,16 | [16,4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15,8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1319), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1317) |
| 13,15 | [16,3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1319), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1317), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) |
| 13.14\$1, 13.13\$1, 13.12\$1, 13.11\$1, 13.10\$1, 13.9\$1, 13.8\$1, 13.7\$1, 13.6\$1, 13.5\$1, 13.4\$1, 13.3\$1, 13.2\$1, 13.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) |
| 12.22-rds.20250508 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) |
| 12.22-rds.20250220 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.22, 12.21\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318) [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.20\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.19\$1, 12.18\$1, 12.17\$1, 12.16\$1, 12.15\$1, 12.14\$1, 12.13\$1, 12.12\$1, 12.11\$1, 12.10\$1, 12.9\$1, 12.8\$1, 12.7\$1, 12.6\$1, 12.5\$1, 12.4\$1, 12.3\$1, 12.2\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 11.22-rds.20250508 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 11.22-rds.20250220 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
| 11.22-rds.20240509 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20240808](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240808), [11.22-rds.20241121](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20241121), [11.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250220), [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
| 11.22, 11.21\$1, 11.20\$1, 11.19\$1, 11.18\$1, 11.17\$1, 11.16\$1, 11.15\$1, 11.14\$1, 11.13\$1, 11.12\$1, 11.11\$1, 11.10\$1, 11.9\$1, 11.8\$1, 11.7\$1, 11.6\$1, 11.5\$1, 11.4\$1, 11.2\$1, 11.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20240418](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240418), [11.22-rds.20240509](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240509), [11.22-rds.20240808](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240808), [11.22-rds.20241121](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20241121), [11.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250220), [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
\$1 Cette version n’est plus prise en charge.
# Comment effectuer une mise à niveau de version majeure pour RDS pour PostgreSQL
Nous vous recommandons le processus suivant lors d’une mise à niveau de version majeure sur une base de données Amazon RDS pour PostgreSQL :
1. **Préparez un groupe de paramètres compatible avec la version** – Si vous utilisez un groupe de paramètres personnalisé, vous avez deux options. Vous pouvez spécifier un groupe de paramètres par défaut pour la nouvelle version du moteur de base de données. Ou vous pouvez créer votre propre groupe de paramètres personnalisé pour la nouvelle version du moteur de base de données Pour plus d’informations, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md) et [Utilisation des groupes de paramètres de clusters de bases de données pour les clusters de bases de données Multi-AZ](USER_WorkingWithDBClusterParamGroups.md).
1. **Vérifiez les classes de bases de données non prises en charge** : vérifiez que la classe d’instances de votre base de données est compatible avec la version PostgreSQL vers laquelle vous effectuez la mise à niveau. Pour de plus amples informations, veuillez consulter [Moteurs de base de données pris en charge pour les classes d’instance de base de données](Concepts.DBInstanceClass.Support.md).
1. **Recherchez une utilisation non prise en charge :**
+ **Transactions préparées** : validez ou restaurez toutes les transactions préparées ouvertes avant d’essayer d’effectuer une mise à niveau.
Vous pouvez utiliser la requête suivante pour vérifier qu’aucune transaction préparée ouverte ne figure sur votre base de données.
```
SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
```
+ **Types de données Reg\$1** : 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_upgrade` ne peut pas conserver ce type de données, qui est utilisé par Amazon RDS pour effectuer la mise à niveau.
Pour vérifier l’absence de toute utilisation des types de données *reg\$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');
```
1. **Vérifiez la présence de bases de données non valides :**
+ Assurez-vous qu’aucune base de données n’est pas valide. 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;
```
+ La requête précédente renvoie des noms de base de données non valides. Vous pouvez utiliser `DROP DATABASE invalid_db_name;` pour supprimer les bases de données non valides. Vous pouvez également utiliser la commande suivante pour supprimer les bases de données non valides :
```
SELECT 'DROP DATABASE ' || quote_ident(datname) || ';' FROM pg_database WHERE datconnlimit = -2 \gexec
```
Pour plus d’informations sur les bases de données non valides, consultez [Comprendre le comportement de l’autovacuum avec les bases de données non valides](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/appendix.postgresql.commondbatasks.autovacuumbehavior.html).
1. **Traitez les emplacements de réplication logique** : une mise à niveau ne peut pas se produire si la base de données possède des emplacements de réplication logique. Les emplacements de réplication logique sont généralement utilisés pour la migration AWS DMS et la réplication de tables de la base de données vers des lacs de données, des outils BI et d’autres cibles. Avant de procéder à la mise à niveau, assurez-vous de connaître l’objectif des emplacements de réplication logique utilisés et confirmez qu’il est possible de les supprimer. Si les emplacements de réplication logique sont toujours utilisés, vous ne devez pas les supprimer et vous ne pouvez pas procéder à la mise à niveau.
Si les emplacements de réplication logique ne sont pas nécessaires, vous pouvez les supprimer à l’aide du code SQL suivant :
```
SELECT * FROM pg_replication_slots WHERE slot_type NOT LIKE 'physical';
SELECT pg_drop_replication_slot(slot_name);
```
Les installations de réplication logique qui utilisent l’extension `pglogical` doivent également avoir des emplacements supprimés pour une mise à niveau de version majeure réussie. Pour obtenir des informations sur la façon d’identifier et de supprimer les emplacements créés à l’aide de l’extension `pglogical`, consultez [Gestion des emplacements de réplication logiques pour pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md).
Dans les versions source 17 et ultérieures, les emplacements de réplication logique activés non-read-replicas peuvent être conservés par le biais de mises à niveau. Les emplacements de réplication logique créés sur les répliques en lecture ne sont pas conservés lors des mises à niveau.
Assurez-vous que toutes les transactions et tous les messages de décodage logique ont été consommés depuis le slot avant de lancer la mise à niveau. Si des fichiers journaux d'écriture anticipée (WAL) non consommés sont détenus par des emplacements de réplication logique, la mise à niveau échouera avec un message identifiant les emplacements problématiques. Consultez la documentation de [PostgreSQL pour plus de détails](https://www.postgresql.org/docs/current/logical-replication-upgrade.html).
Sur les clusters multi-AZ dont les versions source sont antérieures à 17.8 ou 18.2, assurez-vous que cette `flow_control` option est désactivée. Pour plus d'informations, voir Activation [et désactivation du contrôle de flux pour les clusters de bases de données multi-AZ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html#multi-az-db-clusters-concepts-replica-lag). Vous pouvez désactiver le contrôle de flux en supprimant l'extension de `shared_preload_libraries` et en redémarrant votre instance de base de données.
1. **Traitez les réplicas en lecture** : une mise à niveau d’une instance de base de données mono-AZ ou d’un déploiement d’instance de base de données multi-AZ met également à niveau les réplicas en lecture dans la région ainsi que l’instance de base de données principale. Amazon RDS ne met pas à niveau les réplicas en lecture d'un cluster de bases de données multi-AZ.
Vous ne pouvez pas mettre à niveau les réplicas en lecture séparément. Si vous le pouviez, cela pourrait conduire à des situations où les bases de données principale et de réplica auraient des versions majeures différentes de PostgreSQL. Toutefois, les mises à niveau de réplica en lecture peuvent augmenter la durée d’indisponibilité sur l’instance de base de données principale. Pour éviter la mise à niveau d’un réplica en lecture, promouvez le réplica en instance autonome ou supprimez-le avant de démarrer le processus de mise à niveau.
Le processus de mise à niveau recrée le groupe de paramètres du réplica en lecture en fonction du groupe de paramètres actuel du réplica en lecture. Vous pouvez appliquer un groupe de paramètres personnalisé à un réplica en lecture uniquement une fois la mise à niveau terminée en modifiant le réplica en lecture. Pour plus d’informations sur les réplicas en lecture, consultez [Utilisation de réplicas en lecture pour Amazon RDS pour PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md).
1. **Gérer des objets volumineux** : dans PostgreSQL, les objets volumineux (également appelés) sont utilisés pour stocker et gérer des objets binaires volumineux (tels BLOBs que des fichiers, des images, des vidéos, etc.) dont la taille est supérieure à la taille maximale autorisée pour les types de données de colonne classiques. Pour plus d'informations, consultez la documentation de [PostgreSQL Large Objects](https://www.postgresql.org/docs/current/largeobjects.html).
Une mise à niveau peut manquer de mémoire et échouer s'il existe des millions d'objets volumineux et que l'instance ne peut pas les gérer pendant une mise à niveau. Le processus de mise à niveau de la version majeure de PostgreSQL comprend deux grandes phases : le vidage du schéma via pg\$1dump et sa restauration via pg\$1restore. Si votre base de données contient des millions d'objets volumineux, vous devez vous assurer que votre instance dispose de suffisamment de mémoire pour gérer les fichiers pg\$1dump et pg\$1restore lors d'une mise à niveau et pour les adapter à un type d'instance plus important.
Avant de commencer une mise à niveau, vérifiez si votre base de données contient des objets volumineux. Le catalogue `pg_largeobject_metadata` contient des métadonnées associées à des objets de grande taille. Les données réelles des objets volumineux sont stockées dans`pg_largeobject`. Utilisez la requête suivante pour vérifier le nombre d'objets de grande taille :
```
SELECT count(*) FROM pg_largeobject_metadata;
```
Pour nettoyer des objets volumineux existants ou des objets volumineux orphelins, voir [Gestion des objets volumineux avec le module lo](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL_large_objects_lo_extension.html).
Lorsque vous planifiez une mise à niveau de version majeure, nous vous recommandons d'utiliser un type d'instance doté d'au moins 32 Go de mémoire si votre base de données contient 25 à 30 millions d'objets volumineux. Cette recommandation est basée sur nos tests et peut varier en fonction de votre charge de travail spécifique et de la configuration de votre base de données. Si votre base de données inclut des objets supplémentaires (tels que des tables, des index ou des vues matérialisées), nous vous recommandons de sélectionner un type d'instance plus grand afin de garantir des performances optimales pendant le processus de mise à niveau.
1. **Gérez les intégrations zéro ETL** : si vous avez une [intégration zéro ETL](zero-etl.md) existante, [supprimez-la](zero-etl.deleting.md) avant d’effectuer une mise à niveau de version majeure. Ensuite, une fois la mise à niveau terminée, recréez l’intégration.
Sur les versions source majeures 17 et supérieures, l'intégration zéro ETL peut être conservée lors de la mise à niveau.
1. **Effectuez une sauvegarde** : nous vous recommandons d’effectuer une sauvegarde avant d’effectuer la mise à niveau de version majeure, afin de disposer d’un point de restauration connu pour votre base de données. Si la période de conservation des sauvegardes est supérieure à 0, le processus de mise à niveau crée des instantanés de base de données de votre base de données avant et après la mise à niveau. Pour modifier la période de rétention des sauvegardes, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md) et [Modification d’un cluster de bases de données multi-AZ pour Amazon RDS](modify-multi-az-db-cluster.md).
Pour effectuer une sauvegarde manuellement, consultez [Création d’un instantané de base de données pour une instance de base de données mono-AZ pour Amazon RDS](USER_CreateSnapshot.md) et [Création d’un instantané de cluster de bases de données multi-AZ pour Amazon RDS](USER_CreateMultiAZDBClusterSnapshot.md).
1. **Mise à niveau de certaines extensions avant une mise à niveau de version majeure** : si vous envisagez d’omettre une version majeure avec la mise à niveau, vous devez mettre à jour certaines extensions *avant* d’effectuer la mise à niveau de version majeure. Par exemple, la mise à niveau des versions 9.5.x ou 9.6.x vers une version 11.x entraîne une omission de la version majeure. Les extensions à mettre à jour comprennent PostGIS et les extensions connexes pour le traitement des données spatiales.
+ `address_standardizer`
+ `address_standardizer_data_us`
+ `postgis_raster`
+ `postgis_tiger_geocoder`
+ `postgis_topology`
Vous ne pouvez pas effectuer de mise à niveau directe vers PostgreSQL version 17 si vous utilisez `rdkit` version 4.6.0 ou inférieure, et PostgreSQL versions 16 et inférieure, en raison d’une incompatibilité `rdkit`. Voici les options de mise à niveau :
+ Si vous utilisez PostgreSQL versions 13 et inférieures, vous devez d’abord effectuer une mise à niveau majeure vers les versions 14.14 et 14 ultérieures, les versions 15.9 et 15 ultérieures, ou les versions 16.5 et 16 ultérieures, puis effectuer la mise à niveau de version vers PostgreSQL 17.
+ Si vous utilisez PostgreSQL versions 14, 15 ou 16, vous devez d’abord effectuer une mise à niveau mineure vers les versions 14.14 et 14 ultérieures, les versions 15.9 et 15 ultérieures, ou les versions 16.5 et 16 ultérieures, puis effectuer la mise à niveau de version vers PostgreSQL 17.
Exécutez la commande suivante pour chaque extension que vous utilisez :
```
ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';
```
Pour de plus amples informations, veuillez consulter [Mise à niveau des extensions PostgreSQL dans RDS pour les bases de données RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.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. **Supprimer certaines extensions avant la mise à niveau de la version majeure** : les extensions qui ne sont pas prises en charge sur la version cible doivent être supprimées, sinon la mise à niveau échouera.
L'`plrust`extension est supprimée à partir de RDS PostgreSQL 18. [L'`postgis_topology`extension n'est pas disponible sur les versions 18.1 et 18.2 de RDS PostgreSQL en raison de problèmes connus [1], [[](https://trac.osgeo.org/postgis/ticket/5983)2].](https://trac.osgeo.org/postgis/ticket/6016) Ces extensions doivent être supprimées avant la mise à niveau.
Une mise à niveau qui ignore une version majeure vers la version 11.x ne prend pas en charge la mise à jour de l'`pgRouting`extension. La mise à niveau des versions 9.4.x, 9.5.x ou 9.6.x vers les versions 11.x entraîne l’omission d’une version majeure. Il est plus sûr de supprimer l’extension `pgRouting` puis de la réinstaller sur une version compatible une fois la mise à niveau effectuée. Pour connaître les versions d’extension vers lesquelles vous pouvez effectuer une mise à jour, consultez [Versions de l'extension PostgreSQL prises en charge](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md).
Les extensions `tsearch2` et `chkpass` ne sont plus prises en charge pour PostgreSQL versions 11 ou ultérieures.
Vous pouvez vérifier si une extension est installée à l'aide de la requête suivante :
```
SELECT * FROM pg_extension WHERE extname in ('extension_name');
```
1. **Supprimer les types de données inconnus** – Supprimez les types de données `unknown` en fonction de la version cible.
PostgreSQL version 10 a cessé de prendre en charge le type de données `unknown`. Si une base de données version 9.6 utilise le type de données `unknown`, une mise à niveau vers une version 10 affiche un message d’erreur tel que :
```
Database instance is in a state that cannot be upgraded: PreUpgrade checks failed:
The instance could not be upgraded because the 'unknown' data type is used in user tables.
Please remove all usages of the 'unknown' data type and try again."
```
Pour rechercher le type de données `unknown` dans votre base de données afin de pouvoir supprimer la colonne incriminée ou la remplacer par un type de données pris en charge, utilisez le code SQL suivant :
```
SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';
```
1. **Réalisez un essai de mise à niveau** : nous vous recommandons fortement de tester la mise à niveau de version majeure sur un doublon de votre base de données de production avant d’essayer d’effectuer la mise à niveau sur votre base de données de production. Vous pouvez surveiller les plans d’exécution sur la base de données de test dupliquée pour détecter d’éventuelles régressions du plan d’exécution et évaluer ses performances. Pour créer une instance de test dupliquée, vous pouvez soit restaurer votre base de données à partir d'un instantané récent, soit point-in-time restaurer votre base de données à sa date de restauration la plus récente.
Pour plus d’informations, consultez [Restaurer à partir d’un instantané](USER_RestoreFromSnapshot.md#USER_RestoreFromSnapshot.Restoring) ou [Restauration d’une instance de base de données à un instant précis pour Amazon RDS](USER_PIT.md). Pour les clusters de bases de données multi-AZ, consultez [Restauration d'un instantané dans un cluster de base de données multi-AZ](USER_RestoreFromMultiAZDBClusterSnapshot.Restoring.md) ou [Restauration d'un cluster de base de données multi-AZ à une date définie](USER_PIT.MultiAZDBCluster.md).
Pour en savoir plus sur la procédure de mise à niveau, consultez [Mise à niveau manuelle de la version du moteur](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
Lors de la mise à niveau d’une base de données de version 9.6 vers la version 10, sachez que PostgreSQL 10 active les requêtes parallèles par défaut. Vous pouvez tester l’impact du parallélisme *avant* la mise à niveau en modifiant le paramètre `max_parallel_workers_per_gather` sur votre base de données de test et en spécifiant 2.
**Note**
La valeur par défaut du paramètre `max_parallel_workers_per_gather` dans le groupe de paramètres de base de données `default.postgresql10` est 2.
Pour plus d’informations, consultez [Parallel Query](https://www.postgresql.org/docs/10/parallel-query.html) dans la documentation PostgreSQL. Pour désactiver le parallélisme sur la version 10, définissez le paramètre `max_parallel_workers_per_gather` sur 0.
Durant la mise à niveau de version majeure, les bases de données `public` et `template1`, ainsi que le schéma `public` figurant dans chaque base de données, sont renommés temporairement. Ces objets apparaissent dans les journaux avec leur nom d’origine et une chaîne aléatoire ajoutée. Cette chaîne est ajoutée afin que les paramètres personnalisés tels que `locale` et `owner` soient conservés au cours de la mise à niveau de version majeure. À la fin de la mise à niveau, les objets reprennent leurs noms d’origine.
**Note**
Pendant le processus de mise à niveau de la version majeure, vous ne pouvez pas point-in-time restaurer votre instance de base de données ou votre cluster de base de données multi-AZ. Une fois qu’Amazon RDS a effectué la mise à niveau, le service réalise une sauvegarde automatique de la base de données. Vous pouvez effectuer une point-in-time restauration avant le début de la mise à niveau et une fois la sauvegarde automatique de votre base de données terminée.
1. **Résolvez les problèmes si une mise à niveau échoue avec des erreurs de procédure de pré-vérification** : au cours du processus de mise à niveau de version majeure, Amazon RDS pour PostgreSQL exécute d’abord une procédure de pré-vérification pour identifier les éventuels problèmes pouvant provoquer un échec de la mise à niveau. Le procédure de pré-vérification recherche les éventuelles conditions d’incompatibilité entre toutes les bases de données de l’instance.
Si la pré-vérification détecte un problème, elle crée un événement de journal indiquant l’échec de la pré-vérification de mise à niveau. Les détails de la procédure de pré-vérification se trouvent dans un journal de mise à niveau nommé `pg_upgrade_precheck.log` pour toutes les bases de données d’une base de données. Amazon RDS ajoute un horodatage au nom du fichier. Pour plus d’informations sur l’affichage des journaux, consultez [Surveillance des fichiers journaux Amazon RDS](USER_LogAccess.md).
Si la mise à niveau d’un réplica en lecture échoue au stade de la vérification préalable, la réplication sur le réplica en lecture défaillant est interrompue et le réplica en lecture est mis à l’état résilié. Supprimez le réplica en lecture et recréez un nouveau réplica en lecture basé sur l'instance de base de données principale mise à niveau.
Résolvez tous les problèmes identifiés dans le journal de pré-vérification puis relancez la mise à niveau de version majeure. Voici un exemple de journal de pré-vérification.
```
------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with the requested major engine version upgrade and try the upgrade again.
* There are uncommitted prepared transactions. Please commit or rollback all prepared transactions.* One or more role names start with 'pg_'. Rename all role names that start with 'pg_'.
* The following issues in the database 'my"million$"db' need to be corrected before upgrading:** The ["line","reg*"] data types are used in user tables. Remove all usage of these data types.
** The database name contains characters that are not supported by RDS for PostgreSQL. Rename the database.
** The database has extensions installed that are not supported on the target database version. Drop the following extensions from your database: ["tsearch2"].
* The following issues in the database 'mydb' need to be corrected before upgrading:** The database has views or materialized views that depend on 'pg_stat_activity'. Drop the views.
```
1. **Si une mise à niveau de réplica en lecture échoue lors de la mise à niveau de la base de données, résolvez le problème** : un réplica en lecture ayant échoué obtient le statut `incompatible-restore` et la réplication est arrêtée sur la base de données. Supprimez le réplica en lecture et recréez un nouveau réplica en lecture basé sur l'instance de base de données principale mise à niveau.
**Note**
Amazon RDS ne met pas à niveau les réplicas en lecture pour les clusters de bases de données multi-AZ. Si vous effectuez une mise à niveau de version majeure sur un cluster de bases de données multi-AZ, l’état de réplication de ses réplicas en lecture devient **résilié**.
Une mise à niveau de réplica en lecture peut échouer pour les raisons suivantes :
+ Elle n’a pas pu s’aligner sur l’instance de base de données principale même après un temps d’attente.
+ Elle était dans un état de mise hors service ou de cycle de vie incompatible, tel que storage-full, incompatible-restore, etc.
+ Lorsque la mise à niveau de l’instance de base de données principale a démarré, une mise à niveau de version mineure distincte était en cours d’exécution sur le réplica en lecture.
+ Le réplica en lecture utilisait des paramètres incompatibles.
+ Le réplica en lecture n’a pas pu communiquer avec l’instance de base de données principale pour synchroniser le dossier de données.
1. **Mettez à niveau votre base de données de production** : quand l’essai de mise à niveau de version majeure est un succès, vous devez être en mesure de mettre à niveau en toute confiance votre base de données de production. Pour de plus amples informations, veuillez consulter [Mise à niveau manuelle de la version du moteur](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
1. 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 bases de données PostgreSQL. Les statistiques de l’optimiseur ne sont pas transférées lors d’une mise à niveau majeure de la version. Vous devez donc régénérer toutes les statistiques pour éviter les problèmes de performances. Exécutez la commande sans paramètres pour générer des statistiques pour toutes les tables normales de la base de données actuelle, comme suit :
```
ANALYZE VERBOSE;
```
L’indicateur `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.
Une fois la mise à niveau de version majeure effectuée, nous vous recommandons d’effectuer les tâches suivantes :
+ Une mise à niveau de PostgreSQL ne met à niveau aucune extension PostgreSQL. Pour mettre à niveau les extensions, veuillez consulter [Mise à niveau des extensions PostgreSQL dans RDS pour les bases de données RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
+ Vous pouvez utiliser Amazon RDS pour consulter deux journaux générés par l’utilitaire `pg_upgrade`. Il s’agit des journaux `pg_upgrade_internal.log` et `pg_upgrade_server.log`. Amazon RDS ajoute un horodatage au nom de fichier de ces journaux. Vous pouvez consultez ces journaux comme tout autre journal. Pour de plus amples informations, veuillez consulter [Surveillance des fichiers journaux Amazon RDS](USER_LogAccess.md).
Vous pouvez également télécharger les journaux de mise à niveau sur Amazon CloudWatch Logs. Pour de plus amples informations, veuillez consulter [Publication de journaux PostgreSQL sur Amazon Logs CloudWatch](USER_LogAccess.Concepts.PostgreSQL.md#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs).
+ Pour vérifier si tout fonctionne comme prévu, testez votre application sur la base de données mise à niveau avec une charge de travail similaire. Une fois la mise à niveau vérifiée, vous pouvez supprimer l’instance de test.
# Mises à niveau automatiques des versions mineures pour RDS pour PostgreSQL
Si vous activez l’option **Mise à niveau automatique des versions mineures** au moment de créer ou modifier une instance de base de données ou un cluster de bases de données multi-AZ, votre base de données peut être mise à niveau automatiquement.
Amazon RDS prend également en charge la politique de déploiement des mises à niveau afin de gérer les mises à niveau automatiques des versions mineures sur plusieurs ressources de base de données et. Comptes AWS Pour de plus amples informations, veuillez consulter [Utilisation de la politique de déploiement des mises à AWS Organizations niveau pour les mises à niveau automatiques des versions mineures](RDS.Maintenance.AMVU.UpgradeRollout.md).
Pour chaque version majeure de RDS pour PostgreSQL, une seule version mineure est désignée par RDS comme étant la version de mise à niveau automatique. Une fois qu'une version mineure a été testée et approuvée par Amazon RDS, la mise à niveau de la version mineure se produit automatiquement pendant votre fenêtre de maintenance. RDS ne définit pas automatiquement les dernières versions mineures publiées comme version de mise à niveau automatique. Avant de désigner une publication de version récente comme version de mise à niveau automatique, RDS prend en compte plusieurs critères, à savoir :
+ Problèmes de sécurité connus
+ Bogues dans la version de la communauté PostgreSQL
+ Stabilité globale du parc depuis la publication de la version mineure
Vous pouvez utiliser la AWS CLI commande suivante pour déterminer la version cible de mise à niveau mineure automatique actuelle pour une version mineure de PostgreSQL spécifiée dans une version spécifique. Région AWS
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version minor-version \
--region region \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output text
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version minor-version ^
--region region ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output text
```
Par exemple, la AWS CLI commande suivante détermine la cible de mise à niveau mineure automatique pour la version mineure 16.1 de PostgreSQL dans l'est des États-Unis (Ohio) (us-east-2) Région AWS .
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version 16.1 \
--region us-east-2 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output table
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version 16.1 ^
--region us-east-2 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output table
```
Votre sortie est similaire à ce qui suit.
```
----------------------------------
| DescribeDBEngineVersions |
+--------------+-----------------+
| AutoUpgrade | EngineVersion |
+--------------+-----------------+
| False | 16.2 |
| True | 16.3 |
| False | 16.4 |
| False | 16.5 |
| False | 16.6 |
| False | 17.1 |
| False | 17.2 |
+--------------+-----------------+
```
Dans cet exemple, la valeur de `AutoUpgrade` est `True` pour PostgreSQL version 16.3. Ainsi, la cible de mise à niveau automatique mineure est la version 16.3 de PostgreSQL, comme indiqué dans la sortie.
Une base de données PostgreSQL est automatiquement mise à niveau au cours de votre fenêtre de maintenance si les critères suivants sont réunis :
+ L’option **Mise à niveau automatique des versions mineures** est activée pour la base de données.
+ La base de données exécute une version mineure du moteur de base de données qui est inférieure à la version mineure de la mise à niveau automatique actuelle.
Pour de plus amples informations, veuillez consulter [Mise à niveau automatique de la version mineure du moteur](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades).
**Note**
Une mise à niveau de PostgreSQL ne met pas à niveau les extensions PostgreSQL. Pour mettre à niveau les extensions, veuillez consulter [Mise à niveau des extensions PostgreSQL dans RDS pour les bases de données RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
# Mise à niveau des extensions PostgreSQL dans RDS pour les bases de données RDS pour PostgreSQL
Une mise à niveau du moteur PostgreSQL ne met pas à niveau la plupart des extensions PostgreSQL. Pour mettre à jour une extension après une mise à niveau de version, utilisez la commande `ALTER EXTENSION UPDATE`.
**Note**
Pour plus d’informations sur la mise à jour de l’extension PostGIS, consultez [Gestion des données spatiales avec l’extension PostGIS](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 la 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 à niveau une extension, utilisez la commande suivante.
```
ALTER EXTENSION extension_name UPDATE TO 'new_version';
```
Pour voir la liste des versions prises en charge des extensions PostgreSQL, consultez [Versions de l'extension PostgreSQL prises en charge](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md).
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;
```
# Surveillance des mises à niveau du moteur RDS pour PostgreSQL à l'aide d'événements
Lorsque vous mettez à niveau la version du moteur d'une base de données RDS pour PostgreSQL, Amazon RDS émet un événement spécifique à chaque phase du processus. Pour suivre la progression d'une mise à niveau, vous pouvez consulter ces événements ou vous y abonner.
Pour plus d'informations sur les événements RDS, consultez[Surveillance des événements Amazon RDS](working-with-events.md).
Pour obtenir des informations détaillées sur un événement Amazon RDS spécifique qui se produit lors de la mise à niveau de votre moteur, consultez[Catégories d'événements Amazon RDS et messages d'événements ](USER_Events.Messages.md).
# Mise à niveau d'une version du moteur d'instantané de base de données PostgreSQL
Amazon RDS vous permet de créer un instantané de base de données de volume de stockage de votre instance de base de données PostgreSQL. Lorsque vous créez un instantané de base de données, l’instantané est basé sur la version du moteur utilisée par votre instance Amazon RDS. Vous pouvez mettre à niveau la version du moteur pour vos instantanés de base de données.
Après avoir restauré un instantané de base de données mis à niveau vers une nouvelle version de moteur, veillez à vérifier que la mise à jour est réussie. Pour plus d’informations sur une mise à niveau des versions majeures, consultez [Mises à niveau du moteur de base de données RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md). Pour savoir comment restaurer un instantané de base de données, consultez [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md).
Vous pouvez mettre à niveau des instantanés de base de données manuels chiffrés ou non chiffrés.
Pour afficher les versions de moteur disponibles pour votre instantané de base de données RDS pour PostgreSQL, utilisez l'exemple suivant. AWS CLI
```
aws rds describe-db-engine-versions --engine postgres --engine-version example-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text --include-all
```
Pour plus d’informations sur les versions de moteur disponibles pour les instantanés de base de données RDS pour PostgreSQL, consultez [Choix d’une mise à niveau de version majeure RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).
**Note**
Vous ne pouvez pas mettre à niveau des instantanés DB automatisés qui sont créés lors du processus de sauvegarde automatique.
## Console
**Pour mettre à niveau un instantané de base 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 **Snapshots**.
1. Choisissez l’instantané que vous souhaitez mettre à niveau.
1. Pour **Actions**, choisissez **Upgrade Snapshot (Mettre à niveau l’instantané)**. La page **Upgrade Snapshot (Mettre à niveau l’instantané)** s’affiche.
1. Choisissez la **New engine version (Version du nouveau moteur)** vers laquelle mettre à niveau.
1. Choisissez **Save changes (Enregistrer les changements)** pour mettre à niveau l’instantané.
Pendant le processus de mise à niveau, toutes les actions d’instantané sont désactivées pour l’instantané de base de données. De même, le statut de l'instantané de base de données passe de **disponible** à **upgrading (mise à niveau)**, puis passe à **active**, une fois la mise à niveau terminée. Si l'instantané de base de données ne peut pas être mis à jour en raison d'un problème d'instantané endommagé, le statut devient **indisponible**. Vous ne pouvez pas récupérer l’instantané lorsqu’il a ce statut.
**Note**
Si la mise à niveau de l’instantané de base de données échoue, l’instantané revient à l’état d’origine avec la version originale.
## AWS CLI
Pour mettre à niveau un instantané de base de données vers une nouvelle version du moteur de base de données, utilisez la AWS CLI [modify-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot.html)commande.
**Parameters**
+ `--db-snapshot-identifier` : l’identifiant de l’instantané de base de données à mettre à niveau. L’identifiant doit être unique pour un Amazon Resource Name (ARN). Pour plus d'informations, consultez [Amazon Resource Names (ARN) dans Amazon RDS](USER_Tagging.ARN.md).
+ `--engine-version` : la version du moteur vers laquelle la mise à niveau de l’instantané de base de données doit être effectuée.
**Example**
Pour Linux, macOS ou Unix :
```
1. aws rds modify-db-snapshot \
2. --db-snapshot-identifier my_db_snapshot \
3. --engine-version new_version
```
Pour Windows :
```
1. aws rds modify-db-snapshot ^
2. --db-snapshot-identifier my_db_snapshot ^
3. --engine-version new_version
```
## API RDS
Pour mettre à niveau un instantané de base de données vers une nouvelle version du moteur de base de données, appelez l'DBSnapshotopération Amazon RDS API [Modify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshot.html).
+ `DBSnapshotIdentifier` : l’identifiant de l’instantané de base de données à mettre à niveau. L’identifiant doit être unique pour un Amazon Resource Name (ARN). Pour plus d'informations, consultez [Amazon Resource Names (ARN) dans Amazon RDS](USER_Tagging.ARN.md).
+ `EngineVersion` : la version du moteur vers laquelle la mise à niveau de l’instantané de base de données doit être effectuée.
# Utilisation de réplicas en lecture pour Amazon RDS pour PostgreSQL
Vous pouvez mettre à l’échelle les opérations de lecture des instances de base de données Amazon RDS pour PostgreSQL en ajoutant des réplicas en lecture aux instances. Comme pour les autres moteurs de base de données Amazon RDS, RDS pour PostgreSQL utilise les mécanismes de réplication natifs de PostgreSQL pour maintenir les réplicas en lecture à jour avec les modifications apportées à la base de données source. Pour obtenir des informations générales sur les réplicas en lecture et Amazon RDS, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Ensuite, vous trouverez des informations propres à l’utilisation des réplicas en lecture avec RDS pour PostgreSQL.
## Limites des réplicas en lecture avec PostgreSQL
Les limites des réplicas en lecture pour PostgreSQL sont les suivantes :
+ Les réplicas en lecture PostgreSQL sont en lecture seule. Bien qu’un réplica en lecture ne soit pas une instance de base de données accessible en écriture, vous pouvez le promouvoir en instance de base de données RDS pour PostgreSQL autonome. Toutefois, le processus n'est pas réversible.
+ Vous ne pouvez pas créer de réplica en lecture à partir d’un autre réplica en lecture si votre instance de base de données RDS pour PostgreSQL exécute une version de PostgreSQL antérieure à 14.1. RDS pour PostgreSQL prend en charge les réplicas en lecture en cascade sur RDS pour PostgreSQL version 14.1 et versions ultérieures uniquement. Pour de plus amples informations, veuillez consulter [Utilisation de réplicas en lecture en cascade avec RDS pour PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Si vous promouvez un réplica en lecture PostgreSQL, il devient une instance de base de données accessible en écriture. Il arrête de recevoir les fichiers WAL (write-ahead log) d'une instance de base de données source, et n'est plus une instance en lecture seule. Vous pouvez créer des réplicas en lecture à partir de l’instance de base de données promue comme pour n’importe quelle instance de base de données RDS pour PostgreSQL. Pour de plus amples informations, veuillez consulter [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
+ Si vous promouvez un réplica en lecture PostgreSQL depuis une chaîne de réplication (une série de réplicas en lecture en cascade), tous les réplicas en lecture en aval existants continuent de recevoir automatiquement des fichiers WAL de l’instance promue. Pour de plus amples informations, veuillez consulter [Utilisation de réplicas en lecture en cascade avec RDS pour PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Si aucune transaction utilisateur n'est en cours d'exécution sur l'instance de base de données source, le réplica en lecture PostgreSQL associé signale un retard de réplication pouvant atteindre cinq minutes. Le décalage de réplication est calculé comme `currentTime - lastCommitedTransactionTimestamp`. Cela signifie que lorsqu'aucune transaction n'est traitée, la valeur du décalage de réplication augmente pendant un certain temps jusqu'à ce que le segment WAL (journal d'écriture anticipée) bascule. Par défaut, RDS pour PostgreSQL change le segment WAL toutes les cinq minutes, ce qui entraîne l’enregistrement d’une transaction et une diminution du décalage signalé.
+ Vous ne pouvez pas activer les sauvegardes automatiques pour les réplicas en lecture PostgreSQL pour les versions de RDS pour PostgreSQL antérieures à 14.1. Les sauvegardes automatiques pour les réplicas en lecture sont prises en charge pour RDS pour PostgreSQL 14.1 et versions ultérieures uniquement. Pour RDS pour PostgreSQL 13 et versions antérieures, créez un instantané à partir d’un réplica en lecture si vous souhaitez en obtenir une sauvegarde.
+ Point-in-time la restauration (PITR) n'est pas prise en charge pour les répliques en lecture. Vous pouvez utiliser PITR avec une instance principale (enregistreur) uniquement, pas avec un réplica en lecture. Pour en savoir plus, consultez [Restauration d’une instance de base de données à un instant précis pour Amazon RDS](USER_PIT.md).
+ Les réplicas en lecture pour les versions 12 et inférieures de PostgreSQL redémarrent automatiquement pendant la fenêtre de maintenance de 60 à 90 jours pour appliquer la rotation des mots de passe. Si le réplica perd la connexion à la source avant le redémarrage planifié, il redémarre tout de même pour reprendre la réplication. Pour PostgreSQL versions 13 et ultérieures, les réplicas en lecture peuvent subir de brèves déconnexions et reconnexions pendant le processus de rotation des mots de passe.
# Configuration de réplicas en lecture avec PostgreSQL
RDS for PostgreSQL utilise la réplication en continu native de PostgreSQL pour créer une copie en lecture seule d'une instance de base de données source. Cette instance de base de données de réplica en lecture est un réplica physique créé de façon asynchrone de l'instance de base de données source. Elle est créée par une connexion spéciale qui transmet les données WAL (write-ahead log) entre l'instance de base de données source et le réplica en lecture. Pour plus d'informations, consultez [Streaming Replication](https://www.postgresql.org/docs/14/warm-standby.html#STREAMING-REPLICATION) dans la documentation PostgreSQL.
PostgreSQL diffuse de manière asynchrone les modifications de base de données sur cette connexion sécurisée telles qu'elles sont effectuées sur l'instance de base de données source. Vous pouvez chiffrer les communications entre vos applications clientes et l'instance de base de données source ou tout autre réplica en lecture en définissant le paramètre `ssl` sur `1`. Pour plus d’informations, consultez [Utilisation de SSL avec une instance de base de données PostgreSQL](PostgreSQL.Concepts.General.SSL.md).
PostgreSQL utilise un rôle de *réplication* pour effectuer la réplication en continu. Ce rôle dispose de privilèges, mais vous ne pouvez pas l'utiliser pour modifier des données. PostgreSQL utilise un processus unique pour traiter la réplication.
Vous pouvez créer un réplica en lecture PostgreSQL sans affecter les opérations ou les utilisateurs de l'instance de base de données source. Amazon RDS définit pour vous les paramètres et autorisations nécessaires, sur l'instance de base de données source et le réplica en lecture, sans impacter le service. Un instantané de l'instance de base de données source est pris, et est utilisé pour créer le réplica en lecture. Si vous supprimez le réplica en lecture à un moment donné dans le futur, aucune panne ne se produit.
Vous pouvez créer jusqu'à 15 réplicas en lecture à partir d'une seule instance de base de données source au sein de la même région. Depuis RDS for PostgreSQL 14.1, vous pouvez également créer jusqu'à trois niveaux de réplica en lecture dans une chaîne (cascade) à partir d'une instance de base de données source. Pour de plus amples informations, veuillez consulter [Utilisation de réplicas en lecture en cascade avec RDS pour PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md). Dans tous les cas, les sauvegardes automatisées doivent être configurées sur l'instance de base de données source. Pour cela, vous devez définir la période de conservation des sauvegardes sur votre instance de base de données sur une valeur autre que 0. Pour de plus amples informations, veuillez consulter [Création d’un réplica en lecture](USER_ReadRepl.Create.md).
Vous pouvez créer des réplicas en lecture pour votre instance de base de données RDS for PostgreSQL dans la même Région AWS que votre instance de base de données source. Cette procédure se nomme « réplication *dans la région* ». Vous pouvez également créer des répliques de lecture dans une instance différente Régions AWS de celle de la base de données source. Cette procédure se nomme « réplication *entre régions* ». Pour plus d'informations sur la configuration des réplicas en lecture entre régions, veuillez consulter [Création d'une réplique de lecture dans un autre Région AWS](USER_ReadRepl.XRgn.md). Les différents mécanismes prenant en charge le processus de réplication dans la région et entre régions diffèrent légèrement en fonction de la version de RDS for PostgreSQL, comme expliqué dans [Fonctionnement de la réplication en continu pour différentes versions de RDS pour PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.md).
Pour que la réplication fonctionne de façon efficace, chaque réplica en lecture doit avoir la même quantité de ressources de calcul et de stockage que l'instance de base de données source. Si vous mettez à l'échelle l'instance de base de données source, veillez à le faire également pour les réplicas en lecture.
Amazon RDS remplace tout paramètre incompatible sur un réplica en lecture s'il empêche ce dernier de démarrer. Par exemple, supposons que la valeur du paramètre `max_connections` est supérieure dans l'instance de base de données source à celle du réplica en lecture. Dans ce cas, Amazon RDS met à jour le paramètre dans le réplica en lecture sur la même valeur que celle de l'instance de base de données source.
Les répliques de lecture RDS pour PostgreSQL ont accès à des bases de données externes disponibles via des wrappers de données étrangers FDWs () sur l'instance de base de données source. Par exemple, supposons que votre instance de base de données RDS for PostgreSQL utilise l'encapsuleur `mysql_fdw` pour accéder aux données de RDS for MySQL. Si tel est le cas, vos réplicas en lecture peuvent également accéder à ces données. Les autres supports pris en charge FDWs incluent `oracle_fdw``postgres_fdw`, et`tds_fdw`. Pour de plus amples informations, veuillez consulter [Utilisation des encapsuleurs de données externes pris en charge pour Amazon RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md).
## Utilisation des réplicas en lecture RDS for PostgreSQL avec des configurations multi-AZ
Vous pouvez créer un réplica en lecture à partir de déploiements d'instance de base de données mono-AZ ou Multi-AZ. Vous pouvez utiliser des déploiements multi-AZ pour améliorer la durabilité et la disponibilité des données critiques, avec un réplica de secours. Un *réplica de secours* est un réplica en lecture dédié qui peut assumer la charge de travail en cas de défaillance de la base de données source. Vous ne pouvez pas utiliser votre réplica de secours pour traiter le trafic en lecture. Vous pouvez toutefois créer des réplicas en lecture à partir d'instances de base de données multi-AZ à trafic élevé pour décharger les requêtes en lecture seule. Pour plus d'informations sur les déploiements Multi-AZ, veuillez consulter [Déploiements de l’instance de base de données multi-AZ pour Amazon RDS](Concepts.MultiAZSingleStandby.md).
Si l'instance de base de données source d'un déploiement multi-AZ bascule vers une instance de secours, les réplicas en lecture associés se mettent automatiquement à utiliser l'instance de secours (désormais principale) comme source de réplication. Les réplicas en lecture ont peut-être besoin d'être redémarrés, en fonction de la version de RDS for PostgreSQL, comme suit :
+ **PostgreSQL 13 et versions ultérieures** – Le redémarrage n'est pas obligatoire. Les réplicas en lecture sont automatiquement synchronisés avec la nouvelle instance principale. Toutefois, dans certains cas, votre application cliente risque de mettre en cache les détails du service DNS (Domain Name Service) pour vos réplicas en lecture. Si tel est le cas, définissez la valeur time-to-live (TTL) sur moins de 30 secondes. Cela empêche le réplica en lecture de conserver une adresse IP obsolète (et l'empêche ainsi de se synchroniser avec la nouvelle instance principale). Pour en savoir plus et pour obtenir d'autres bonnes pratiques, consultez [Directives opérationnelles de base Amazon RDS](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance).
+ **PostgreSQL 12 et toutes les versions antérieures** – Les réplicas en lecture redémarrent automatiquement après un basculement vers le réplica de secours car ce dernier (désormais principal) a une adresse IP différente et un nom d'instance différent. Le redémarrage synchronise le réplica en lecture avec la nouvelle instance principale.
Pour en savoir plus sur le basculement, consultez [Basculement d’une instance de base de données multi-AZ pour Amazon RDS](Concepts.MultiAZ.Failover.md). Pour plus d'informations sur le fonctionnement des réplicas en lecture dans un déploiement multi-AZ, veuillez consulter [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Pour prendre en charge le basculement d'un réplica en lecture, vous pouvez créer le réplica en lecture en tant qu'instance de base de données multi-AZ pour que Amazon RDS crée une instance de secours de votre réplica dans une autre zone de disponibilité. La création de votre réplica en lecture en tant qu'instance de base de données multi-AZ est indépendante du fait que la base de données source soit ou non une instance de base de données multi-AZ.
# Décodage logique sur un réplica en lecture
RDS pour PostgreSQL prend en charge la réplication logique à partir d’instances de secours avec PostgreSQL 16.1. Cela vous permet de créer un décodage logique à partir d’une instance de secours en lecture seule qui réduit la charge sur l’instance de base de données principale. Vous pouvez améliorer la disponibilité de vos applications qui doivent synchroniser les données entre plusieurs systèmes. Cette fonctionnalité améliore les performances de votre entrepôt de données et de votre analytique des données.
De plus, les emplacements de réplication d’une instance de secours donnée permettent de continuer à promouvoir cette instance de secours en instance principale. Cela signifie qu’en cas de basculement d’une instance de base de données principale ou de promotion d’une instance de secours en tant que nouvelle instance principale, les emplacements de réplication seront conservés et les anciens abonnés de secours ne seront pas affectés.
**Pour créer un décodage logique sur un réplica en lecture**
1. **Activer la réplication logique** : pour créer un décodage logique sur une instance de secours, vous devez activer la réplication logique sur votre instance de base de données source et son réplica physique. Pour de plus amples informations, veuillez consulter [Configuration de réplicas en lecture avec PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md).
+ **Pour activer la réplication logique pour une instance de base de données RDS pour PostgreSQL nouvellement créée** : créez un nouveau groupe de paramètres personnalisés de base de données et définissez le paramètre statique `rds.logical_replication` sur `1`. Associez ensuite ce groupe de paramètres de base de données à l’instance de base de données source et à sa réplica en lecture physique. Pour de plus amples informations, veuillez consulter [Association d’un groupe de paramètres de base de données à une instance de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Associating.md).
+ **Pour activer la réplication logique pour une instance de base de données RDS pour PostgreSQL existante** : modifiez le groupe de paramètres personnalisés de base de données de l’instance de base de données source et son réplica physique en lecture pour définir le paramètre statique `rds.logical_replication` sur `1`. Pour de plus amples informations, veuillez consulter [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
**Note**
Vous pouvez redémarrer les instances de base de données pour appliquer ces modifications de paramètre.
Vous pouvez utiliser la requête suivante pour vérifier les valeurs pour `wal_level` et `rds.logical_replication` sur l’instance de base de données source et son réplica en lecture physique.
```
Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication');
name | setting
-------------------------+---------
rds.logical_replication | on
wal_level | logical
(2 rows)
```
1. **Créez une table dans la base de données source** : connectez-vous à la base de données dans votre instance de base de données source. Pour de plus amples informations, veuillez consulter [Connexion à une instance de base de données exécutant le moteur de base de données PostgreSQL](USER_ConnectToPostgreSQLInstance.md).
Utilisez les requêtes suivantes pour créer une table dans votre base de données source et pour insérer des valeurs :
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
```
Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000
```
1. **Créer une publication pour la table source** : utilisez la requête suivante pour créer une publication pour la table sur l’instance de base de données source.
```
Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test;
CREATE PUBLICATION
```
Utilisez une requête SELECT pour vérifier les détails de la publication créée à la fois sur l’instance de base de données source et sur l’instance physique de réplica en lecture.
```
Postgres=>SELECT * from pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
-------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
16429 | testpub | 16413 | f | t | t | t | t | f
(1 row)
```
1. **Créer un abonnement à partir d’une instance de réplica logique** : créez une autre instance de base de données RDS pour PostgreSQL en tant qu’instance de réplica logique. Assurez-vous que le VPC est correctement configuré pour que cette instance de réplica logique puisse accéder à l’instance de réplica physique en lecture. Pour de plus amples informations, veuillez consulter [Amazon VPC et Amazon RDS](USER_VPC.md). Si votre instance de base de données source est inactive, des problèmes de connectivité peuvent survenir et l’instance principale n’envoie pas les données à l’instance de secours.
```
Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port
dbname=source_db_name user=user password=password' PUBLICATION testpub;
NOTICE: created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
Utilisez une requête SELECT pour vérifier les détails de l’abonnement sur l’instance de réplica logique.
```
Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16429 | testsub | t | testsub | {testpub}
(1 row)
postgres=> select count(*) from LR_test;
count
-------
10000
(1 row)
```
1. **Inspectez l’état de l’emplacement de réplication logique** : vous ne pouvez voir que l’emplacement de réplication physique sur votre instance de base de données source.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
---------------------------------------------+-----------+---------------------
rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical |
(1 row)
```
Toutefois, sur votre instance de réplica en lecture, vous pouvez voir l’emplacement de réplication logique et la valeur `confirmed_flush_lsn` changer à mesure que l’application consomme activement des modifications logiques.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/500002F0
(1 row)
```
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/5413F5C0
(1 row)
```
# Utilisation de réplicas en lecture en cascade avec RDS pour PostgreSQL
À partir de la version 14.1, RDS pour PostgreSQL prend en charge les réplicas en lecture en cascade. Les *réplicas en lecture en cascade* vous permettent de mettre à l’échelle les lectures sans surcharger votre instance de base de données RDS pour PostgreSQL source. Les mises à jour du journal WAL ne sont pas envoyées par l'instance de base de données source à chaque réplica en lecture. Au lieu de cela, chaque réplica en lecture d'une série en cascade envoie les mises à jour du journal WAL au réplica en lecture suivant de la série. Cela réduit la charge pesant sur l'instance de base de données source.
Avec les réplicas en lecture en cascade, votre instance de base de données RDS pour PostgreSQL envoie des données WAL au premier réplica en lecture de la chaîne. Ce réplica en lecture envoie ensuite des données WAL au deuxième réplica de la chaîne, etc. Au final, tous les réplicas en lecture de la chaîne ont reçu les modifications de l’instance de base de données RDS pour PostgreSQL, sans surcharger uniquement l’instance de base de données source.
Vous pouvez créer une série comportant jusqu’à trois réplicas en lecture dans une chaîne à partir d’une instance de base de données RDS pour PostgreSQL source. Par exemple, supposons que vous disposez d’une instance de base de données RDS pour PostgreSQL 14.1, `rpg-db-main`. Vous pouvez effectuer les opérations suivantes :
+ À partir de `rpg-db-main`, créez le premier réplica en lecture de la chaîne, `read-replica-1`.
+ Ensuite, à partir de `read-replica-1`, créez le réplica en lecture suivant dans la chaîne, `read-replica-2`.
+ Enfin, à partir de `read-replica-2`, créez le troisième réplica en lecture de la chaîne, `read-replica-3`.
Vous ne pouvez pas créer un autre réplica en lecture au-delà de ce troisième réplica en lecture en cascade dans la série pour `rpg-db-main`. Une série complète d’instances allant d’une instance de base de données source RDS pour PostgreSQL à la fin d’une série de réplicas en lecture en cascade peut comporter jusqu’à quatre instances de bases de données.
Pour que les réplicas en lecture en cascade fonctionnent, activez les sauvegardes automatiques sur RDS pour PostgreSQL. Commencez par créer le réplica en lecture, puis activez les sauvegardes automatiques sur l’instance de base de données RDS pour PostgreSQL. Le processus est le même que pour les autres moteurs de base de données Amazon RDS. Pour de plus amples informations, veuillez consulter [Création d’un réplica en lecture](USER_ReadRepl.Create.md).
Comme pour tout réplica en lecture, vous pouvez promouvoir un réplica en lecture faisant partie d'une cascade. La promotion d'un réplica en lecture depuis une chaîne de réplicas en lecture retire ce réplica de la chaîne. Par exemple, supposons que vous souhaitez déplacer une partie de la charge de travail de votre instance de base de données `rpg-db-main` vers une nouvelle instance destinée uniquement au service comptable. En prenant pour hypothèse la chaîne de trois réplicas en lecture de l'exemple, vous décidez de promouvoir `read-replica-2`. La chaîne est affectée comme suit :
+ La promotion de `read-replica-2` le retire de la chaîne de réplication.
+ Il s'agit désormais d'une read/write instance de base de données complète.
+ La réplication continue sur `read-replica-3`, tout comme avant la promotion.
+ Votre `rpg-db-main` continue la réplication sur `read-replica-1`.
Pour plus d'informations sur la promotion des réplicas en lecture, consultez [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
**Note**
RDS pour PostgreSQL ne prend pas en charge les mises à niveau des versions majeures pour les réplicas en cascade. Avant de procéder à une mise à niveau de version majeure, vous devez supprimer les réplicas en cascade. Vous pouvez les recréer après avoir terminé la mise à niveau sur votre instance de base de données source et sur les réplicas de premier niveau.
Pour les réplicas en lecture en cascade, RDS pour PostgreSQL prend en charge 15 réplicas en lecture pour chaque instance de base de données source au premier niveau de réplication, et 5 réplicas en lecture pour chaque instance de base de données source aux deuxième et troisième niveaux de réplication.
# Création de réplicas en lecture en cascade entre régions avec RDS pour PostgreSQL
RDS pour PostgreSQL prend en charge les réplicas en lecture en cascade entre régions. Vous pouvez créer un réplica entre régions à partir de l’instance de base de données source, puis créer des réplicas dans la même région à partir de celui-ci. Vous pouvez créer un réplica dans la même région à partir de l’instance de base de données source, puis créer des réplicas entre régions à partir de celui-ci.
**Création d’un réplica entre régions, puis création de réplicas dans la même région**
Vous pouvez utiliser une instance de base de données RDS pour PostgreSQL en version 14.1 ou supérieure, `rpg-db-main`, pour effectuer les opérations suivantes :
1. Commencez par `rpg-db-main` (USA-EST-1), créez le premier réplica en lecture entre régions de la chaîne, `read-replica-1` (USA-OUEST-2).
1. À l’aide du premier réplica entre régions `read-replica-1` (USA-OUEST-2), créez le deuxième réplica en lecture de la chaîne, `read-replica-2` (USA-OUEST-2).
1. À l’aide de `read-replica-2`, créez le troisième réplica en lecture de la chaîne, `read-replica-3` (USA-OUEST-2).
**Création d’un réplica dans la même région, puis création de réplicas entre régions**
Vous pouvez utiliser une instance de base de données RDS pour PostgreSQL en version 14.1 ou supérieure, `rpg-db-main`, pour effectuer les opérations suivantes :
1. À partir de `rpg-db-main` (USA-EST-1), créez le premier réplica en lecture de la chaîne, `read-replica-1` (USA-EST-1).
1. À l’aide de `read-replica-1` (USA-EST-1), créez le premier réplica en lecture entre régions de la chaîne, `read-replica-2` (USA-OUEST-2).
1. À l’aide de `read-replica-2` (USA-OUEST-2), créez le troisième réplica en lecture de la chaîne, `read-replica-3` (USA-OUEST-2).
**Limitations liées à la création de réplicas en lecture entre régions**
+ Une chaîne en cascade entre régions de réplicas de bases de données peut couvrir au maximum deux régions, avec un maximum de quatre niveaux. Les quatre niveaux incluent la source de base de données et trois réplicas en lecture.
**Avantages de l’utilisation de réplicas en lecture en cascade**
+ Capacité de mise à l’échelle de lecture améliorée : en répartissant les requêtes de lecture entre plusieurs réplicas, la réplication en cascade permet d’équilibrer la charge. Cela améliore les performances, en particulier dans les applications nécessitant beaucoup de lecture, en réduisant la charge de travail de la base de données d’enregistreur.
+ Répartition géographique : les réplicas en cascade peuvent être situés dans différents emplacements géographiques. Cela réduit le temps de latence pour les utilisateurs éloignés de la base de données principale et fournit un réplica en lecture local, améliorant ainsi les performances et l’expérience utilisateur.
+ Haute disponibilité et reprise après sinistre : en cas de panne d’un serveur principal, les réplicas peuvent être promus au rang d’instances principales, ce qui garantit la continuité. La réplication en cascade améliore encore cela en proposant plusieurs niveaux d’options de basculement, améliorant ainsi la résilience globale du système.
+ Flexibilité et croissance modulaire : à mesure que le système se développe, de nouveaux réplicas peuvent être ajoutés à différents niveaux sans reconfiguration majeure de la base de données principale. Cette approche modulaire permet une croissance évolutive et gérable de la configuration de réplication.
**Bonnes pratiques en matière d’utilisation de réplicas en lecture entre régions**
+ Avant de promouvoir un réplica, créez des réplicas supplémentaires. Cela permet de gagner du temps et de gérer efficacement la charge de travail.
# Fonctionnement de la réplication en continu pour différentes versions de RDS pour PostgreSQL
Comme indiqué dans [Configuration de réplicas en lecture avec PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md), RDS pour PostgreSQL utilise le protocole de réplication en continu natif de PostgreSQL pour envoyer des données WAL à partir de l’instance de base de données source. Il envoie les données WAL source aux réplicas en lecture pour les réplicas en lecture dans la région et entre régions. Avec la version 9.4, PostgreSQL a introduit des emplacements de réplication physiques comme mécanisme de prise en charge du processus de réplication.
Un *emplacement de réplication physique* empêche une instance de base de données source de supprimer les données WAL avant qu'elles ne soient utilisées par tous les réplicas en lecture. Chaque réplica en lecture possède son propre emplacement physique sur l'instance de base de données source. L'emplacement permet de suivre le WAL le plus ancien (par numéro de séquence logique, LSN) qui pourrait être requis par le réplica. Une fois que tous les emplacements et les connexions à la base de données ont dépassé un WAL (LSN) donné, le LSN devient candidat à la suppression au point de contrôle suivant.
Amazon RDS utilise Amazon S3 pour archiver les données WAL. Pour les réplicas en lecture dans la région, vous pouvez utiliser ces données archivées pour restaurer le réplica en lecture si nécessaire. Par exemple, vous pouvez le faire si la connexion entre la base de données source et le réplica en lecture est interrompue pour quelque raison que ce soit.
Le tableau suivant résume les différences entre les versions de PostgreSQL et les mécanismes de prise en charge pour la réplication dans la région et entre régions utilisée par RDS pour PostgreSQL.
| Version | Dans la région | Entre régions |
| --- | --- | --- |
| PostgreSQL 14.1 et versions ultérieures | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
| PostgreSQL 13 et versions inférieures | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
Pour de plus amples informations, veuillez consulter [Surveillance et réglage du processus de réplication](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md).
## Analyse des paramètres qui contrôlent la réplication PostgreSQL
Les paramètres suivants affectent le processus de réplication et déterminent dans quelle mesure les réplicas en lecture restent à jour avec l'instance de base de données source :
**max\$1wal\$1senders**
Le paramètre `max_wal_senders` spécifie le nombre maximal de connexions que l'instance de base de données source peut prendre en charge en même temps via le protocole de réplication en continu.
La valeur par défaut varie selon les versions de RDS pour PostgreSQL :
+ Pour les versions 13, 14 et 15, la valeur par défaut est 20.
+ Pour les versions 16 et supérieures, la valeur par défaut est 35.
Ce paramètre doit être défini sur une valeur légèrement supérieure au nombre réel de réplicas en lecture. Si la valeur est trop faible pour le nombre de réplicas en lecture, la réplication s'arrête.
Pour plus d'informations, consultez [max\$1wal\$1senders](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-WAL-SENDERS) dans la documentation PostgreSQL.
`max_wal_senders` est un paramètre statique qui nécessite un redémarrage de l’instance de base de données pour que les modifications prennent effet.
**wal\$1keep\$1segments**
Le paramètre `wal_keep_segments` spécifie le nombre de fichiers WAL (write-ahead log) conservés par l'instance de base de données source dans le répertoire `pg_wal`. La valeur par défaut est 32.
Si la valeur de `wal_keep_segments` n'est pas suffisante pour votre déploiement, un réplica en lecture peut prendre un retard tel que la réplication en continu s'arrête. Dans ce cas, Amazon RDS génère une erreur de réplication et commence la récupération des données sur le réplica en lecture. Pour ce faire, il relit les données WAL archivées de l'instance de base de données source à partir d'Amazon S3. Ce processus de récupération se poursuit jusqu'à ce que le réplica en lecture ait rattrapé suffisamment de retard pour continuer la réplication en continu. Pour voir ce processus en action tel qu'il est capturé par le journal PostgreSQL, consultez [Exemple : Récupération d'un réplica en lecture à la suite d'interruptions de réplicationExemple : Récupération d'un réplica en lecture à la suite d'interruptions de réplication](#USER_PostgreSQL.Replication.example-how-it-works).
Dans PostgreSQL version 13, le paramètre `wal_keep_segments` est nommé `wal_keep_size`. Il a le même objectif que `wal_keep_segments`, mais sa valeur par défaut est exprimée en mégaoctets (Mo) (2 048 Mo) plutôt qu'en nombre de fichiers. Pour plus d’informations, consultez [wal\$1keep\$1segments](https://www.postgresql.org/docs/12/runtime-config-replication.html#GUC-WAL-KEEP-SEGMENTS) et [wal\$1keep\$1size](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-WAL-KEEP-SIZE) dans la documentation PostgreSQL.
**max\$1slot\$1wal\$1keep\$1size**
Le paramètre `max_slot_wal_keep_size` contrôle la quantité de données WAL conservée par l’instance de base de données RDS pour PostgreSQL dans le répertoire `pg_wal` pour remplir les emplacements. Ce paramètre est utilisé pour les configurations utilisant des emplacements de réplication. La valeur par défaut de ce paramètre est `-1`, ce qui signifie que la quantité de données WAL conservées sur l'instance de base de données source n'est pas limitée. Pour en savoir plus sur la surveillance de vos emplacements de réplication, consultez [Surveillance des emplacements de réplication pour votre instance de base de données RDS pour PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md#USER_PostgreSQL.Replication.ReadReplicas.Monitor-monitor-replication-slots).
Pour plus d’informations sur ce paramètre, consultez [max\$1slot\$1wal\$1keep\$1size](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-SLOT-WAL-KEEP-SIZE) dans la documentation PostgreSQL.
Chaque fois que le flux qui fournit les données WAL à un réplica en lecture est interrompu, PostgreSQL bascule en mode de récupération. Il restaure le réplica en lecture à l’aide des données WAL archivées d’Amazon S3 ou avec les données WAL associées à l’emplacement de réplication. Une fois ce processus terminé, PostgreSQL rétablit la réplication en continu.
### Exemple : Récupération d'un réplica en lecture à la suite d'interruptions de réplication
L'exemple suivant fournit les détails du journal qui illustrent le processus de récupération d'un réplica en lecture. L'exemple provient d'une instance de base de données RDS pour PostgreSQL exécutant PostgreSQL version 12.9 dans la Région AWS même base de données que la base de données source, de sorte que les emplacements de réplication ne sont pas utilisés. Le processus de récupération est le même pour les autres instances de base de données RDS pour PostgreSQL exécutant des versions de PostgreSQL antérieures à la version 14.1 avec des réplicas en lecture dans la région.
Lorsque le réplica en lecture a perdu le contact avec l'instance de base de données source, Amazon RDS enregistre le problème dans le journal sous la forme d'un message `FATAL: could not receive data from WAL stream`, ainsi que `ERROR: requested WAL segment ... has already been removed`. Comme indiqué sur la ligne en gras, Amazon RDS récupère le réplica en relisant un fichier WAL archivé.
```
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR: requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG: restored log file "000000010000001A000000D3" from archive
```
Lorsqu'Amazon RDS relit un nombre suffisant de données WAL archivées sur le réplica pour qu'il rattrape son retard, le streaming vers le réplica en lecture reprend. Lorsque le streaming reprend, Amazon RDS écrit une entrée dans le fichier journal, semblable à ce qui suit.
```
2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1
```
## Définition des paramètres qui contrôlent la mémoire partagée
Les paramètres que vous définissez déterminent la taille de la mémoire partagée pour le suivi des transactions IDs, des verrous et des transactions préparées. **La structure de mémoire partagée d'une instance de secours doit être égale ou supérieure à celle d'une instance principale.** Cela garantit que la première ne viendra pas à manquer de mémoire partagée lors de la récupération. Si les valeurs des paramètres sur le réplica sont inférieures aux valeurs des paramètres sur l'instance principale, Amazon RDS ajuste automatiquement les paramètres de réplica et redémarre le moteur.
Les paramètres concernés sont les suivants :
+ max\$1connections
+ max\$1worker\$1processes
+ max\$1wal\$1senders
+ max\$1prepared\$1transactions
+ max\$1locks\$1per\$1transaction
Pour éviter le redémarrage des réplicas par RDS en raison d'un manque de mémoire, nous recommandons d'appliquer les modifications de paramètres à chaque réplica sous la forme d'un redémarrage progressif. Vous devez appliquer les règles suivantes lorsque vous définissez les paramètres :
+ **Augmentation des valeurs des paramètres :**
+ Vous devez toujours d'abord augmenter les valeurs des paramètres de tous les réplicas lus, puis effectuer un redémarrage progressif de tous les réplicas. Appliquez ensuite les modifications de paramètres sur l'instance principale et redémarrez.
+ **Diminution des valeurs des paramètres :**
+ Vous devez d'abord diminuer les valeurs des paramètres de l'instance principale, puis effectuer un redémarrage. Appliquez ensuite les modifications des paramètres à tous les réplicas de lecture associés et effectuez un redémarrage progressif.
# Surveillance et réglage du processus de réplication
Nous vous recommandons fortement de surveiller régulièrement votre instance de base de données RDS pour PostgreSQL et vos réplicas en lecture. Vous devez vous assurer que vos réplicas en lecture suivent le rythme des modifications apportées à l'instance de base de données source. Amazon RDS récupère de manière transparente vos réplicas en lecture lorsque le processus de réplication est interrompu. Cependant, il est préférable d'éviter toute récupération. La récupération à l'aide d'emplacements de réplication est plus rapide que l'utilisation de l'archive Amazon S3, mais tout processus de récupération peut affecter les performances de lecture.
Pour déterminer dans quelle mesure vos réplicas en lecture suivent le rythme de l'instance de base de données source, vous pouvez effectuer les opérations suivantes :
+ **Vérifiez la valeur de `ReplicaLag` entre l'instance de base de données source et les réplicas.** Le *retard du réplica* correspond au retard en secondes qu'accuse un réplica en lecture par rapport à son instance de base de données source. Cette métrique renvoie le résultat de la requête suivante.
```
SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";
```
Le délai de réplication indique dans quelle mesure un réplica en lecture suit le rythme de l'instance de base de données source. Il s'agit de la latence entre l'instance de base de données source et une instance de lecture spécifique. Une valeur de délai de réplication élevée peut indiquer une non-correspondance entre les classes d'instance de base de données et/ou les types de stockages utilisés par l'instance de base de données source et ses réplicas en lecture. La classe d'instance de base de données et les types de stockages pour l'instance de base de données source et tous les réplicas en lecture doivent être identiques.
Le délai de réplication peut également être issu de problèmes de connexion intermittents. Vous pouvez surveiller le délai de réplication dans Amazon CloudWatch en consultant la `ReplicaLag` métrique Amazon RDS. Pour en savoir plus sur `ReplicaLag` et d’autres métriques pour Amazon RDS, consultez [CloudWatch Métriques Amazon pour Amazon RDS](rds-metrics.md).
+ **Consultez le journal PostgreSQL pour obtenir des informations que vous pouvez utiliser pour ajuster vos paramètres.** À chaque point de contrôle, le journal PostgreSQL capture le nombre de fichiers journaux de transactions recyclés, comme illustré dans l'exemple suivant.
```
2014-11-07 19:59:35 UTC::@:[26820]:LOG: checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s
```
Vous pouvez utiliser ces informations pour déterminer le nombre de fichiers de transactions qui sont recyclés au cours d'une période donnée. Vous pouvez ensuite modifier la valeur de `wal_keep_segments` si nécessaire. Par exemple, supposons que le journal PostgreSQL à `checkpoint complete` montre `35 recycled` pour une intervalle de 5 minutes. Dans ce cas, la valeur par défaut de `wal_keep_segments` (32) n'est pas suffisante pour suivre le rythme de l'activité de streaming. Nous vous recommandons ainsi d'augmenter la valeur de ce paramètre.
+ **Utilisez Amazon CloudWatch pour surveiller les indicateurs permettant de prévoir les problèmes de réplication.** Plutôt que d'analyser directement le journal PostgreSQL, vous pouvez utiliser CloudWatch Amazon pour vérifier les métriques collectées. Par exemple, vous pouvez consulter la valeur de la métrique `TransactionLogsGeneration` pour obtenir la quantité de données WAL générées par l'instance de base de données source. Dans certains cas, la charge de travail de votre instance de base de données risque de générer une grande quantité de données WAL. Si tel est le cas, vous devrez peut-être modifier la classe de votre instance de base de données source et de vos réplicas en lecture. L'utilisation d'une classe d'instance avec des performances réseau élevées (10 Gbit/s) peut réduire le délai de réplication.
## Surveillance des emplacements de réplication pour votre instance de base de données RDS pour PostgreSQL
Toutes les versions de RDS pour PostgreSQL utilisent des emplacements de réplication pour les réplicas en lecture entre régions. RDS pour PostgreSQL 14.1 et versions ultérieures utilisent des emplacements de réplication pour les réplicas en lecture dans la région. Les réplicas en lecture dans la région utilisent également Amazon S3 pour archiver les données WAL. En d'autres termes, si votre instance de base de données et vos réplicas en lecture exécutent PostgreSQL 14.1 ou versions ultérieures, les emplacements de réplication et les archives Amazon S3 sont disponibles pour récupérer le réplica en lecture. La récupération d'un réplica en lecture à l'aide de son emplacement de réplication est plus rapide que la récupération à partir d'une archive Amazon S3. Nous vous recommandons donc de surveiller les emplacements de réplication et les métriques associées.
Vous pouvez afficher les emplacements de réplication sur vos instances de base de données RDS pour PostgreSQL en interrogeant la vue `pg_replication_slots`, comme suit.
```
postgres=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 | | physical | | | f | t | 13194 | | | 23/D8000060 | | reserved | | f
(1 row)
```
La valeur `reserved` de `wal_status` signifie que la quantité de données WAL détenue par l'emplacement se situe dans les limites du paramètre `max_wal_size`. En d'autres termes, la taille de l'emplacement de réplication est correcte. Les autres valeurs de statut possibles sont les suivantes :
+ `extended` – L'emplacement dépasse la valeur de `max_wal_size`, mais les données WAL sont conservées.
+ `unreserved` – L'emplacement ne contient plus toutes les données WAL requises. Une partie sera supprimée au prochain point de contrôle.
+ `lost` – Certaines données WAL requises ont été supprimées. L'emplacement n'est plus utilisable.
Les états `lost` et `unreserved` de `wal_status` ne sont visibles que lorsque `max_slot_wal_keep_size` n’est pas négatif.
La vue `pg_replication_slots` affiche l'état actuel de vos emplacements de réplication. Pour évaluer les performances de vos emplacements de réplication, vous pouvez utiliser Amazon CloudWatch et surveiller les indicateurs suivants :
+ **`OldestReplicationSlotLag`** : indique la quantité de données du journal d’écriture anticipée (WAL) de la source qui n’a pas été consommée par le réplica le plus en retard.
+ **`TransactionLogsDiskUsage`** : indique la quantité de stockage utilisée pour les données WAL. Lorsqu'un réplica en lecture est significativement en retard, la valeur de cette métrique peut augmenter considérablement.
Pour en savoir plus sur l'utilisation d'Amazon CloudWatch et de ses métriques pour RDS pour PostgreSQL, consultez. [Surveillance des métriques Amazon RDS () avec Amazon CloudWatch](monitoring-cloudwatch.md) Pour plus d’informations sur la surveillance de la réplication en continu sur vos instances de base de données RDS pour PostgreSQL, consultez [Best practices for Amazon RDS PostgreSQL replication](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/) sur *AWS Database Blog*.
# Configuration de la réplication différée avec RDS pour PostgreSQL
## Présentation et avantages
La fonctionnalité de réplication différée de RDS pour PostgreSQL vous permet de retarder intentionnellement la réplication des modifications de données de votre base de données principale vers un ou plusieurs serveurs de secours (réplica en lecture). Cela fournit une protection précieuse contre la corruption des données, les pertes de données accidentelles ou les transactions erronées, qui pourraient autrement être immédiatement propagées à tous les réplicas.
La réplication différée est prise en charge sur les versions suivantes de RDS pour PostgreSQL :
+ 14.19 et versions 14 ultérieures
+ 15.14 et versions 15 ultérieures
+ 16.10 et versions 16 ultérieures
+ 17.6 et versions supérieures 17
En introduisant un décalage dans le processus de réplication, vous disposez d’une opportunité pour détecter les incidents liés aux données et les traiter avant qu’ils n’affectent l’ensemble de votre cluster de bases de données. Les avantages de la réplication différée sont les suivants :
+ Elle vous permet de récupérer après des suppressions accidentelles, des mises à jour ou d’autres erreurs logiques.
+ Elle fournit une mémoire tampon contre la propagation de données corrompues dans votre cluster de bases de données.
+ Elle offre une option de point de restauration supplémentaire pour compléter vos stratégies de sauvegarde traditionnelles.
+ Elle vous permet de configurer le délai en fonction des besoins spécifiques de votre organisation et de sa tolérance au risque.
## Activation et configuration de la réplication différée
Pour activer la réplication différée sur un réplica en lecture RDS pour PostgreSQL, suivez ces étapes :
**Note**
Pour les réplicas en lecture en cascade, utilisez le même paramètre `recovery_min_apply_delay` et les mêmes étapes que ceux décrits ci-dessous.
**Pour activer la réplication différée**
1. Créez un nouveau groupe de paramètres personnalisés ou modifiez-en un existant. Pour de plus amples informations, veuillez consulter [Groupes de paramètres de base de données pour les instances de base de données Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
1. Configurez le paramètre `recovery_min_apply_delay` dans le groupe de paramètres :
+ Définissez la valeur sur le délai souhaité en millisecondes. Par exemple, 3600000 pour un délai d’une heure.
+ Plage autorisée : 0 à 86400000 ms (0 à 24 heures)
+ Par défaut : 0
1. Appliquez le groupe de paramètres à l’instance de réplica en lecture que vous souhaitez configurer pour une réplication différée.
1. Pour que les modifications deviennent effectives, redémarrez l’instance de réplica en lecture.
**Note**
Le paramètre `recovery_min_apply_delay` est dynamique. Si vous modifiez un groupe de paramètres existant déjà attaché à l’instance, les modifications prennent effet immédiatement sans nécessiter de redémarrage. Toutefois, lorsque vous appliquez un nouveau groupe de paramètres à l’instance, vous devez redémarrer l’instance pour que les modifications prennent effet.
## Gestion de la récupération par réplication différée
La réplication différée est particulièrement utile dans les scénarios où les méthodes point-in-time de restauration traditionnelles peuvent être insuffisantes ou prendre trop de temps.
Pendant la période de réplication différée, vous pouvez utiliser les fonctions PostgreSQL suivantes pour gérer le processus de récupération :
+ `pg_wal_replay_pause()` : demandez la suspension du processus de récupération du réplica différé.
+ `pg_wal_replay_resume()` : redémarrez le processus de récupération s’il a été suspendu.
+ `pg_is_wal_replay_paused()` : vérifiez si le processus de récupération est actuellement suspendu.
+ `pg_get_wal_replay_pause_state()` : obtenez l’état actuel du processus de récupération (non suspendu, pause demandée ou suspendu).
Les utilisateurs dotés du rôle `rds_superuser` disposent des privilèges EXECUTE sur `pg_wal_replay_pause()` et `pg_wal_replay_resume()`. Si d’autres utilisateurs de base de données ont besoin d’accéder à ces fonctions, vous devez leur accorder le rôle `rds_superuser`. Pour plus d'informations sur le rôle `rds_superuser`, consultez [Comprendre le rôle rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md).
L’accès à d’autres fonctions, telles que `pg_is_wal_replay_paused()` et `pg_get_wal_replay_pause_state()`, ne requiert pas le rôle `rds_superuser`.
Vous pouvez utiliser les paramètres de cible de récupération suivants pour contrôler avec précision le moment auquel la réplique différée est récupérée. Ces paramètres sont statiques et nécessitent un redémarrage de la base de données pour que les modifications soient appliquées :
+ recovery\$1target
+ recovery\$1target\$1lsn
+ recovery\$1target\$1name
+ recovery\$1target\$1time
+ recovery\$1target\$1xid
+ recovery\$1target\$1inclusive
**Important**
Vous pouvez spécifier uniquement un paramètre de cible de récupération à la fois. La configuration de plusieurs paramètres de cible de récupération dans le fichier de configuration entraîne une erreur.
## Considérations relatives à planification
Procédez comme suit lorsque vous planifiez la réplication différée avec RDS pour PostgreSQL :
+ Lors de la rotation automatique des informations d’identification `rdsrepladmin` (qui a lieu tous les 90 jours), les replicas en lecture différée peuvent entrer temporairement dans un état `REPLICATION_ERROR`. Si le réplica différé possède suffisamment de journaux WAL pour maintenir le délai configuré, il peut interrompre le processus du récepteur WAL, provoquant une accumulation de WAL sur la source. Vous devez surveiller l’état de réplication sur le réplica et la consommation de stockage sur la source pour éviter d’utiliser tout l’espace de stockage.
+ Lorsque les réplicas à lecture différée rencontrent des événements système (tels que le redémarrage), ils entrent dans un état `REPLICATION_ERROR` dans lequel le processus du récepteur WAL reste inactif jusqu’à l’expiration du délai configuré. Ce comportement peut entraîner une accumulation de WAL sur l’instance source, ce qui peut entraîner un épuisement du stockage. Envisagez d’appliquer les mesures préventives suivantes :
+ Configurez des CloudWatch alarmes pour surveiller l'utilisation du stockage sur les instances sources.
+ Activez l’autoscaling du stockage pour faire face à la croissance inattendue de WAL.
+ Définissez le paramètre `max_slot_wal_keep_size` sur l’instance source pour limiter la rétention WAL par slot de réplication.
+ Surveillez régulièrement le délai de réplication et l’état du slot.
+ L’allongement des délais augmente le nombre de journaux WAL sur les réplicas, ce qui consomme plus d’espace de stockage. Surveillez l'espace de stockage à l'aide d' CloudWatch alarmes, activez l'auto-scaling ou récupérez les répliques en cas de besoin.
+ Lors de la promotion d’un réplica à lecture différée, le paramètre `recovery_min_apply_delay` n’est pas respecté et tous les enregistrements WAL en attente sont immédiatement appliqués.
+ Le paramètre `recovery_min_apply_delay` est indépendant de chaque niveau d’une configuration de réplication en cascade. La définition d’un délai pour un réplica n’augmente pas le délai des réplicas en cascade.
Pour plus d’informations, consultez la documentation [Réplicas en lecture RDS pour PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) et la documentation [Reprise après sinistre RDS pour PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Disaster-Recovery.html).
## Présentation des limitations
La fonctionnalité de réplication différée pour Amazon RDS pour PostgreSQL présente les limitations suivantes :
+ Les déploiements bleu/vert présentent les limitations suivantes lors de la configuration de la réplication différée :
+ **Instance source verte** : `recovery_min_apply_delay parameter` n’est pas pris en compte, même s’il est configuré dans le groupe de paramètres. Aucun paramètre de délai sur l’instance source verte ne prend effet.
+ **Instance de réplica verte** : `recovery_min_apply_delay parameter` est entièrement pris en charge et appliqué au fichier de configuration PostgreSQL. Les paramètres de délai fonctionnent comme prévu pendant le flux de travail de bascule.
+ Blue/Green Déploiements RDS pour les mises à niveau de versions majeures
+ Lors des mises à niveau des versions majeures, tous les réplicas en lecture différée seront automatiquement interrompus pour permettre à l’instance source de poursuivre le processus de mise à niveau, afin de garantir une durée d’indisponibilité minimale. Une fois que l’instance source a terminé la mise à niveau, vous devez recréer manuellement les réplicas différés.
+ La réplication différée n’est pas compatible avec les fonctionnalités suivantes.
+ Réplication logique RDS pour PostgreSQL
+ Clusters multi-AZ RDS pour PostgreSQL (y compris la réplication entrante et sortante)
+ Aurora PostgreSQL
# Résolution de problèmes liés aux réplicas en lecture RDS pour PostgreSQL
Vous trouverez ci-dessous des idées pour résoudre problèmes courants liés aux réplicas en lecture RDS pour PostgreSQL.
**Mettre fin à la requête à l’origine du retard du réplica en lecture**
Les transactions à l’état actif ou inactif qui s’exécutent pendant une longue période dans la base de données peuvent interférer avec le processus de réplication WAL, augmentant ainsi le retard de réplication. Veillez donc à surveiller le temps d’exécution de ces transactions à l’aide de la vue `pg_stat_activity` PostgreSQL.
Exécutez une requête similaire à la suivante sur l’instance principale pour trouver l’ID de processus (PID) de la requête exécutée depuis longtemps :
```
SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';
```
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
Après avoir identifié le PID de la requête, vous pouvez choisir de mettre fin à la requête.
Exécutez une requête similaire à la suivante sur l’instance principale pour mettre fin à la requête exécutée depuis longtemps :
```
SELECT pg_terminate_backend(PID);
```
# Amélioration des performances des requêtes pour RDS pour PostgreSQL avec Lectures optimisées pour Amazon RDS
Vous pouvez accélérer le traitement des requêtes pour RDS pour PostgreSQL avec Lectures optimisées pour Amazon RDS. Une instance de base de données ou un cluster de bases de données multi-AZ RDS pour PostgreSQL qui utilise la fonctionnalité Lectures optimisées pour RDS peut traiter les requêtes jusqu’à 50 % plus rapidement qu’une instance ou un cluster qui ne l’utilise pas.
**Topics**
+ [
## Présentation de Lectures optimisées pour RDS dans PostgreSQL
](#USER_PostgreSQL.optimizedreads-overview)
+ [
## Cas d'utilisation pour RDS Optimized Reads
](#USER_PostgreSQL.optimizedreads-use-cases)
+ [
## Bonnes pratiques relatives à RDS Optimized Reads
](#USER_PostgreSQL.optimizedreads-best-practices)
+ [
## Utilisation de RDS Optimized Reads
](#USER_PostgreSQL.optimizedreads-using)
+ [
## Surveillance des instances de base de données qui utilisent RDS Optimized Reads
](#USER_PostgreSQL.optimizedreads-monitoring)
+ [
## Limites pour Lectures optimisées pour RDS dans PostgreSQL
](#USER_PostgreSQL.optimizedreads-limitations)
## Présentation de Lectures optimisées pour RDS dans PostgreSQL
Les lectures optimisées sont disponibles par défaut sur RDS pour PostgreSQL versions 15.2 et ultérieures, 14.7 et ultérieures, et 13.10 et ultérieures lors de l’utilisation des classes d’instance de base de données basées sur NVMe. Pour les spécifications matérielles indiquant quelles instances utilisent NVMe, consultez [Spécifications matérielles pour les classes d'instances de base de données ](Concepts.DBInstanceClass.Summary.md).
Lorsque vous utilisez une instance de base de données ou un cluster de bases de données multi-AZ RDS pour PostgreSQL avec la fonctionnalité Lectures optimisées pour RDS activée, des performances de requête jusqu’à 50 % plus rapides sont obtenues grâce au stockage local de niveau bloc, de type SSD (Solid State Drive), basé sur NVMe (Non-Volatile Memory Express). Vous pouvez accélérer le traitement des requêtes en plaçant les tables temporaires générées par PostgreSQL sur le stockage local, ce qui réduit le trafic vers Elastic Block Storage (EBS) sur le réseau.
Dans PostgreSQL, les objets temporaires sont affectés à un espace de noms temporaire qui est automatiquement supprimé à la fin de la session. Lors de la suppression, l'espace de noms temporaire supprime tous les objets qui dépendent de la session, y compris les objets qualifiés selon le schéma, tels que les tables, les fonctions, les opérateurs ou même les extensions.
Dans RDS pour PostgreSQL, le paramètre `temp_tablespaces` est configuré pour cette zone de travail temporaire dans laquelle les objets temporaires sont stockés.
Les requêtes suivantes renvoient le nom de l'espace de table et son emplacement.
```
postgres=> show temp_tablespaces;
temp_tablespaces
---------------------
rds_temp_tablespace
(1 row)
```
`rds_temp_tablespace` est un espace de table configuré par RDS qui pointe vers le stockage local NVMe. Vous pouvez toujours revenir au stockage Amazon EBS en modifiant ce paramètre dans le `Parameter group` en utilisant la AWS Management Console pour pointer vers un espace de table autre que `rds_temp_tablespace`. Pour plus d’informations, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Vous pouvez également utiliser la commande SET pour modifier la valeur du paramètre `temp_tablespaces` sur `pg_default` au niveau de la session à l'aide de la commande SET. La modification du paramètre redirige la zone de travail temporaire vers Amazon EBS. Le retour à Amazon EBS est utile lorsque le stockage local de votre instance ou cluster RDS n'est pas suffisant pour effectuer une opération SQL spécifique.
```
postgres=> SET temp_tablespaces TO 'pg_default';
SET
```
```
postgres=> show temp_tablespaces;
temp_tablespaces
------------------
pg_default
```
## Cas d'utilisation pour RDS Optimized Reads
Voici quelques cas d'utilisation pour lesquels Lectures optimisées est utilisé :
+ Requêtes d'application avec des expressions de table communes (CTE), des tables dérivées et des opérations de regroupement complexes.
+ Réplicas en lecture qui gèrent les requêtes non optimisées pour une application.
+ Requêtes de création de rapports dynamiques ou à la demande avec des opérations complexes telles que GROUP BY et ORDER BY qui ne peuvent pas toujours utiliser les index appropriés.
+ Autres charges de travail utilisant des tables temporaires internes.
+ Opérations `CREATE INDEX` ou `REINDEX` pour le tri.
## Bonnes pratiques relatives à RDS Optimized Reads
Utilisez les bonnes pratiques suivantes pour RDS Optimized Reads :
+ Ajoutez une logique de nouvelle tentative pour les requêtes en lecture seule au cas où elles échoueraient en raison d'un stockage d'instances complet pendant l'exécution.
+ Surveillez l'espace de stockage disponible sur le stockage d'instances à l'aide de la métrique CloudWatch `FreeLocalStorage`. Si le stockage d'instances atteint sa limite en raison de la charge de travail sur l'instance de base de données ou le cluster de bases de données multi-AZ, modifiez l'instance ou le cluster pour utiliser une plus grande classe d'instances de base de données.
## Utilisation de RDS Optimized Reads
Lorsque vous provisionnez une instance de base de données RDS pour PostgreSQL avec l’une des classes d’instance de base de données basées sur NVMe dans le cadre d’un déploiement d’instance de base de données mono-AZ ou multi-AZ, ou d’un déploiement de cluster de bases de données multi-AZ, l’instance de base de données utilise automatiquement la fonctionnalité Lectures optimisées pour RDS.
Pour plus d’informations sur le déploiement multi-AZ, consultez [Configuration et gestion d’un déploiement multi-AZ pour Amazon RDS](Concepts.MultiAZ.md).
Pour activer RDS Optimized Reads, effectuez l'une des actions suivantes :
+ Créez une instance de base de données ou un cluster de bases de données multi-AZ RDS pour PostgreSQL en utilisant l’une des classes d’instance de base de données basées sur NVMe. Pour plus d’informations, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
+ Modifiez une instance de base de données ou un cluster de bases de données multi-AZ RDS pour PostgreSQL existant afin d’utiliser l’une des classes d’instance de base de données basées sur NVMe. Pour plus d’informations, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
La fonctionnalité Lectures optimisées pour RDS est disponible dans toutes les Régions AWS où une ou plusieurs des classes d'instances de base de données avec stockage SSD NVMe local sont prises en charge. Pour plus d’informations, consultez [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).
Pour revenir à une instance RDS aux lectures non optimisées, modifiez la classe d'instances de base de données de votre instance ou cluster RDS pour spécifier la classe d'instances similaire qui prend en charge uniquement le stockage EBS pour vos charges de travail de base de données. Par exemple, si la classe d'instance de base de données actuelle est db.r6gd.4xlarge, choisissez db.r6g.4xlarge pour revenir en arrière. Pour plus d’informations, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
## Surveillance des instances de base de données qui utilisent RDS Optimized Reads
Vous pouvez surveiller les instances de base de données qui utilisent Lectures optimisées pour RDS à l'aide des métriques CloudWatch suivantes :
+ `FreeLocalStorage`
+ `ReadIOPSLocalStorage`
+ `ReadLatencyLocalStorage`
+ `ReadThroughputLocalStorage`
+ `WriteIOPSLocalStorage`
+ `WriteLatencyLocalStorage`
+ `WriteThroughputLocalStorage`
Ces métriques fournissent des données sur le stockage disponible dans le stockage d'instances, les IOPS et le débit. Pour plus d’informations sur ces métriques, consultez [Mesures au CloudWatch niveau de l'instance Amazon pour Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
Pour surveiller l’utilisation actuelle de votre stockage local, connectez-vous à votre base de données et exécutez la requête suivante :
```
SELECT
spcname AS "Name",
pg_catalog.pg_size_pretty(pg_catalog.pg_tablespace_size(oid)) AS "size"
FROM
pg_catalog.pg_tablespace
WHERE
spcname IN ('rds_temp_tablespace');
```
Pour plus d’informations sur les fichiers temporaires et leur utilisation, consultez [Gestion des fichiers temporaires avec PostgreSQL](PostgreSQL.ManagingTempFiles.md).
## Limites pour Lectures optimisées pour RDS dans PostgreSQL
La limitation suivante s'applique à la fonctionnalité Lectures optimisées pour RDS dans PostgreSQL :
+ Les transactions peuvent échouer lorsque le stockage d'instances est plein.
# Importation de données dans PostgreSQL sur Amazon RDS
Supposons que vous disposez d'un déploiement PostgreSQL existant que vous souhaitez transférer dans Amazon RDS. La complexité de votre tâche dépend de la taille de votre base de données et des types d'objets de base de données que vous transférez. Prenons l'exemple d'une base de données qui contient des jeux de données se mesurant en gigaoctets, ainsi que des déclencheurs et des procédures stockés. Une telle base de données va être plus compliquée qu'une base de données simple avec seulement quelques mégaoctets de données de test et pas de déclencheurs, ni de procédures stockés.
Nous vous recommandons d'utiliser les outils de migration de base de données PostgreSQL natifs dans les conditions suivantes :
+ Vous avez une migration homogène, dans le sens où vous migrez depuis une base de données avec le même moteur de base de données que la base de données cible.
+ Vous migrez une base de données entière.
+ Les outils natifs vous permettent de migrer votre système avec une interruption minimale.
Dans la plupart des autres cas, la meilleure approche consiste à effectuer une migration AWS de base de données à l'aide du Service de migration de base de données (AWS DMS). AWS DMS peut migrer des bases de données sans interruption et, pour de nombreux moteurs de base de données, poursuivre la réplication continue jusqu'à ce que vous soyez prêt à passer à la base de données cible. Vous pouvez migrer vers le même moteur de base de données ou vers un autre moteur de base de données à l'aide de AWS DMS. Si vous migrez vers un moteur de base de données différent de celui de votre base de données source, vous pouvez utiliser le AWS Schema Conversion Tool (AWS SCT). Vous pouvez l'utiliser AWS SCT pour migrer des objets de schéma qui ne sont pas migrés par AWS DMS. Pour plus d'informations sur le AWS DMS, voir [Qu'est-ce que c'est ? AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)
Modifiez votre groupe de paramètres de base de données pour inclure les paramètres suivants *pour votre importation uniquement*. Vous devez tester les réglages des paramètres pour déterminer les réglages les plus efficaces pour la taille de votre instance de base de données. Vous devez également revenir aux valeurs de production pour ces paramètres une fois votre importation terminée.
Modifiez les paramètres de l'instance de base de données comme suit :
+ Désactivez les sauvegardes de l'instance de base de données (affectez la valeur 0 à backup\$1retention).
+ Désactivez le mode multi-AZ.
Modifiez votre groupe de paramètres DB pour inclure les paramètres suivants. Vous devez utiliser ces paramètres uniquement lors de l'importation des données. Vous devez tester les réglages des paramètres pour déterminer les réglages les plus efficaces pour la taille de votre instance de base de données. Vous devez également revenir aux valeurs de production pour ces paramètres une fois votre importation terminée.
| Paramètre | Valeur recommandée lors de l'importation | Description |
| --- | --- | --- |
| `maintenance_work_mem` | 524288, 1048576, 2097152 ou 4194304 (en Ko). Ces paramètres sont comparables à 512 Mo, 1 Go, 2 Go et 4 Go. | La valeur de ce paramètre dépend de la taille de votre hôte. Ce paramètre est utilisé lors des instructions CREATE INDEX et chaque commande parallèle peut utiliser cette quantité de mémoire. Calculez la meilleure valeur afin de ne pas définir de valeur si élevée et risquer de manquer de mémoire. |
| `max_wal_size` | 256 (pour la version 9.6), 4096 (pour les versions 10 et ultérieures) | Taille maximale pour permettre au journal WAL de croître lors des points de contrôle automatiques. L'augmentation de ce paramètre peut augmenter le temps nécessaire à la reprise sur incident. Ce paramètre remplace `checkpoint_segments` pour PostgreSQL 9.6 et versions ultérieures. Pour PostgreSQL version 9.6, cette valeur est exprimée en unités de 16 Mo. Pour les versions ultérieures, la valeur est exprimée en unités de 1 Mo. Par exemple, dans la version 9.6, 128 signifie 128 fragments d'une taille de 16 Mo chacun. Dans la version 12.4, 2048 signifie 2048 fragments de 1 Mo chacun. |
| `checkpoint_timeout` | 1800 | La valeur de ce paramètre vous permet une rotation WAL moins fréquente. |
| `synchronous_commit` | Désactivé | Désactivez ce paramètre pour accélérer les écritures. Le fait de désactiver ce paramètre peut augmenter le risque de perte de données en cas de défaillance du serveur (ne désactivez pas FSYNC). |
| `wal_buffers` | 8192 | Cette valeur est en unités de 8 Ko. Cela permet de nouveau d'accélérer la génération WAL |
| `autovacuum` | 0 | Désactivez le paramètre auto-vacuum de PostgreSQL lorsque vous chargez des données afin qu'il n'utilise pas de ressources |
Utilisez les commandes `pg_dump -Fc` (compressé) ou `pg_restore -j` (parallèle) avec ces paramètres.
**Note**
La commande PostgreSQL `pg_dumpall` requiert des autorisations super\$1user qui ne sont pas accordées lorsque vous créez une instance de base de données, si bien qu'elle ne peut pas être utilisée pour importer des données.
**Topics**
+ [
# Importation d'une base de données PostgreSQL à partir d'une instance Amazon EC2
](PostgreSQL.Procedural.Importing.EC2.md)
+ [
# Utilisation de la commande \$1copy pour importer des données dans une table sur une instance de base de données PostgreSQL
](PostgreSQL.Procedural.Importing.Copy.md)
+ [
# Importation de données Amazon S3 dans une instance de base de données RDS for PostgreSQL d'un
](USER_PostgreSQL.S3Import.md)
+ [
# Transport de bases de données PostgreSQL entre des instances de base de données
](PostgreSQL.TransportableDB.md)
# Importation d'une base de données PostgreSQL à partir d'une instance Amazon EC2
Si vous possédez des données dans un serveur PostgreSQL sur une instance Amazon EC2 et que vous souhaitez les déplacer vers une instance de base de données PostgreSQL, vous pouvez suivre ce processus.
1. Créez un fichier contenant les données à charger à l'aide de pg\$1dump
1. Créez l'instance de base de données cible
1. Utilisez *psql* pour créer la base de données sur l'instance de base de données et pour charger les données
1. Créez un instantané de base de données de l'instance de base de données
Les sections suivantes fournissent plus de détails sur chacune des étapes indiquées ci-dessus.
## Étape 1 : Créer un fichier contenant les données à charger à l'aide de pg\$1dump
L'utilitaire `pg_dump` utilise la commande COPY pour créer un schéma et un vidage des données d'une base de données PostgreSQL. Le script de vidage généré par `pg_dump` charge les données dans une base de données dotée du même nom et recrée les tables, les index et les clés étrangères. Vous pouvez utiliser la commande `pg_restore` et le paramètre `-d` pour restaurer les données dans une base de données dotée d'un nom différent.
Avant de créer le vidage des données, vous devez interroger les tables à vider pour obtenir le nombre de lignes afin de pouvoir confirmer ce nombre sur l'instance de base de données cible.
La commande suivante crée un fichier de vidage mydb2dump.sql pour une base de données nommée mydb2.
```
prompt>pg_dump dbname=mydb2 -f mydb2dump.sql
```
## Étape 2 : Créer l'instance de bases de données cible
Créez l'instance de base de données PostgreSQL cible à l'aide soit de la console Amazon RDS, de l' AWS CLI ou de l'API. Créez l'instance avec le paramètre de rétention des sauvegardes défini sur 0 et désactivez le mode multi-AZ. Cela vous permet d'effectuer une importation plus rapide des données. Vous devez créer une base de données sur l'instance avant de pouvoir vider les données. La base de données peut avoir le même nom que celle qui contenait les données vidées. Sinon, vous pouvez créer une base de données avec un autre nom. Dans ce cas, vous pouvez utiliser la commande `pg_restore` et le paramètre `-d` pour restaurer les données dans une base de données dotée d'un nouveau nom.
Par exemple, les commandes suivantes permettent de vider, de restaurer et de renommer une base de données.
```
pg_dump -Fc -v -h [endpoint of instance] -U [master username] [database] > [database].dump
createdb [new database name]
pg_restore -v -h [endpoint of instance] -U [master username] -d [new database name] [database].dump
```
## Étape 3 : Utiliser psql pour créer la base de données sur l'instance de base de données et charger les données
Vous pouvez utiliser la même connexion que vous avez utilisée pour exécuter la commande pg\$1dump pour vous connecter à l'instance de base de données cible et recréer la base de données. Grâce à *psql*, vous pouvez utiliser l'identifiant principal et le mot de passe principal pour créer la base de données sur l'instance de base de données.
L'exemple suivant utilise *psql* et un fichier de vidage nommé mydb2dump.sql pour créer une base de données appelée mydb2 sur une instance de base de données PostgreSQL nommée mypginstance :
Pour Linux, macOS ou Unix :
```
psql \
-f mydb2dump.sql \
--host mypginstance.555555555555.aws-region.rds.amazonaws.com \
--port 8199 \
--username myawsuser \
--password password \
--dbname mydb2
```
Pour Windows :
```
psql ^
-f mydb2dump.sql ^
--host mypginstance.555555555555.aws-region.rds.amazonaws.com ^
--port 8199 ^
--username myawsuser ^
--password password ^
--dbname mydb2
```
**Note**
Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.
## Étape 4 : Créer un instantané de base de données de l'instance de bases de données
Une fois que vous avez vérifié que les données ont été chargées dans votre instance de base de données, nous vous conseillons de créer un instantané de base de données de l'instance de base de données PostgreSQL cible. Les snapshots DB sont des sauvegardes complètes de votre instance de base de données qui peuvent être utilisées pour restaurer l'instance de base de données à un état connu. Un instantané de base de données pris immédiatement après le chargement vous évite de devoir charger les données à nouveau en cas d'incident. Vous pouvez également l'utiliser pour créer de nouvelles instances de base de données. Pour plus d'informations sur la création d'un instantané de base de données, consultez [Création d’un instantané de base de données pour une instance de base de données mono-AZ pour Amazon RDS](USER_CreateSnapshot.md).
# Utilisation de la commande \$1copy pour importer des données dans une table sur une instance de base de données PostgreSQL
La commande PostgreSQL `\copy` est une méta-commande disponible à partir de l'outil client interactif `psql`. Vous pouvez utiliser `\copy` pour importer des données dans une table sur votre instance de base de données RDS pour PostgreSQL. Pour utiliser la commande `\copy`, vous devez d'abord créer la structure de la table sur l'instance de base de données cible, afin que `\copy` dispose d'une destination pour les données copiées.
Vous pouvez utiliser `\copy` pour charger des données à partir d'un fichier CSV (valeurs séparées par des virgules), par exemple un fichier qui a été exporté et enregistré sur votre poste de travail client.
Pour importer les données CSV vers l’instance de base de données RDS pour PostgreSQL cible, connectez-vous d’abord à l’instance de base de données cible à l’aide de `psql`.
```
psql --host=db-instance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=target-db
```
Exécutez ensuite la commande `\copy` avec les paramètres suivants afin d'identifier la cible pour les données et son format.
+ `target_table` : nom de la table devant recevoir les données copiées à partir du fichier CSV.
+ `column_list` : spécifications des colonnes pour la table.
+ `'filename'` : chemin d'accès complet vers le fichier CSV sur votre poste de travail local.
```
\copy target_table from '/path/to/local/filename.csv' WITH DELIMITER ',' CSV;
```
Si votre fichier CSV contient des informations d'en-tête de colonne, vous pouvez utiliser cette version de la commande et des paramètres.
```
\copy target_table (column-1, column-2, column-3, ...)
from '/path/to/local/filename.csv' WITH DELIMITER ',' CSV HEADER;
```
Si la commande `\copy` échoue, PostgreSQL renvoie des messages d'erreur.
Création d’une nouvelle instance de base de données dans la commande `psql` de l’environnement de version préliminaire de base de données avec la méta-commande `\copy` telle qu’illustrée dans les exemples suivants. Cet exemple utilise *source-table* comme nom de tableau source, *source-table.csv* comme fichier .csv et *target-db* comme base de données cible :
Pour Linux, macOS ou Unix :
```
$psql target-db \
-U \
-p \
-h \
-c "\copy source-table from 'source-table.csv' with DELIMITER ','"
```
Pour Windows :
```
$psql target-db ^
-U ^
-p ^
-h ^
-c "\copy source-table from 'source-table.csv' with DELIMITER ','"
```
Pour plus de détails sur la commande `\copy`, consultez la page [psql](http://www.postgresql.org/docs/current/static/app-psql.html) dans la documentation PostgreSQL, au sein de la section *Meta-Commands*.
# Importation de données Amazon S3 dans une instance de base de données RDS for PostgreSQL d'un
Vous pouvez importer des données qui ont été stockées à l'aide d'Amazon Simple Storage Service dans une table sur une instance de base de données RDS for PostgreSQL. Pour ce faire, vous devez d'abord installer l'extension `aws_s3` RDS for PostgreSQL. Cette extension fournit les fonctions que vous utilisez pour importer des données à partir d'un compartiment Amazon S3. Un *compartiment* est un conteneur Amazon S3 pour les objets et les fichiers. Les données peuvent résider dans un fichier CSV (valeur séparée par des virgules), un fichier texte ou un fichier compressé (gzip). Vous apprendrez ensuite comment installer l'extension et comment importer des données d'Amazon S3 dans un tableau.
Votre base de données doit exécuter PostgreSQL version 10.7 ou supérieure pour importer depuis Simple Storage Service (Amazon S3) vers RDS for PostgreSQL.
Si vous n'avez pas de données stockées sur Amazon S3, vous devez d'abord créer un compartiment et y stocker les données. Pour en savoir plus, consulter les rubriques suivantes dans le *Guide de l'utilisateur d'Amazon Simple Storage Service*.
+ [Créez un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#creating-bucket)
+ [Ajout d'un objet dans un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#uploading-an-object-bucket)
L'importation entre comptes depuis Amazon S3 est prise en charge. Pour plus d’informations, consultez [Octroi d'autorisations entre comptes](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
Vous pouvez utiliser la clé gérée par le client pour le chiffrement lors de l'importation de données depuis S3. Pour plus d'informations, consultez [Clés KMS stockées dans AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
**Topics**
+ [
# Installation de l'extension aws\$1s3
](USER_PostgreSQL.S3Import.InstallExtension.md)
+ [
# Présentation de l’importation de données à partir de données Amazon S3
](USER_PostgreSQL.S3Import.Overview.md)
+ [
# Configuration de l’accès à un compartiment Amazon S3
](USER_PostgreSQL.S3Import.AccessPermission.md)
+ [
# Importation de données depuis Amazon S3 vers votre instance de base de données RDS pour PostgreSQL
](USER_PostgreSQL.S3Import.FileFormats.md)
+ [
# Références de fonctions
](USER_PostgreSQL.S3Import.Reference.md)
# Installation de l'extension aws\$1s3
Avant de pouvoir utiliser Amazon S3 avec votre instance de base de données RDS for PostgreSQL, vous devez installer l'extension. Cette extension fournit des fonctions pour importer des données depuis un compartiment Amazon S3. Il fournit également des fonctions pour exporter des données depuis une instance de base de données RDS for PostgreSQL vers un compartiment Amazon S3. Pour de plus amples informations, consultez [Exportation de données à partir d’une instance de base de données RDS pour PostgreSQL vers Amazon S3](postgresql-s3-export.md). L'extension `aws_s3` dépend de certaines des fonctions d'aide de l'extension `aws_commons`, qui est installée automatiquement lorsque cela est nécessaire.
**Pour installer l'extension `aws_s3`**
1. Utilisez psql (ou pgAdmin) pour vous connecter à l'instance de base de données RDS for PostgreSQL en tant qu'utilisateur disposant de privilèges `rds_superuser`. Si vous avez conservé le nom par défaut pendant le processus d'installation, vous vous connectez en tant que `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Pour installer l'extension, exécutez la commande suivante.
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. Pour vérifier que l'extension est installée, vous pouvez utiliser la métacommande psql `\dx`.
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
Les fonctions d'importation de données depuis Amazon S3 et d'exportation de données vers Amazon S3 sont désormais disponibles.
# Présentation de l’importation de données à partir de données Amazon S3
**Pour importer des données S3 dans Amazon RDS**
Tout d’abord, rassemblez les informations que vous devez fournir à la fonction. Il s'agit notamment du nom de la table sur l'instance de base de données RDS pour PostgreSQL, ainsi que du nom du compartiment, du chemin du fichier, du type de fichier et de l'endroit où Région AWS les données Amazon S3 sont stockées. Pour plus d’informations, consultez [View an object](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html) (Afficher un objet) dans le *Guide de l’utilisateur Amazon Simple Storage Service*.
**Note**
L’importation de données partitionnées depuis Amazon S3 n’est pas prise en charge actuellement.
1. Obtenez le nom de la table dans laquelle la fonction `aws_s3.table_import_from_s3` doit importer les données. À titre d’exemple, la commande suivante crée une table `t1` qui peut être utilisée dans les étapes suivantes.
```
postgres=> CREATE TABLE t1
(col1 varchar(80),
col2 varchar(80),
col3 varchar(80));
```
1. Obtenez les détails sur le compartiment Amazon S3 et les données à importer. Pour ce faire, ouvrez la console Amazon S3 à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/), puis choisissez **Buckets**. Trouvez le compartiment contenant vos données dans la liste. Sélectionnez le compartiment, ouvrez sa page Object overview (Présentation des objets), puis choisissez Properties (Propriétés).
Notez le nom du compartiment, le chemin Région AWS, le et le type de fichier. Vous aurez besoin du nom Amazon Resource Name (ARN) pour configurer l’accès à Amazon S3 via un rôle IAM. Pour obtenir plus d’informations, consultez [Configuration de l’accès à un compartiment Amazon S3](USER_PostgreSQL.S3Import.AccessPermission.md). L’image suivante montre un exemple.
![\[Image d’un objet fichier dans un compartiment Amazon S3.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/aws_s3_import-export_s3_bucket-info.png)
1. Vous pouvez vérifier le chemin d'accès aux données du compartiment Amazon S3 à l'aide de la AWS CLI commande`aws s3 cp`. Si les informations sont correctes, cette commande télécharge une copie du fichier Amazon S3.
```
aws s3 cp s3://amzn-s3-demo-bucket/sample_file_path ./
```
1. Configurez les autorisations sur votre instance de base de données RDS pour PostgreSQL pour permettre l’accès au fichier sur le compartiment Amazon S3. Pour ce faire, vous devez utiliser un rôle Gestion des identités et des accès AWS (IAM) ou des informations d'identification de sécurité. Pour de plus amples informations, veuillez consulter [Configuration de l’accès à un compartiment Amazon S3](USER_PostgreSQL.S3Import.AccessPermission.md).
1. Fournissez le chemin et les autres détails de l’objet Amazon S3 recueillis (voir l’étape 2) à la fonction `create_s3_uri` pour construire un objet URI Amazon S3. Pour en savoir plus sur cette fonction, consultez [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri). Voici un exemple de construction de cet objet pendant une session psql.
```
postgres=> SELECT aws_commons.create_s3_uri(
'docs-lab-store-for-rpg',
'versions_and_jdks_listing.csv',
'us-west-1'
) AS s3_uri \gset
```
Dans l’étape suivante, vous transmettez cet objet (`aws_commons._s3_uri_1`) à la fonction `aws_s3.table_import_from_s3` pour importer les données dans la table.
1. Appelez la fonction `aws_s3.table_import_from_s3` pour importer les données d’Amazon S3 dans votre table. Pour obtenir des informations de référence, consultez [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3). Pour obtenir des exemples, consultez [Importation de données depuis Amazon S3 vers votre instance de base de données RDS pour PostgreSQL](USER_PostgreSQL.S3Import.FileFormats.md).
# Configuration de l’accès à un compartiment Amazon S3
Pour importer des données à partir d’un fichier Amazon S3, vous devez accorder à l’instance de base de données RDS pour PostgreSQL une autorisation d’accès au compartiment Amazon S3 contenant le fichier. Pour accorder l’accès à un compartiment Amazon S3, vous pouvez employer une des deux méthodes décrites dans les rubriques suivantes.
**Topics**
+ [
## Utilisation d’un rôle IAM pour accéder à un compartiment Amazon S3
](#USER_PostgreSQL.S3Import.ARNRole)
+ [
## Utilisation d’informations d’identification de sécurité pour accéder à un compartiment Amazon S3
](#USER_PostgreSQL.S3Import.Credentials)
+ [
## Résolution des problèmes d’accès à Amazon S3
](#USER_PostgreSQL.S3Import.troubleshooting)
## Utilisation d’un rôle IAM pour accéder à un compartiment Amazon S3
Avant de charger des données à partir d’un fichier Amazon S3, accordez à votre instance de base de données RDS pour PostgreSQL l’autorisation d’accéder au compartiment Amazon S3 dans lequel se trouve le fichier. De cette façon, vous n’avez pas à gérer d’informations d’identification supplémentaires ni à les fournir dans l’appel de fonction [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
Pour ce faire, créez une politique IAM qui donne accès au compartiment Amazon S3. Créez un rôle IAM et attachez la politique à ce rôle. Attribuez ensuite le rôle IAM à votre instance de base de données.
**Pour permettre à une instance de base de données RDS for PostgreSQL d'accéder à Amazon S3 via un rôle IAM**
1. Créez une politique IAM.
Celle-ci fournit au compartiment et à l’objet les autorisations permettant à votre instance de base de données RDS pour PostgreSQL d’accéder à Amazon S3.
Incluez à la politique les actions obligatoires suivantes pour permettre le transfert de fichiers d’un compartiment Amazon S3 vers Amazon RDS :
+ `s3:GetObject`
+ `s3:ListBucket`
Incluez à la politique les ressources suivantes pour identifier le compartiment Amazon S3 et les objets qu’il contient. Voici le format Amazon Resource Name (ARN) permettant d’accéder à Amazon S3 :
+ arn:aws:s3 : *amzn-s3-demo-bucket*
+ arn:aws:s3 : :1 /\$1 *amzn-s3-demo-bucket*
Pour obtenir plus d’informations sur la création d’une politique IAM pour RDS pour PostgreSQL, consultez [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). Consultez également [Didacticiel : création et attachement de votre première politique gérée par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) dans le *Guide de l’utilisateur IAM*.
La AWS CLI commande suivante crée une politique IAM nommée `rds-s3-import-policy` avec ces options. Elle accorde un accès à un compartiment nommé *amzn-s3-demo-bucket*.
**Note**
Notez le Amazon Resource Name (ARN) de la politique renvoyée par cette commande. Vous en aurez besoin par la suite pour attacher la politique à un rôle IAM.
**Example**
Pour Linux, macOS ou Unix :
```
aws iam create-policy \
--policy-name rds-s3-import-policy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
Pour Windows :
```
aws iam create-policy ^
--policy-name rds-s3-import-policy ^
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. Créez un rôle IAM.
L’objectif est ici de permettre à Amazon RDS d’endosser ce rôle IAM pour accéder à vos compartiments Amazon S3. Pour plus d’informations, consultez [Création d’un rôle pour déléguer des autorisations à un utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) dans le *Guide de l’utilisateur IAM*.
Nous vous recommandons d’utiliser les clés de contexte de condition globale `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` et `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` dans des politiques basées sur les ressources pour limiter les autorisations du service à une ressource spécifique. C’est le moyen le plus efficace de se protéger contre le [problème du député confus](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
Si vous utilisez les deux clés de contexte de condition globale et que la valeur de `aws:SourceArn` contient l’ID de compte, la valeur de `aws:SourceAccount` et le compte indiqué dans la valeur de `aws:SourceArn` doivent utiliser le même ID de compte lorsqu’il est utilisé dans la même déclaration de politique.
+ Utilisez `aws:SourceArn` si vous souhaitez un accès interservices pour une seule ressource.
+ Utilisez `aws:SourceAccount` si vous souhaitez autoriser une ressource de ce compte à être associée à l’utilisation interservices.
Dans la politique, veillez à utiliser la clé de contexte de condition globale `aws:SourceArn` avec l’ARN complet de la ressource. L'exemple suivant montre comment procéder à l'aide de la AWS CLI commande pour créer un rôle nommé`rds-s3-import-role`.
**Example**
Pour Linux, macOS ou Unix :
```
aws iam create-role \
--role-name rds-s3-import-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
Pour Windows :
```
aws iam create-role ^
--role-name rds-s3-import-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
1. Attachez la politique IAM que vous avez créée au rôle IAM que vous venez de créer.
La AWS CLI commande suivante associe la politique créée à l'étape précédente au rôle nommé `rds-s3-import-role` Remplacer `your-policy-arn` par l'ARN de stratégie que vous avez noté à l'étape précédente.
**Example**
Pour Linux, macOS ou Unix :
```
aws iam attach-role-policy \
--policy-arn your-policy-arn \
--role-name rds-s3-import-role
```
Pour Windows :
```
aws iam attach-role-policy ^
--policy-arn your-policy-arn ^
--role-name rds-s3-import-role
```
1. Ajoutez le rôle IAM à l’instance de base de données.
Pour ce faire, utilisez le AWS Management Console ou AWS CLI, comme décrit ci-dessous.
### Console
**Pour ajouter un rôle IAM à l’instance de base de données PostgreSQL à l’aide de la console**
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. Choisissez le nom de l’instance de base de données PostgreSQL pour afficher ses détails.
1. Sous l’onglet **Connectivity & security** (Connectivité et sécurité), accédez à la section **Manage IAM roles** (Gérer les rôles IAM) et choisissez le rôle à ajouter sous **Add IAM roles to this instance** (Ajouter des rôles IAM à ce cluster/cette instance).
1. Sous **Feature** (Fonction), choisissez **s3Import**.
1. Choisissez **Add role** (Ajouter un rôle).
### AWS CLI
**Pour ajouter un rôle IAM à une instance de base de données PostgreSQL à l’aide de la CLI**
+ Utilisez la commande suivante pour ajouter le rôle à l’instance de base de données PostgreSQL nommée `my-db-instance`. Remplacez *`your-role-arn`* par l’ARN de rôle que vous avez noté lors d’une étape précédente. Utilisez `s3Import` comme valeur de l’option `--feature-name`.
**Example**
Pour Linux, macOS ou Unix :
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-db-instance \
--feature-name s3Import \
--role-arn your-role-arn \
--region your-region
```
Pour Windows :
```
aws rds add-role-to-db-instance ^
--db-instance-identifier my-db-instance ^
--feature-name s3Import ^
--role-arn your-role-arn ^
--region your-region
```
### API RDS
Pour ajouter un rôle IAM pour une instance de cluster de base de données à l'aide de l'API Amazon RDS, appelez l'opération.
## Utilisation d’informations d’identification de sécurité pour accéder à un compartiment Amazon S3
Si vous préférez, au lieu de donner à accès un compartiment Amazon S3 avec un rôle IAM, vous pouvez utiliser des informations d’identification de sécurité. Pour ce faire, spécifiez le paramètre `credentials` dans l’appel de fonction [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
Le `credentials` paramètre est une structure de type contenant `aws_commons._aws_credentials_1` des AWS informations d'identification. Utilisez la fonction [aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials) pour définir la clé d’accès et la clé secrète dans une structure `aws_commons._aws_credentials_1`, comme indiqué ci-après.
```
postgres=> SELECT aws_commons.create_aws_credentials(
'sample_access_key', 'sample_secret_key', '')
AS creds \gset
```
Après avoir créé la structure `aws_commons._aws_credentials_1 `, utilisez la fonction [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) avec le paramètre `credentials` pour importer les données, comme indiqué ci-après.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
:'creds'
);
```
Vous pouvez également inclure l’appel de fonction [aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials) en ligne au sein de l’appel de fonction `aws_s3.table_import_from_s3`.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
);
```
## Résolution des problèmes d’accès à Amazon S3
Si vous rencontrez des problèmes de connexion lorsque vous tentez d’importer des données depuis Amazon S3, consultez les recommandations suivantes :
+ [Résolution des problèmes liés à Identity and Access Amazon RDS](security_iam_troubleshoot.md)
+ [Dépannage d’Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html) dans le *Guide de l’utilisateur Amazon Simple Storage Service*.
+ [Dépannage d’Amazon S3 et IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html) dans le *Guide de l’utilisateur IAM*
# Importation de données depuis Amazon S3 vers votre instance de base de données RDS pour PostgreSQL
Vous importez des données depuis votre compartiment Amazon S3 en utilisant la fonction `table_import_from_s3` de l'extension aws\$1s3. Pour obtenir des informations de référence, consultez [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
**Note**
Les exemples suivants utilisent la méthode du rôle IAM pour donner accès au compartiment Amazon S3. Les appels de fonction `aws_s3.table_import_from_s3` n'incluent donc aucun paramètre d'informations d'identification.
L'exemple suivant montre un exemple typique.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't1',
'',
'(format csv)',
:'s3_uri'
);
```
Les paramètres sont les suivants :
+ `t1` – Nom de la table de l'instance de base de données PostgreSQL dans laquelle copier les données.
+ `''` – Liste facultative des colonnes de la table de base de données. Vous pouvez utiliser ce paramètre pour indiquer quelles colonnes des données S3 sont copiées dans quelles colonnes de table. Si aucune colonne n'est spécifiée, toutes les colonnes sont copiées dans la table. Pour obtenir un exemple d'utilisation d'une liste de colonnes, veuillez consulter [Importation d'un fichier Amazon S3 qui utilise un délimiteur personnalisé](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter).
+ `(format csv)` – Arguments PostgreSQL COPY. Le processus de copie utilise les arguments et le format de la commande [PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html) pour importer les données. Les choix de format comprennent les valeurs séparées par des virgules (CSV) comme dans cet exemple, le texte et les données binaires. Par défaut, il s'agit de texte.
+ `s3_uri` – Structure contenant les informations d'identification du fichier Amazon S3. Pour obtenir un exemple d'utilisation de la fonction [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) pour créer une structure `s3_uri`, consultez [Présentation de l’importation de données à partir de données Amazon S3](USER_PostgreSQL.S3Import.Overview.md).
Pour plus d’informations sur cette fonction, consultez [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
La fonction `aws_s3.table_import_from_s3` retourne du texte. Pour spécifier d'autres types de fichiers à importer à partir d'un compartiment Amazon S3, consultez l'un des exemples suivants.
**Note**
L'importation d'un fichier de 0 octet entraîne une erreur.
**Topics**
+ [
## Importation d'un fichier Amazon S3 qui utilise un délimiteur personnalisé
](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter)
+ [
## Importation d'un fichier compressé Amazon S3 (gzip)
](#USER_PostgreSQL.S3Import.FileFormats.gzip)
+ [
## Importation d'un fichier codé Amazon S3
](#USER_PostgreSQL.S3Import.FileFormats.Encoded)
## Importation d'un fichier Amazon S3 qui utilise un délimiteur personnalisé
L'exemple suivant montre comment importer un fichier qui utilise un délimiteur personnalisé. Il montre également comment définir l'emplacement de destination des données dans la table de base de données à l'aide du paramètre `column_list` de la fonction [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
Pour cet exemple, supposons que les informations suivantes sont organisées en colonnes délimitées par une barre verticale dans le fichier Amazon S3.
```
1|foo1|bar1|elephant1
2|foo2|bar2|elephant2
3|foo3|bar3|elephant3
4|foo4|bar4|elephant4
...
```
**Pour importer un fichier qui utilise un délimiteur personnalisé**
1. Créez une table dans la base de données pour les données importées.
```
postgres=> CREATE TABLE test (a text, b text, c text, d text, e text);
```
1. Utilisez le format suivant de la fonction [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) pour importer des données à partir du fichier Amazon S3.
Vous pouvez inclure l'appel de fonction [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) en ligne au sein de l'appel de fonction `aws_s3.table_import_from_s3` pour spécifier le fichier.
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test',
'a,b,d,e',
'DELIMITER ''|''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'pipeDelimitedSampleFile', 'us-east-2')
);
```
Les données se retrouvent désormais dans la table dans les colonnes suivantes.
```
postgres=> SELECT * FROM test;
a | b | c | d | e
---+------+---+---+------+-----------
1 | foo1 | | bar1 | elephant1
2 | foo2 | | bar2 | elephant2
3 | foo3 | | bar3 | elephant3
4 | foo4 | | bar4 | elephant4
```
## Importation d'un fichier compressé Amazon S3 (gzip)
L'exemple suivant montre comment importer un fichier compressé avec gzip à partir d'Amazon S3. Le fichier que vous importez doit comporter les métadonnées Amazon S3 suivantes :
+ Clé : `Content-Encoding`
+ Valeur : `gzip`
Si vous chargez le fichier à l'aide du AWS Management Console, les métadonnées sont généralement appliquées par le système. Pour plus d'informations sur le chargement de fichiers vers Amazon S3 à l'aide de, de AWS Management Console AWS CLI, ou de l'API, consultez la section [Chargement d'objets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html) dans le guide de l'*utilisateur d'Amazon Simple Storage Service*.
Pour de plus amples informations sur les métadonnées Amazon S3 et les métadonnées fournies par le système, veuillez consulter [Editing object metadata in the Amazon S3 console](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
Importez le fichier gzip dans votreinstance de base de données RDS for PostgreSQL comme décrit ci-après.
```
postgres=> CREATE TABLE test_gzip(id int, a text, b text, c text, d text);
postgres=> SELECT aws_s3.table_import_from_s3(
'test_gzip', '', '(format csv)',
'amzn-s3-demo-bucket', 'test-data.gz', 'us-east-2'
);
```
## Importation d'un fichier codé Amazon S3
L'exemple suivant montre comment importer un fichier codé en Windows-1252 à partir d'Amazon S3.
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test_table', '', 'encoding ''WIN1252''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'SampleFile', 'us-east-2')
);
```
# Références de fonctions
**Topics**
+ [
## aws\$1s3.table\$1import\$1from\$1s3
](#aws_s3.table_import_from_s3)
+ [
## aws\$1commons.create\$1s3\$1uri
](#USER_PostgreSQL.S3Import.create_s3_uri)
+ [
## aws\$1commons.create\$1aws\$1credentials
](#USER_PostgreSQL.S3Import.create_aws_credentials)
## aws\$1s3.table\$1import\$1from\$1s3
Importe les données Amazon S3 vers une table Amazon RDS. L'extension `aws_s3` fournit la fonction `aws_s3.table_import_from_s3`. La valeur renvoyée est du texte.
### Syntaxe
Les paramètres requis sont `table_name`, `column_list` et `options`. Ils identifient la table de base de données et spécifient la façon dont les données sont copiées dans la table.
Vous pouvez également utiliser les paramètres suivants :
+ Le paramètre `s3_info` spécifie le fichier Amazon S3 à importer. Lorsque vous utilisez ce paramètre, l'accès à Amazon S3 est fourni par un rôle IAM pour le l'instance de base de données PostgreSQL.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1
)
```
+ Le paramètre `credentials` spécifie les informations d'identification permettant d'accéder à Amazon S3. Lorsque vous utilisez ce paramètre, vous n'utilisez pas de rôle IAM.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1,
credentials aws_commons._aws_credentials_1
)
```
### Parameters
*table\$1name*
Chaîne de texte obligatoire contenant le nom de la table de base de données PostgreSQL dans laquelle importer les données.
*column\$1list*
Chaîne de texte obligatoire contenant la liste facultative des colonnes de la table de base de données PostgreSQL dans lesquelles copier les données. Si la chaîne est vide, toutes les colonnes de la table sont utilisées. Pour obtenir un exemple, veuillez consulter [Importation d'un fichier Amazon S3 qui utilise un délimiteur personnalisé](USER_PostgreSQL.S3Import.FileFormats.md#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter).
*options*
Chaîne de texte obligatoire contenant les arguments de la commande `COPY` de PostgreSQL. Ces arguments spécifient la façon dont les données sont copiées dans la table PostgreSQL. Pour plus d'informations, consultez la [documentation sur la commande COPY de PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html).
*s3\$1info*
Type composite `aws_commons._s3_uri_1` contenant les informations suivantes sur l'objet S3 :
+ `bucket` – Nom du compartiment Amazon S3 contenant le fichier.
+ `file_path` – Nom du fichier Amazon S3, avec le chemin d'accès à celui-ci.
+ `region`— La AWS région dans laquelle se trouve le fichier. Pour obtenir la liste des noms de AWS régions et des valeurs associées, consultez[Régions, zones de disponibilité et zones locales ](Concepts.RegionsAndAvailabilityZones.md).
*credentials*
Type composite `aws_commons._aws_credentials_1` contenant les informations d'identification suivantes à utiliser pour l'opération d'importation :
+ Clé d'accès
+ Clé secrète
+ Jeton de session
Pour plus d'informations sur la création d'une structure composite `aws_commons._aws_credentials_1`, veuillez consulter [aws\$1commons.create\$1aws\$1credentials](#USER_PostgreSQL.S3Import.create_aws_credentials).
### Syntaxe alternative
Pour faciliter le test, vous pouvez utiliser un ensemble étendu de paramètres au lieu des paramètres `s3_info` et `credentials`. Plusieurs variations de syntaxe supplémentaires pour la fonction `aws_s3.table_import_from_s3` sont fournies ci-dessous.
+ Au lieu d'utiliser le paramètre `s3_info` pour identifier un fichier Amazon S3, utilisez la combinaison des paramètres `bucket`, `file_path` et `region`. Sous cette forme, l'accès à Amazon S3 est fourni par un rôle IAM sur l'instance de base de données PostgreSQL.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text
)
```
+ Au lieu d'utiliser le paramètre `credentials` pour spécifier l'accès à Amazon S3, utilisez la combinaison des paramètres `access_key`, `session_key` et `session_token`.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text,
access_key text,
secret_key text,
session_token text
)
```
### Autres paramètres
*bucket*
Chaîne de texte comportant le nom du compartiment Amazon S3 qui contient le fichier.
*file\$1path*
Chaîne de texte contenant le nom du fichier Amazon S3, avec le chemin d'accès à celui-ci.
*region*
Chaîne de texte identifiant l' Région AWS emplacement du fichier. Pour obtenir la liste des Région AWS noms et des valeurs associées, consultez[Régions, zones de disponibilité et zones locales ](Concepts.RegionsAndAvailabilityZones.md).
*access\$1key*
Chaîne de texte contenant la clé d'accès à utiliser pour l'opération d'importation. La valeur par défaut est NULL.
*secret\$1key*
Chaîne de texte contenant la clé secrète à utiliser pour l'opération d'importation. La valeur par défaut est NULL.
*session\$1token*
(Facultatif) Chaîne de texte contenant la clé de session à utiliser pour l'opération d'importation. La valeur par défaut est NULL.
## aws\$1commons.create\$1s3\$1uri
Crée une structure `aws_commons._s3_uri_1` pour contenir les informations relatives au fichier Amazon S3. Utilisez les résultats de la fonction `aws_commons.create_s3_uri` dans le paramètre `s3_info` de la fonction [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3).
### Syntaxe
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```
### Parameters
*bucket*
Chaîne de texte obligatoire contenant le nom du compartiment Amazon S3 pour le fichier.
*file\$1path*
Chaîne de texte obligatoire contenant le nom du fichier Amazon S3, avec le chemin d’accès à celui-ci.
*region*
Chaîne de texte obligatoire Région AWS contenant le contenu du fichier. Pour obtenir la liste des Région AWS noms et des valeurs associées, consultez[Régions, zones de disponibilité et zones locales ](Concepts.RegionsAndAvailabilityZones.md).
## aws\$1commons.create\$1aws\$1credentials
Définit une clé d'accès et une clé secrète dans une structure `aws_commons._aws_credentials_1`. Utilisez les résultats de la fonction `aws_commons.create_aws_credentials` dans le paramètre `credentials` de la fonction [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3).
### Syntaxe
```
aws_commons.create_aws_credentials(
access_key text,
secret_key text,
session_token text
)
```
### Parameters
*access\$1key*
Chaîne de texte obligatoire contenant la clé d'accès à utiliser pour l'importation d'un fichier Amazon S3. La valeur par défaut est NULL.
*secret\$1key*
Chaîne de texte obligatoire contenant la clé secrète à utiliser pour l'importation d'un fichier Amazon S3. La valeur par défaut est NULL.
*session\$1token*
Chaîne de texte facultative contenant le jeton de session à utiliser pour l'importation d'un fichier Amazon S3. La valeur par défaut est NULL. Si vous saisissez le paramètre `session_token` facultatif, vous pouvez utiliser les informations d'identification temporaires.
# Transport de bases de données PostgreSQL entre des instances de base de données
En utilisant les bases de données transportables PostgreSQL pour Amazon RDS, vous pouvez déplacer une base de données PostgreSQL entre deux instances de base de données. Il s'agit d'un moyen très rapide de migrer de grandes bases de données entre différentes instances de base de données. Pour utiliser cette approche, vos instances de base de données doivent toutes deux exécuter la même version majeure de PostgreSQL.
Cette fonctionnalité nécessite que vous installiez l'extension `pg_transport` sur les instances de base de données source et de destination. L'extension `pg_transport` fournit un mécanisme de transport physique qui déplace les fichiers de base de données avec un traitement minimal. Ce mécanisme déplace les données beaucoup plus rapidement que les processus traditionnels de vidage et de chargement, avec moins de temps d'arrêt.
**Note**
Les bases de données transportables PostgreSQL sont disponibles dans RDS for PostgreSQL versions 10.10 et ultérieures, ansi que versions 11.5 et ultérieures.
Pour transporter une instance de base de données PostgreSQL d'une instance de base de données RDS for PostgreSQL à une autre, vous devez d'abord configurer les instances source et de destination, comme indiqué dans la section [ Configuration d'instances de base de données pour leur transport](PostgreSQL.TransportableDB.Setup.md). Vous pouvez ensuite transporter la base de données à l'aide de la fonction décrite dans [ Transport d'une base de données PostgreSQL](PostgreSQL.TransportableDB.Transporting.md).
**Topics**
+ [
## Que se passe-t-il durant le transport d'une base de données ?
](#PostgreSQL.TransportableDB.DuringTransport)
+ [
## Limites à l'utilisation de bases de données transportables PostgreSQL
](#PostgreSQL.TransportableDB.Limits)
+ [
# Configuration pour le transport d'une base de données PostgreSQL
](PostgreSQL.TransportableDB.Setup.md)
+ [
# Transport d'une base de données PostgreSQL vers la destination depuis la source
](PostgreSQL.TransportableDB.Transporting.md)
+ [
# Référence des fonctions des base de données transportables
](PostgreSQL.TransportableDB.transport.import_from_server.md)
+ [
# Référence des paramètres des bases de données transportables
](PostgreSQL.TransportableDB.Parameters.md)
## Que se passe-t-il durant le transport d'une base de données ?
La fonction de bases de données transportables PostgreSQL utilisent un modèle d'extraction pour importer la base de données à partir de l'instance de base de données source. La fonction `transport.import_from_server` crée la base de données en transit sur l'instance de base de données de destination. La base de données en transit est inaccessible sur l'instance de base de données de destination pendant toute la durée du transport.
Lorsque le transport commence, toutes les sessions en cours sur la base de données source cessent. Les bases de données autres que la base de données source sur l'instance de base de données source ne sont pas affectées par le transport.
La base de données source est placée dans un mode lecture seule spécial. Lorsqu'elle est dans ce mode, vous pouvez vous connecter à la base de données source et exécuter des requêtes de lecture seule. Par contre, les requêtes d'écriture et certains autres types de commandes sont bloqués. Seule la base de données source qui fait l'objet du transport est affectée par ces restrictions.
Durant le transport, vous ne pouvez pas restaurer l'instance de base de données de destination à un instant dans le passé. En effet, le transport n'est pas transactionnel et n'utilise pas le journal write-ahead (WAL) PostgreSQL pour enregistrer les modifications. Si les sauvegardes automatiques sont activées sur l'instance de base de données de destination, une sauvegarde est automatiquement effectuée une fois le transport terminé. Point-in-timeles restaurations sont disponibles pendant un certain temps *après* la fin de la sauvegarde.
En cas d'échec du transport, l'extension `pg_transport` tente d'annuler toutes les modifications apportées aux instances de base de données source et de destination. Cela inclut la suppression de la base de données partiellement transportée sur la destination. Selon le type de défaillance, la base de données source peut continuer à rejeter les requêtes d'écriture. Si tel est le cas, utilisez la commande suivante pour autoriser les requêtes d'écriture.
```
ALTER DATABASE db-name SET default_transaction_read_only = false;
```
## Limites à l'utilisation de bases de données transportables PostgreSQL
Les bases de données transportables présentent les limites suivantes :
+ **Réplicas en lecture **– Vous ne pouvez pas utiliser des bases de données transportables sur des réplicas en lecture ou des instances parentes de réplicas en lecture.
+ **Types de colonne non pris en charge** – Vous ne pouvez pas utiliser les types de données `reg` dans des tables de bases de données que vous souhaitez transporter avec cette méthode. Ces types dépendent de l'objet du catalogue système IDs (OIDs), qui change souvent pendant le transport.
+ **Espaces de tables** – Tous les objets de base de données sources doivent se trouver dans l'espace de table `pg_default` par défaut .
+ **Compatibilité** – Les instances de base de données source et destination doivent exécuter la même version majeure de PostgreSQL.
+ **Extensions** : l'instance de base de données source ne peut avoir que `pg_transport` installé.
+ **Rôles et ACLs** — Les privilèges d'accès et les informations de propriété de la base de données source ne sont pas transférés vers la base de données de destination. Tous les objets de base de données sont créés par l'utilisateur de destination locale du transport et sont sa propriété.
+ **Transports simultanés** : une seule instance de base de données peut prendre en charge jusqu'à 32 transports simultanés, y compris les importations et les exportations, si les processus de travail ont été correctement configurés.
+ **Uniquement RDS pour les instances de bases de données PostgreSQL** : les bases de données transportables PostgreSQL ne sont prises en charge que sur les instances de base de données RDS for PostgreSQL. Vous ne pouvez pas l'utiliser avec des bases de données locales ou des bases de données exécutées sur Amazon EC2.
# Configuration pour le transport d'une base de données PostgreSQL
Avant de commencer, vérifiez que vos instances de base de données RDS pour PostgreSQL répondent aux exigences suivantes :
+ Les instances de base de données source et destination doivent exécuter la même version de PostgreSQL.
+ La base de données de destination ne peut pas avoir de base de données portant le même nom que la base de données source que vous souhaitez transporter.
+ Le compte que vous utilisez pour exécuter le transport doit avoir les privilèges `rds_superuser` sur les bases de données source et de destination.
+ Le groupe de sécurité de l'instance de base de données source doit autoriser l'accès entrant depuis l'instance de base de données de destination. C'est peut-être déjà le cas si vos instances de base de données source et de destination se trouvent dans le VPC. Pour plus d’informations sur les groupes de sécurité, consultez [Contrôle d’accès par groupe de sécurité](Overview.RDSSecurityGroups.md).
Le transport de bases de données d'une instance de base de données source vers une instance de base de données de destination nécessite plusieurs modifications apportées au groupe de paramètres de base de données associé à chaque instance. Cela signifie que vous devez créer un groupe de paramètres de base de données personnalisé pour l'instance de base de données source et créer un groupe de paramètres de base de données personnalisé pour l'instance de base de données de destination.
**Note**
Si vos instances de base de données sont déjà configurées à l'aide de groupes de paramètres de base de données personnalisés, vous pouvez commencer par l'étape 2 de la procédure suivante.
**Pour configurer les paramètres de groupe de base de données personnalisés pour le transport de bases de données**
Pour les étapes suivantes, utilisez un compte doté des privilèges `rds_superuser`.
1. Si les instances de base de données source et de destination utilisent un groupe de paramètres de base de données par défaut, vous devez créer un groupe de paramètres de base de données personnalisé à l’aide de la version appropriée pour vos instances. Vous pouvez ainsi modifier les valeurs de plusieurs paramètres. Pour de plus amples informations, veuillez consulter [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
1. Dans le groupe de paramètres de base de données personnalisé, modifiez les valeurs des paramètres suivants :
+ `shared_preload_libraries` : ajoutez `pg_transport` à la liste des bibliothèques.
+ `pg_transport.num_workers` : la valeur par défaut est 3. Augmentez ou réduisez cette valeur au besoin pour votre base de données. Pour une base de données de 200 Go, nous recommandons de ne pas dépasser 8. N'oubliez pas que si vous augmentez la valeur par défaut de ce paramètre, vous devez également augmenter la valeur de `max_worker_processes`.
+ `pg_transport.work_mem` : la valeur par défaut est 128 Mo ou 256 Mo, selon la version PostgreSQL. Le paramètre par défaut peut généralement rester inchangé.
+ `max_worker_processes` : la valeur de ce paramètre doit être définie à l'aide du calcul suivant :
```
(3 * pg_transport.num_workers) + 9
```
Cette valeur est nécessaire au niveau de la destination pour gérer les divers processus employés en arrière-plan impliqués dans le transport. Pour en savoir plus sur `max_worker_processes,`, consultez [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html) (Consommation des ressources) dans la documentation de PostgreSQL.
Pour de plus amples informations sur les paramètres `pg_transport`, consultez [Référence des paramètres des bases de données transportables](PostgreSQL.TransportableDB.Parameters.md).
1. Redémarrez l’instance de base de données source RDS pour PostgreSQL et l’instance de destination pour que les paramètres prennent effet.
1. Connectez-vous à votre instance de base de données source RDS pour PostgreSQL.
```
psql --host=source-instance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Supprimez les extensions externes du schéma public de l'instance de base de données. Seule l'extension `pg_transport` est autorisée pendant l'opération de transport réelle.
1. Installez l'extension `pg_transport` comme suit :
```
postgres=> CREATE EXTENSION pg_transport;
CREATE EXTENSION
```
1. Connectez-vous à votre instance de base de données de destination RDS pour PostgreSQL. Supprimez toutes les extensions externes, puis installez l'extension `pg_transport`.
```
postgres=> CREATE EXTENSION pg_transport;
CREATE EXTENSION
```
# Transport d'une base de données PostgreSQL vers la destination depuis la source
Une fois terminé le processus décrit dans [Configuration pour le transport d'une base de données PostgreSQL](PostgreSQL.TransportableDB.Setup.md), vous pouvez démarrer le transport. Pour cela, exécutez la fonction `transport.import_from_server` sur l'instance de base de données de destination. Dans la syntaxe suivante, vous trouverez les paramètres de la fonction.
```
SELECT transport.import_from_server(
'source-db-instance-endpoint',
source-db-instance-port,
'source-db-instance-user',
'source-user-password',
'source-database-name',
'destination-user-password',
false);
```
Le valeur `false` illustrée dans l'exemple indique à la fonction qu'il ne s'agit pas d'un test. Pour tester la configuration de votre transport, vous pouvez spécifier `true` pour `dry_run` lorsque vous appelez la fonction, comme illustré ci-après :
```
postgres=> SELECT transport.import_from_server(
'docs-lab-source-db.666666666666aws-region.rds.amazonaws.com', 5432,
'postgres', '********', 'labdb', '******', true);
INFO: Starting dry-run of import of database "labdb".
INFO: Created connections to remote database (took 0.03 seconds).
INFO: Checked remote cluster compatibility (took 0.05 seconds).
INFO: Dry-run complete (took 0.08 seconds total).
import_from_server
--------------------
(1 row)
```
Les lignes INFO sont affichées car le paramètre `pg_transport.timing` est défini sur sa valeur par défaut, à savoir `true`. Définissez `dry_run` à la valeur `false` lorsque vous exécutez la commande et que la base de données source est importée vers la destination, comme indiqué ci-dessous :
```
INFO: Starting import of database "labdb".
INFO: Created connections to remote database (took 0.02 seconds).
INFO: Marked remote database as read only (took 0.13 seconds).
INFO: Checked remote cluster compatibility (took 0.03 seconds).
INFO: Signaled creation of PITR blackout window (took 2.01 seconds).
INFO: Applied remote database schema pre-data (took 0.50 seconds).
INFO: Created connections to local cluster (took 0.01 seconds).
INFO: Locked down destination database (took 0.00 seconds).
INFO: Completed transfer of database files (took 0.24 seconds).
INFO: Completed clean up (took 1.02 seconds).
INFO: Physical transport complete (took 3.97 seconds total).
import_from_server
--------------------
(1 row)
```
Cette fonction nécessite que vous fournissiez les mots de passe utilisateur de la base de données. Nous vous recommandons donc de modifier les mots de passe des rôles utilisateur que vous avez utilisés une fois le transport terminé. Vous pouvez aussi utiliser des variables de liaison SQL pour créer des rôles utilisateur temporaires. Utilisez ces rôles temporaires pour le transport, puis supprimez-les une fois que vous n'en avez plus besoin.
Si votre transport n'est pas réussi, vous pouvez voir un message d'erreur similaire à ce qui suit :
```
pg_transport.num_workers=8 25% of files transported failed to download file data
```
Le message d'erreur « Impossible de télécharger les données du fichier » indique que le nombre de processus de travail n'est pas défini correctement pour la taille de la base de données. Vous devrez peut-être augmenter ou diminuer la valeur définie pour `pg_transport.num_workers`. Chaque échec indique le pourcentage d'achèvement, afin que vous puissiez voir l'impact de vos modifications. Par exemple, la modification du paramètre de 8 à 4 dans un cas a entraîné les résultats suivants :
```
pg_transport.num_workers=4 75% of files transported failed to download file data
```
Gardez à l'esprit que le paramètre `max_worker_processes` est également pris en compte pendant le processus de transport. Autrement dit, vous devrez peut-être modifier à la fois `pg_transport.num_workers` et `max_worker_processes` pour transporter correctement la base de données. L'exemple présenté a finalement fonctionné lorsque le `pg_transport.num_workers` a été réglé sur 2 :
```
pg_transport.num_workers=2 100% of files transported
```
Pour plus d'informations sur la fonction `transport.import_from_server` et ses paramètres, veuillez consulter [Référence des fonctions des base de données transportables](PostgreSQL.TransportableDB.transport.import_from_server.md).
# Référence des fonctions des base de données transportables
La fonction `transport.import_from_server` transporte une base de données PostgreSQL en l'important d'une instance de base de données source vers une instance de base de données de destination. Elle effectue cette opération en utilisant un mécanisme de transport physique de connexion de base de données.
Avant de démarrer le transport, cette fonction vérifie que les instances de base de données source et de destination sont de la même version et sont compatibles avec la migration. Elle confirme également que l'instance de base de données de destination dispose de suffisamment d'espace pour la source.
**Syntaxe**
```
transport.import_from_server(
host text,
port int,
username text,
password text,
database text,
local_password text,
dry_run bool
)
```
**Valeur renvoyée**
Aucun.
**Paramètres**
Le tableau ci-dessous contient les descriptions des paramètres de la fonction `transport.import_from_server`.
****
| Paramètre | Description |
| --- | --- |
| host | Point de terminaison de l'instance de base de données source. |
| port | Entier représentant le port de l'instance de base de données source. Les instances de base de données PostgreSQL utilisent souvent le port 5432. |
| username | Utilisateur de l'instance de base de données source. Cet utilisateur doit être membre du rôle `rds_superuser`. |
| password | Mot de passe utilisateur de l'instance de base de données source. |
| database | Nom de la base de données à transporter à partir de l'instance de base de données source. |
| local\$1password | Mot de passe local de l'utilisateur actuel pour l'instance de base de données de destination. Cet utilisateur doit être membre du rôle `rds_superuser`. |
| dry\$1run | Valeur booléenne facultative spécifiant si un essai est nécessaire. La valeur par défaut est `false`, ce qui signifie que le transport est effectué.Pour vérifier la compatibilité entre les instances de base de données source et de destination sans effectuer le transport réel, définissez dry\$1run sur true. |
**Exemple**
Pour obtenir un exemple, consultez [Transport d'une base de données PostgreSQL vers la destination depuis la source](PostgreSQL.TransportableDB.Transporting.md).
# Référence des paramètres des bases de données transportables
Plusieurs paramètres contrôlent le comportement de l'extension `pg_transport`. Vous trouverez ci-dessous la description de ces paramètres.
**`pg_transport.num_workers`**
Le nombre d'unités de travail à utiliser pour le processus de transport. La valeur par défaut est 3. Les valeurs valides vont de 1 à 32. Même les transports de base de données les plus volumineux nécessitent généralement moins de 8 unités de travail. La valeur de ce paramètre sur l'instance de base de données de destination est utilisée par la destination et la source pendant le transport.
**`pg_transport.timing` **
Indique s'il faut signaler les informations de synchronisation pendant le transport. La valeur par défaut est `true`, ce qui signifie que les informations de synchronisation sont signalées. Nous vous recommandons de laisser ce paramètre défini sur `true` pour que vous puissiez suivre les progrès réalisés. Pour un exemple de sortie, veuillez consulter [Transport d'une base de données PostgreSQL vers la destination depuis la source](PostgreSQL.TransportableDB.Transporting.md).
**`pg_transport.work_mem`**
Quantité de mémoire maximale à allouer à chaque unité de travail. La valeur par défaut est 131 072 kilo-octets (Ko) ou 262 144 Ko (256 Mo), selon la version PostgreSQL. La valeur minimale est de 64 méga-octets (65 536 Ko). Les valeurs valides sont exprimées en kilo-octets (KBs) sous forme d'unités binaires en base 2, où 1 Ko = 1024 octets.
Le transport peut utiliser moins de mémoire que spécifié dans ce paramètre. Même les transports de base de données volumineux nécessitent généralement moins de 256 Mo (262 144 Ko) de mémoire par unité de travail.
# Exportation de données à partir d’une instance de base de données RDS pour PostgreSQL vers Amazon S3
Vous pouvez interroger des données à partir d’une instance de base de données RDS pour PostgreSQL et les exporter directement dans des fichiers stockés dans un compartiment Amazon S3. Pour ce faire, vous devez d’abord installer l’extension `aws_s3` RDS pour PostgreSQL. Cette extension vous fournit les fonctions que vous utilisez pour exporter les résultats des requêtes vers Amazon S3. Vous trouverez ci-dessous comment installer l’extension et comment exporter des données vers Amazon S3.
**Note**
L’exportation intercompte vers Amazon S3 n’est pas prise en charge.
Toutes les versions actuellement disponibles de RDS pour PostgreSQL prennent en charge l’exportation de données vers Amazon Simple Storage Service. Pour des informations détaillées sur les versions, consultez [Mises à jour d’Amazon RDS pour PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html) dans *Notes de mise à jour d’Amazon RDS pour PostgreSQL*.
Si vous n’avez pas de compartiment configuré pour votre exportation, consultez les rubriques suivantes du *Guide de l’utilisateur d’Amazon Simple Storage Service*.
+ [Configuration d’Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/setting-up-s3.html)
+ [Création d’un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)
Par défaut, les données exportées depuis RDS pour PostgreSQL vers Amazon S3 utilisent un chiffrement côté serveur avec une Clé gérée par AWS. Si vous utilisez le chiffrement par compartiment, le compartiment Amazon S3 doit être chiffré avec une clé AWS Key Management Service (AWS KMS) (SSE-KMS). Actuellement, les compartiments chiffrés avec des clés gérées par Amazon S3 (SSE-S3) ne sont pas pris en charge.
**Note**
Vous pouvez enregistrer les données des instantanés de base de données sur Amazon S3 à l'aide de l'API AWS Management Console AWS CLI, ou Amazon RDS. Pour de plus amples informations, veuillez consulter [Exportation de données d’instantanés de bases de données vers Amazon S3 pour Amazon RDS](USER_ExportSnapshot.md).
**Topics**
+ [
## Installation de l’extension aws\$1s3
](#USER_PostgreSQL.S3Export.InstallExtension)
+ [
## Présentation de l’exportation de données vers Amazon S3
](#postgresql-s3-export-overview)
+ [
## Spécification du chemin d’accès au fichier Amazon S3 vers lequel effectuer l’exportation
](#postgresql-s3-export-file)
+ [
# Configuration de l’accès à un compartiment Amazon S3
](postgresql-s3-export-access-bucket.md)
+ [
# Exportation de données de requête à l’aide de la fonction aws\$1s3.query\$1export\$1to\$1s3
](postgresql-s3-export-examples.md)
+ [
# Références de fonctions
](postgresql-s3-export-functions.md)
+ [
# Résolution des problèmes d'accès à Amazon S3
](postgresql-s3-export-troubleshoot.md)
## Installation de l’extension aws\$1s3
Avant de pouvoir utiliser Amazon Simple Storage Service avec votre instance de base de données RDS pour PostgreSQL, vous devez installer l’extension `aws_s3`. Cette extension fournit des fonctions pour exporter des données depuis une instance de base de données RDS pour PostgreSQL vers un compartiment Amazon S3. Il fournit également des fonctions pour importer des données depuis un compartiment Amazon S3. Pour plus d’informations, consultez [Importation de données Amazon S3 dans une instance de base de données RDS for PostgreSQL d'un ](USER_PostgreSQL.S3Import.md). L’extension `aws_s3` dépend de certaines des fonctions d’aide de l’extension `aws_commons`, qui est installée automatiquement lorsque cela est nécessaire.
**Pour installer l’extension `aws_s3`**
1. Utilisez psql (ou pgAdmin) pour vous connecter à l’instance de base de données RDS pour PostgreSQL en tant qu’utilisateur disposant de privilèges `rds_superuser`. Si vous avez conservé le nom par défaut pendant le processus d’installation, vous vous connectez en tant que `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Pour installer l’extension, exécutez la commande suivante.
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. Pour vérifier que l’extension est installée, vous pouvez utiliser la métacommande psql `\dx`.
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
Les fonctions d’importation de données depuis Amazon S3 et d’exportation de données vers Amazon S3 sont désormais disponibles.
### Vérifiez que votre version de RDS pour PostgreSQL Aurora PostgreSQL en charge les exportations vers Amazon S3
Vous pouvez vérifier que votre version de RDS pour PostgreSQL prend en charge l’exportation vers Amazon S3 en utilisant la commande `describe-db-engine-versions`. L’exemple suivant vérifie la prise en charge de la version 10.14.
```
aws rds describe-db-engine-versions --region us-east-1
--engine postgres --engine-version 10.14 | grep s3Export
```
Si la sortie inclut la chaîne `"s3Export"`, le moteur prend en charge les exportations Amazon S3. Sinon, le moteur ne les prend pas en charge.
## Présentation de l’exportation de données vers Amazon S3
Pour exporter des données stockées dans un RDS pour PostgreSQL vers un compartiment Amazon S3, procédez comme suit.
**Pour exporter des données RDS pour PostgreSQL vers S3**
1. Identifiez un chemin d’accès de fichier Amazon S3 à utiliser pour exporter des données. Pour plus d’informations sur ce processus, consultez [Spécification du chemin d’accès au fichier Amazon S3 vers lequel effectuer l’exportation](#postgresql-s3-export-file).
1. Fournissez une autorisation d’accès au compartiment Amazon S3.
Pour exporter des données vers un fichier Amazon S3, vous devez accorder à l’instance de base de données RDS pour PostgreSQL l’autorisation d’accéder au compartiment Amazon S3 que l’exportation utilisera pour le stockage. Cette opération comprend les étapes suivantes :
1. Créez une politique IAM donnant accès à un compartiment Amazon S3 vers lequel vous souhaitez exporter.
1. Créez un rôle IAM.
1. Attachez la politique que vous avez créée au rôle que vous avez créé.
1. Ajoutez ce rôle IAM à votre instance de base de données.
Pour plus d’informations sur ce processus, consultez [Configuration de l’accès à un compartiment Amazon S3](postgresql-s3-export-access-bucket.md).
1. Identifiez une requête de base de données pour obtenir les données. Exportez les données de requête en appelant la fonction `aws_s3.query_export_to_s3`.
Après avoir terminé les tâches de préparation précédentes, utilisez la fonction [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) pour exporter les résultats de requête vers Amazon S3. Pour plus d’informations sur ce processus, consultez [Exportation de données de requête à l’aide de la fonction aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
## Spécification du chemin d’accès au fichier Amazon S3 vers lequel effectuer l’exportation
Spécifiez les informations suivantes pour identifier l’emplacement dans Amazon S3 vers lequel vous souhaitez exporter des données :
+ Nom du compartiment : un *compartiment* est un conteneur d’objets ou de fichiers Amazon S3.
Pour plus d’informations sur le stockage de données avec Amazon S3, consultez [Création d’un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) et [Utilisation des objets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-downloading-objects.html) dans le *Guide de l’utilisateur Amazon Simple Storage Service*.
+ Chemin d’accès au fichier : le chemin d’accès au fichier identifie l’emplacement de stockage de l’exportation dans le compartiment Amazon S3. Le chemin d’accès au fichier se compose des éléments suivants :
+ Préfixe de chemin facultatif qui identifie un chemin d’accès à un dossier virtuel.
+ Préfixe de fichier qui identifie un ou plusieurs fichiers à stocker. Les exportations les plus volumineuses sont stockées dans plusieurs fichiers, chacun ayant une taille maximale d’environ 6 Go. Les noms de fichiers supplémentaires ont le même préfixe de fichier mais en ajoutant `_partXX`. `XX` représente 2, puis 3, et ainsi de suite.
Par exemple, un chemin d’accès de fichier avec un dossier `exports` et un préfixe de fichier `query-1-export` sera représenté par `/exports/query-1-export`.
+ AWS Région (facultatif) : AWS région dans laquelle se trouve le compartiment Amazon S3. Si vous ne spécifiez aucune valeur de AWS région, Amazon RDS enregistre vos fichiers dans Amazon S3 dans la même AWS région que l'instance de base de données du cluster exportant.
**Note**
Actuellement, la AWS région doit être identique à la région de l'instance de base de données du de bases de données exportatrice.
Pour obtenir la liste des noms de AWS régions et des valeurs associées, consultez[Régions, zones de disponibilité et zones locales ](Concepts.RegionsAndAvailabilityZones.md).
Pour conserver les informations de fichier Amazon S3 sur l’emplacement de stockage de l’exportation, vous pouvez utiliser la fonction [aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri) pour créer une structure composite `aws_commons._s3_uri_1` comme suit.
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
Vous fournissez ultérieurement cette valeur `s3_uri_1` en tant que paramètre dans l’appel à la fonction [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3). Pour obtenir des exemples, consultez [Exportation de données de requête à l’aide de la fonction aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
# Configuration de l’accès à un compartiment Amazon S3
Pour exporter des données vers Amazon S3, accordez à votre instance l’autorisation d’accéder au compartiment Amazon S3 dans lequel les fichiers doivent être stockés.
Pour cela, procédez comme suit :
**Pour donner à une instance de base de données PostgreSQL l’accès à Amazon S3 via un rôle IAM**
1. Créez une politique IAM.
Cette stratégie fournit le compartiment et les autorisations d’objet permettant à votre instance de base de données PostgreSQL d’accéder à Amazon S3.
Dans le cadre de la création de cette politique, procédez comme suit :
1. Incluez dans la stratégie les actions obligatoires suivantes pour permettre le transfert de fichiers de votre instance de base de données PostgreSQL vers un compartiment Amazon S3 :
+ `s3:PutObject`
+ `s3:AbortMultipartUpload`
1. Incluez l’Amazon Resource Name (ARN) qui identifie le compartiment Amazon S3 et les objets du compartiment. Le format ARN pour l’accès à Amazon S3 est le suivant : `arn:aws:s3:::amzn-s3-demo-bucket/*`
Pour plus d’informations sur la création d’une politique IAM pour Amazon RDS pour PostgreSQL, consultez [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). Consultez également [Didacticiel : création et attachement de votre première politique gérée par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) dans le *Guide de l’utilisateur IAM*.
La AWS CLI commande suivante crée une politique IAM nommée `rds-s3-export-policy` avec ces options. Elle accorde un accès à un compartiment nommé *amzn-s3-demo-bucket*.
**Avertissement**
Nous vous recommandons de configurer votre base de données dans un VPC privé dont les politiques de point de terminaison sont configurées pour accéder à des compartiments spécifiques. Pour plus d’informations, consultez [Utilisation des stratégies de point de terminaison pour Amazon S3](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-s3.html#vpc-endpoints-policies-s3) dans le Guide de l’utilisateur Amazon VPC.
Nous vous recommandons vivement de ne pas créer de politique avec accès à toutes les ressources. Cet accès peut constituer une menace pour la sécurité des données. Si vous créez une stratégie qui accorde à `S3:PutObject` un accès à toutes les ressources à l’aide de `"Resource":"*"`, un utilisateur disposant de privilèges d’exportation peut exporter des données vers tous les compartiments de votre compte. En outre, l’utilisateur peut exporter des données vers *n’importe quel compartiment accessible publiquement en écriture dans votre région AWS *.
Après avoir créé la politique, notez son ARN (Amazon Resource Name). Vous en aurez besoin par la suite pour attacher la politique à un rôle IAM.
```
aws iam create-policy --policy-name rds-s3-export-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3export",
"Action": [
"s3:PutObject*",
"s3:ListBucket",
"s3:GetObject*",
"s3:DeleteObject*",
"s3:GetBucketLocation",
"s3:AbortMultipartUpload"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. Créez un rôle IAM.
L’objectif est ici de permettre à Amazon RDS d’endosser ce rôle IAM en votre nom pour accéder à vos compartiments Amazon S3. Pour plus d’informations, consultez [Création d’un rôle pour déléguer des autorisations à un utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) dans le *Guide de l’utilisateur IAM*.
Nous vous recommandons d’utiliser les clés de contexte de condition globale `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` et `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` dans des politiques basées sur les ressources pour limiter les autorisations du service à une ressource spécifique. C’est le moyen le plus efficace de se protéger contre le [problème du député confus](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
Si vous utilisez les deux clés de contexte de condition globale et que la valeur de `aws:SourceArn` contient l’ID de compte, la valeur de `aws:SourceAccount` et le compte indiqué dans la valeur de `aws:SourceArn` doivent utiliser le même ID de compte lorsqu’il est utilisé dans la même déclaration de politique.
+ Utilisez `aws:SourceArn` si vous souhaitez un accès interservices pour une seule ressource.
+ Utilisez `aws:SourceAccount` si vous souhaitez autoriser une ressource de ce compte à être associée à l’utilisation interservices.
Dans la politique, veillez à utiliser la clé de contexte de condition globale `aws:SourceArn` avec l’ARN complet de la ressource. L'exemple suivant montre comment procéder à l'aide de la AWS CLI commande pour créer un rôle nommé`rds-s3-export-role`.
**Example**
Pour Linux, macOS ou Unix :
```
aws iam create-role \
--role-name rds-s3-export-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
Pour Windows :
```
aws iam create-role ^
--role-name rds-s3-export-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
1. Attachez la politique IAM que vous avez créée au rôle IAM que vous venez de créer.
La AWS CLI commande suivante associe la politique créée précédemment au rôle nommé `rds-s3-export-role.` Remplacer `your-policy-arn` par l'ARN de stratégie que vous avez noté lors d'une étape précédente.
```
aws iam attach-role-policy --policy-arn your-policy-arn --role-name rds-s3-export-role
```
1. Ajoutez le rôle IAM à l’instance de base de données. Pour ce faire, utilisez le AWS Management Console ou AWS CLI, comme décrit ci-dessous.
## Console
**Pour ajouter un rôle IAM à l’instance de base de données PostgreSQL à l’aide de la console**
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. Choisissez le nom de l’instance de base de données PostgreSQL pour afficher ses détails.
1. Dans l’onglet **Connectivité & sécurité** de la section **Gérer les rôles IAM**, choisissez le rôle à ajouter sous **Ajouter des rôles IAM à cette instance**.
1. Sous **Fonctionnalité**, choisissez **s3Export**.
1. Choisissez **Ajouter un rôle**.
## AWS CLI
**Pour ajouter un rôle IAM à une instance de base de données PostgreSQL à l’aide de la CLI**
+ Utilisez la commande suivante pour ajouter le rôle à l’instance de base de données PostgreSQL nommée `my-db-instance`. Remplacez *`your-role-arn`* par l’ARN de rôle que vous avez noté lors d’une étape précédente. Utilisez `s3Export` comme valeur de l’option `--feature-name`.
**Example**
Pour Linux, macOS ou Unix :
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-db-instance \
--feature-name s3Export \
--role-arn your-role-arn \
--region your-region
```
Pour Windows :
```
aws rds add-role-to-db-instance ^
--db-instance-identifier my-db-instance ^
--feature-name s3Export ^
--role-arn your-role-arn ^
--region your-region
```
# Exportation de données de requête à l’aide de la fonction aws\$1s3.query\$1export\$1to\$1s3
Exportez vos données PostgreSQL vers Amazon S3 en appelant la fonction [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3).
**Topics**
+ [
## Conditions préalables
](#postgresql-s3-export-examples-prerequisites)
+ [
## Appel de aws\$1s3.query\$1export\$1to\$1s3
](#postgresql-s3-export-examples-basic)
+ [
## Exportation vers un fichier CSV qui utilise un délimiteur personnalisé
](#postgresql-s3-export-examples-custom-delimiter)
+ [
## Exportation vers un fichier binaire avec encodage
](#postgresql-s3-export-examples-encoded)
## Conditions préalables
Avant d’utiliser la fonction `aws_s3.query_export_to_s3`, assurez-vous de remplir les conditions préalables suivantes :
+ Installez les extensions PostgreSQL requises comme décrit dans [Présentation de l’exportation de données vers Amazon S3](postgresql-s3-export.md#postgresql-s3-export-overview).
+ Déterminez vers quel emplacement Amazon S3 exporter vos données comme décrit dans [Spécification du chemin d’accès au fichier Amazon S3 vers lequel effectuer l’exportation](postgresql-s3-export.md#postgresql-s3-export-file).
+ Assurez-vous que l’instance de base de données dispose d’un accès à Amazon S3 comme décrit dans [Configuration de l’accès à un compartiment Amazon S3](postgresql-s3-export-access-bucket.md).
Les exemples suivants utilisent une table de base de données appelée `sample_table`. Ces exemples exportent les données dans un compartiment appelé *amzn-s3-demo-bucket*. Les exemples de table et de données sont créés avec les instructions SQL suivantes dans psql.
```
psql=> CREATE TABLE sample_table (bid bigint PRIMARY KEY, name varchar(80));
psql=> INSERT INTO sample_table (bid,name) VALUES (1, 'Monday'), (2,'Tuesday'), (3, 'Wednesday');
```
## Appel de aws\$1s3.query\$1export\$1to\$1s3
Ce qui suit montre les techniques de base permettant d’appeler la fonction [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3).
Ces exemples utilisent la variable `s3_uri_1` pour identifier une structure contenant les informations identifiant le fichier Amazon S3. Utilisez la fonction [aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri) pour créer la structure.
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
Bien que les paramètres varient pour les deux appels de fonction `aws_s3.query_export_to_s3` suivants, les résultats sont les mêmes pour ces exemples. Toutes les lignes de la table `sample_table` sont exportées dans un compartiment appelé *amzn-s3-demo-bucket*.
```
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1');
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1', options :='format text');
```
Les paramètres sont décrits comme suit :
+ `'SELECT * FROM sample_table'` – Le premier paramètre est une chaîne de texte obligatoire contenant une requête SQL. Le moteur PostgreSQL exécute cette requête. Les résultats de la requête sont copiés dans le compartiment S3 identifié dans d’autres paramètres.
+ `:'s3_uri_1'` – Ce paramètre est une structure qui identifie le fichier Amazon S3. Cet exemple utilise une variable pour identifier la structure créée précédemment. Vous pouvez plutôt créer la structure en incluant l’appel de fonction `aws_commons.create_s3_uri` en ligne dans l’appel de fonction `aws_s3.query_export_to_s3` comme suit.
```
SELECT * from aws_s3.query_export_to_s3('select * from sample_table',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'sample-filepath', 'us-west-2')
);
```
+ `options :='format text'` – Le paramètre `options` est une chaîne de texte facultative contenant des arguments `COPY` PostgreSQL. Le processus de copie utilise les arguments et le format de la commande [PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html).
Si le fichier spécifié n’existe pas dans le compartiment Amazon S3, il est créé. Si le fichier existe déjà, il est remplacé. La syntaxe d’accès aux données exportées dans Amazon S3 est la suivante.
```
s3-region://bucket-name[/path-prefix]/file-prefix
```
Les exportations les plus volumineuses sont stockées dans plusieurs fichiers, chacun ayant une taille maximale d’environ 6 Go. Les noms de fichiers supplémentaires ont le même préfixe de fichier mais en ajoutant `_partXX`. `XX` représente 2, puis 3, et ainsi de suite. Par exemple, supposons que vous spécifiiez le chemin d’accès où vous stockez les fichiers de données comme suit.
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
```
Si l’exportation doit créer trois fichiers de données, le compartiment Amazon S3 contient les fichiers de données suivants.
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part2
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part3
```
Pour obtenir la référence complète de cette fonction et les moyens supplémentaires de l’appeler, consultez [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3). Pour plus d’informations sur l’accès aux fichiers dans Amazon S3, consultez [Afficher un objet](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html) dans le *Guide de l’utilisateur Amazon Simple Storage Service*.
## Exportation vers un fichier CSV qui utilise un délimiteur personnalisé
L’exemple suivant montre comment appeler la fonction [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) pour exporter des données vers un fichier qui utilise un délimiteur personnalisé. L’exemple utilise les arguments de la commande [PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html) pour spécifier le format CSV (valeur séparée par des virgules) et un délimiteur deux-points ( :).
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format csv, delimiter $$:$$');
```
## Exportation vers un fichier binaire avec encodage
L’exemple suivant montre comment appeler la fonction [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) pour exporter des données vers un fichier binaire ayant un encodage Windows-1253.
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format binary, encoding WIN1253');
```
# Références de fonctions
**Topics**
+ [
## aws\$1s3.query\$1export\$1to\$1s3
](#aws_s3.export_query_to_s3)
+ [
## aws\$1commons.create\$1s3\$1uri
](#aws_commons.create_s3_uri)
## aws\$1s3.query\$1export\$1to\$1s3
Exporte un résultat de requête PostgreSQL vers un compartiment Amazon S3. L’extension `aws_s3` fournit la fonction `aws_s3.query_export_to_s3`.
Les deux paramètres requis sont `query` et `s3_info`. Ils définissent la requête à exporter et identifient le compartiment Amazon S3 vers lequel effectuer l’exportation. Un paramètre facultatif appelé `options` permet de définir différents paramètres d’exportation. Pour obtenir des exemples d’utilisation de la fonction `aws_s3.query_export_to_s3`, consultez [Exportation de données de requête à l’aide de la fonction aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
**Syntaxe**
```
aws_s3.query_export_to_s3(
query text,
s3_info aws_commons._s3_uri_1,
options text,
kms_key text
)
```Paramètres d’entrée
*query*
Chaîne de texte obligatoire contenant une requête SQL exécutée par le moteur PostgreSQL. Les résultats de cette requête sont copiés dans un compartiment S3 identifié dans le paramètre `s3_info`.
*s3\$1info*
Type composite `aws_commons._s3_uri_1` contenant les informations suivantes sur l’objet S3 :
+ `bucket` – Nom du compartiment Amazon S3 contenant le fichier.
+ `file_path` : nom du fichier Amazon S3 et chemin d’accès à celui-ci.
+ `region`— La AWS région dans laquelle se trouve le compartiment. Pour obtenir la liste des noms de AWS régions et des valeurs associées, consultez[Régions, zones de disponibilité et zones locales ](Concepts.RegionsAndAvailabilityZones.md).
Actuellement, cette valeur doit être la même AWS région que celle de l'instance de base de données du de bases de données exportatrice. La valeur par défaut est la AWS région de l'instance de base de données du de bases de données exportatrice.
Pour créer une structure composite `aws_commons._s3_uri_1`, consultez [aws\$1commons.create\$1s3\$1uri](#aws_commons.create_s3_uri) fonction.
*options*
Chaîne de texte facultative contenant les arguments de la commande `COPY` de PostgreSQL. Ces arguments spécifient la façon dont les données doivent être copiées lors de l’exportation. Pour plus d’informations, consultez la [documentation sur la commande COPY de PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html).
*kms\$1key text*
Chaîne de texte facultative contenant la clé KMS gérée par le client du compartiment S3 vers lequel exporter les données.
### Autres paramètres d’entrée
Pour faciliter le test, vous pouvez utiliser un ensemble étendu de paramètres au lieu du paramètre `s3_info`. Plusieurs variations de syntaxe supplémentaires pour la fonction `aws_s3.query_export_to_s3` sont fournies ci-dessous.
Au lieu d’utiliser le paramètre `s3_info` pour identifier un fichier Amazon S3, utilisez la combinaison des paramètres `bucket`, `file_path` et `region`.
```
aws_s3.query_export_to_s3(
query text,
bucket text,
file_path text,
region text,
options text,
kms_key text
)
```
*query*
Chaîne de texte obligatoire contenant une requête SQL exécutée par le moteur PostgreSQL. Les résultats de cette requête sont copiés dans un compartiment S3 identifié dans le paramètre `s3_info`.
*bucket*
Chaîne de texte obligatoire comportant le nom du compartiment Amazon S3 qui contient le fichier.
*file\$1path*
Chaîne de texte obligatoire contenant le nom du fichier Amazon S3, avec le chemin d’accès à celui-ci.
*region*
Chaîne de texte facultative contenant la AWS région dans laquelle se trouve le compartiment. Pour obtenir la liste des noms de AWS régions et des valeurs associées, consultez[Régions, zones de disponibilité et zones locales ](Concepts.RegionsAndAvailabilityZones.md).
Actuellement, cette valeur doit être la même AWS région que celle de l'instance de base de données du de bases de données exportatrice. La valeur par défaut est la AWS région de l'instance de base de données du de bases de données exportatrice.
*options*
Chaîne de texte facultative contenant les arguments de la commande `COPY` de PostgreSQL. Ces arguments spécifient la façon dont les données doivent être copiées lors de l’exportation. Pour plus d’informations, consultez la [documentation sur la commande COPY de PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html).
*kms\$1key text*
Chaîne de texte facultative contenant la clé KMS gérée par le client du compartiment S3 vers lequel exporter les données.
### Paramètres de sortie
```
aws_s3.query_export_to_s3(
OUT rows_uploaded bigint,
OUT files_uploaded bigint,
OUT bytes_uploaded bigint
)
```
*rows\$1uploaded*
Nombre de lignes de table qui ont été téléchargées avec succès vers Amazon S3 pour la requête donnée.
*files\$1uploaded*
Nombre de fichiers téléchargés vers Amazon S3. Les fichiers sont créés avec des tailles d’environ 6 Go. Chaque fichier supplémentaire créé voit l’élément `_partXX` ajouté à son nom. `XX` représente 2, puis 3, et ainsi de suite.
*bytes\$1uploaded*
Nombre total d’octets téléchargés vers Amazon S3.
### Exemples
```
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2','format text');
```
## aws\$1commons.create\$1s3\$1uri
Crée une structure `aws_commons._s3_uri_1` pour contenir les informations relatives au fichier Amazon S3. Vous utilisez les résultats de la fonction `aws_commons.create_s3_uri` dans le paramètre `s3_info` de la fonction [aws\$1s3.query\$1export\$1to\$1s3](#aws_s3.export_query_to_s3). Pour obtenir un exemple d’utilisation de la fonction `aws_commons.create_s3_uri`, consultez [Spécification du chemin d’accès au fichier Amazon S3 vers lequel effectuer l’exportation](postgresql-s3-export.md#postgresql-s3-export-file).
**Syntaxe**
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```Paramètres d’entrée
*bucket*
Chaîne de texte obligatoire contenant le nom du compartiment Amazon S3 pour le fichier.
*file\$1path*
Chaîne de texte obligatoire contenant le nom du fichier Amazon S3, avec le chemin d’accès à celui-ci.
*region*
Chaîne de texte obligatoire contenant la AWS région dans laquelle se trouve le fichier. Pour obtenir la liste des noms de AWS régions et des valeurs associées, consultez[Régions, zones de disponibilité et zones locales ](Concepts.RegionsAndAvailabilityZones.md).
# Résolution des problèmes d'accès à Amazon S3
Si vous rencontrez des problèmes de connexion lorsque vous essayez d'exporter des données vers Amazon S3, confirmez d'abord que les règles d'accès sortant du groupe de sécurité VPC associé à votre instance de base de données permettent la connectivité réseau. Plus précisément, le groupe de sécurité doit comporter une règle qui autorise l'instance de base de données à envoyer du trafic TCP au port 443 et à toute adresse IPv4 (0.0.0.0/0). Pour de plus amples informations, consultez [Créer un groupe de sécurité qui autorise l'accès à votre instance de base de données dans votre VPC](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup).
Voir également les recommandations suivantes :
+ [Résolution des problèmes liés à Identity and Access Amazon RDS](security_iam_troubleshoot.md)
+ [Dépannage d'Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
+ [Dépannage d'Amazon S3 et IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html) dans le *Guide de l'utilisateur IAM*
# Invocation d'une AWS Lambda fonction depuis une instance de base de données
AWS Lambda est un service de calcul piloté par les événements qui vous permet d'exécuter du code sans provisionner ni gérer de serveurs. Il peut être utilisé avec de nombreux AWS services, notamment RDS pour PostgreSQL. Par exemple, vous pouvez utiliser des fonctions Lambda pour traiter les notifications d’événements à partir d’une base de données ou pour charger des données à partir de fichiers chaque fois qu’un nouveau fichier est chargé sur Amazon S3. Pour en savoir plus sur Lambda, consultez [Qu'est-ce que c'est ? AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) dans le *Guide AWS Lambda du développeur.*
**Note**
L'appel d'une AWS Lambda fonction est pris en charge dans les versions RDS pour PostgreSQL suivantes :
Toutes les versions de PostgreSQL 18
Toutes les versions de PostgreSQL 17
Toutes les versions de PostgreSQL 16
Toutes les versions de PostgreSQL 15
PostgreSQL 14.1 et versions mineures ultérieures
PostgreSQL 13.2 et versions mineures ultérieures
PostgreSQL 12.6 et versions mineures ultérieures
Vous trouverez ci-après des résumés des étapes nécessaires.
Pour plus d’informations sur les fonctions Lambda, consultez [Mise en route avec Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) et [Principes de base d’AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-foundation.html) dans le *Guide du développeur AWS Lambda *.
**Topics**
+ [
## Étape 1 : configurer votre instance de base de données pour les connexions sortantes vers AWS Lambda
](#PostgreSQL-Lambda-network)
+ [
## Étape 2 : configurer IAM pour votre instance de base de données et AWS Lambda
](#PostgreSQL-Lambda-access)
+ [
## Étape 3 : Installation de l'`aws_lambda`extension pour une instance de RDS pour PostgreSQL
](#PostgreSQL-Lambda-install-extension)
+ [
## Étape 4 : utiliser les fonctions d’assistance Lambda avec votre instance de base de données RDS pour PostgreSQL (Facultatif)
](#PostgreSQL-Lambda-specify-function)
+ [
## Étape 5 : appeler une fonction Lambda à partir de votre instance de base de données RDS pour PostgreSQL.
](#PostgreSQL-Lambda-invoke)
+ [
## Étape 6 : accorder aux autres utilisateurs l’autorisation d’appeler les fonctions Lambda
](#PostgreSQL-Lambda-grant-users-permissions)
+ [
# Exemples : appel de fonctions Lambda à partir de votre instance de base de données RDS pour PostgreSQL
](PostgreSQL-Lambda-examples.md)
+ [
# Messages d'erreur de fonction Lambda
](PostgreSQL-Lambda-errors.md)
+ [
# Référence des fonctions et des paramètres AWS Lambda
](PostgreSQL-Lambda-functions.md)
## Étape 1 : configurer votre instance de base de données pour les connexions sortantes vers AWS Lambda
Les fonctions Lambda s'exécutent toujours au sein d'un Amazon VPC appartenant au service. AWS Lambda Lambda applique des règles d’accès réseau et de sécurité à ce VPC, le maintient et le surveille automatiquement. Votre instance de base de données RDS pour PostgreSQL envoie du trafic réseau vers le VPC du service Lambda. La façon dont vous configurez cela dépend de si votre instance de base de données est publique ou privée.
+ instance de base de données **publique RDS pour PostgreSQL — L'instance de base** de données données est publique si elle se trouve dans un sous-réseau public de votre VPC et si la propriété « » de l'instance est. PubliclyAccessible `true` Pour trouver la valeur de cette propriété, vous pouvez utiliser la [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) AWS CLI commande. Vous pouvez également utiliser la AWS Management Console afin d’ouvrir l’onglet **Connectivity & security** (Connectivité et sécurité) et vérifier que l’option **Publicly accessible** (Accessible publiquement) est définie sur **Yes** (Oui). Pour vérifier que l’instance se trouve dans le sous-réseau public de votre VPC, vous pouvez utiliser la AWS Management Console ou AWS CLI.
Pour configurer l'accès à Lambda, vous utilisez le AWS Management Console ou AWS CLI pour créer une règle sortante sur le groupe de sécurité de votre VPC. La règle de sortie indique que TCP peut utiliser le port 443 pour envoyer des paquets à n'importe quelle IPv4 adresse (0.0.0.0/0).
+ Cluster de ** RDS privé pour instance de base de données PostgreSQL** — Dans ce cas, la propriété PubliclyAccessible `false` « » de l'instance est ou se trouve dans un sous-réseau privé. Pour permettre à l’instance de fonctionner avec Lambda, vous pouvez utiliser une passerelle traduction d’adresses réseau (NAT). Pour plus d’informations, consultez [Passerelles NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html). Vous pouvez également configurer votre VPC avec un point de terminaison VPC pour Lambda. Pour plus d’informations, consultez [Points de terminaison VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) dans le *Guide de l’utilisateur Amazon VPC*. Le point de terminaison répond aux appels faits par votre instance de base de données RDS pour PostgreSQL à vos fonctions Lambda. Le point de terminaison d’un VPC utilise sa propre résolution DNS privée. RDS pour PostgreSQL ne peut pas utiliser le point de terminaison d’un VPC Lambda tant que vous n’avez pas changé la valeur du paramètre `rds.custom_dns_resolution` de sa valeur par défaut de 0 (non activée) à 1. Pour ce faire :
+ Créez un groupe de paramètres DB personnalisé.
+ Change la valeur du paramètre `rds.custom_dns_resolution` de sa valeur par défaut de `0` à `1`.
+ Modifiez votre instance de base de données pour utiliser votre groupe de paramètres de base de données personnalisé.
+ Redémarrez l’instance pour que le paramètre modifié prenne effet.
Votre VPC peut désormais interagir avec le AWS Lambda VPC au niveau du réseau. Ensuite, vous configurez les autorisations à l’aide d’IAM.
## Étape 2 : configurer IAM pour votre instance de base de données et AWS Lambda
L’appel de fonctions Lambda depuis votre instance de base de données RDS pour PostgreSQL requiert certains privilèges. Pour configurer les privilèges requis, nous vous recommandons de créer une politique IAM qui permet d’appeler des fonctions Lambda, d’attribuer cette politique à un rôle, puis d’appliquer le rôle à votre instance de base de données. Cette approche accorde à l’instance de base de données des privilèges pour appeler la fonction Lambda spécifiée en votre nom. Les étapes suivantes expliquent comment procéder à l’aide de l’ AWS CLI.
**Pour configurer les autorisations IAM pour l’utilisation de votre instance Amazon RDSavec Lambda**
1. Utilisez la AWS CLI commande [create-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-policy.html) pour créer une politique IAM qui permet à votre instance de base de données Aurora d'appeler la fonction Lambda spécifiée. (L’ID d’instruction (Sid) est une description facultative pour votre instruction de politique et n’a aucun effet sur l’utilisation.) Cette politique accorde à votre instance de base de données les autorisations minimales requises pour appeler la fonction Lambda spécifiée.
```
aws iam create-policy --policy-name rds-lambda-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToExampleFunction",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:aws-region:444455556666:function:my-function"
}
]
}'
```
Vous pouvez également utiliser la politique `AWSLambdaRole` prédéfinie qui vous permet d’appeler n’importe laquelle de vos fonctions Lambda. Pour plus d’informations, consultez la rubrique [Politiques IAM basées sur l’identité pour Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html#access-policy-examples-aws-managed).
1. Utilisez la AWS CLI commande [create-role](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-role.html) pour créer un rôle IAM que la politique peut assumer lors de l'exécution.
```
aws iam create-role --role-name rds-lambda-role --assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}'
```
1. Appliquez la politique au rôle à l'aide de la [attach-role-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/attach-role-policy.html) AWS CLI commande.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::444455556666:policy/rds-lambda-policy \
--role-name rds-lambda-role --region aws-region
```
1. AWS CLI Cette dernière étape permet aux utilisateurs de base de données de votre instance de base de données d’appeler des fonctions Lambda.
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-instance-name \
--feature-name Lambda \
--role-arn arn:aws:iam::444455556666:role/rds-lambda-role \
--region aws-region
```
Une fois le VPC et les configurations IAM terminées, vous pouvez désormais installer l’extension `aws_lambda`. (Notez que vous pouvez installer l’extension à tout moment, mais tant que vous n’avez pas configuré la prise en charge du VPC et les privilèges IAM corrects, l’extension `aws_lambda` n’ajoute rien aux fonctionnalités de votre instance de base de données RDS pour PostgreSQL.)
## Étape 3 : Installation de l'`aws_lambda`extension pour une instance de RDS pour PostgreSQL
Cette extension offre à votre instance de base de données RDS pour PostgreSQL la capacité d’appeler des fonctions Lambda depuis PostgreSQL.
**Pour installer l'`aws_lambda`extension dans votre instance de RDS pour PostgreSQL**
Utilisez la ligne de commande `psql` de PostgreSQL ou l’outil pgAdmin afin de vous connecter à votre instance de base de données RDS pour PostgreSQL.
1. Connectez-vous à votre instance de base de données RDS pour PostgreSQL en tant qu’utilisateur doté de privilèges `rds_superuser`. L’utilisateur `postgres` par défaut est illustré dans l’exemple.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Installez l’extension `aws_lambda`. L’extension `aws_commons` est également requise. Elle fournit des fonctions d’assistance pour `aws_lambda` et de nombreuses autres extensions Aurora pour PostgreSQL. Si elle n’est pas déjà sur votre instance de base de données RDS pour PostgreSQL, elle est installée avec `aws_lambda` comme illustré ci-dessous.
```
CREATE EXTENSION IF NOT EXISTS aws_lambda CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
L’extension `aws_lambda` est installée dans l’instance de base de données primaire de votre . Vous pouvez désormais créer des structures de commodité pour appeler vos fonctions Lambda.
## Étape 4 : utiliser les fonctions d’assistance Lambda avec votre instance de base de données RDS pour PostgreSQL (Facultatif)
Vous pouvez utiliser les fonctions d’assistance de l’extension `aws_commons` pour préparer les entités que vous pouvez appeler plus facilement depuis PostgreSQL. Pour ce faire, vous avez besoin des informations suivantes concernant vos fonctions Lambda :
+ **Function name** (Nom de la fonction) — Le nom, l’Amazon Resource Name (ARN), la version ou l’alias de la fonction Lambda. La politique IAM créée dans [Étape 2 : configurer IAM pour votre instance et Lambda](#PostgreSQL-Lambda-access) nécessite l’ARN, nous vous recommandons donc d’utiliser l’ARN de votre fonction.
+ **AWS Région** — (Facultatif) AWS Région dans laquelle se trouve la fonction Lambda si elle ne se trouve pas dans la même région que votre instance de base de données Aurora .
Pour conserver les informations de nom de la fonction Lambda, utilisez la fonction [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn). Cette fonction d’assistance crée une structure composite `aws_commons._lambda_function_arn_1` avec les détails requis par la fonction d’appel. Vous trouverez ci-dessous trois autres approches pour configurer cette structure composite.
```
SELECT aws_commons.create_lambda_function_arn(
'my-function',
'aws-region'
) AS aws_lambda_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'111122223333:function:my-function',
'aws-region'
) AS lambda_partial_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'arn:aws:lambda:aws-region:111122223333:function:my-function'
) AS lambda_arn_1 \gset
```
N’importe laquelle de ces valeurs peut être utilisée dans les appels à la fonction [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke). Pour obtenir des exemples, consultez [Étape 5 : appeler une fonction Lambda à partir de votre instance de base de données RDS pour PostgreSQL.](#PostgreSQL-Lambda-invoke).
## Étape 5 : appeler une fonction Lambda à partir de votre instance de base de données RDS pour PostgreSQL.
La fonction `aws_lambda.invoke` se comporte de manière synchrone ou asynchrone, en fonction du `invocation_type`. Les deux alternatives à ce paramètre sont `RequestResponse` (valeur par défaut) et `Event`, comme suit.
+ **`RequestResponse`** — Ce type d’appel est *synchrone*. Il s’agit du comportement par défaut lorsque l’appel est effectué sans spécifier de type d’appel. La charge utile de réponse inclut les résultats de la fonction `aws_lambda.invoke`. Utilisez ce type d’appel lorsque votre flux de travail nécessite la réception des résultats de la fonction Lambda avant de continuer.
+ **`Event`** — Ce type d’appel est *asynchrone*. La réponse n’inclut pas de charge utile contenant des résultats. Utilisez ce type d’appel lorsque votre flux de travail n’a pas besoin de résultat de la fonction Lambda pour continuer le traitement.
Pour tester simplement votre configuration, vous pouvez vous connecter à votre instance de base de données en utilisant `psql` et appeler un exemple de fonction depuis la ligne de commande. Supposons que l’une des fonctions de base soit configurée sur votre service Lambda, telle que la fonction simple Python affichée dans la capture d’écran suivante.
![\[Exemple de fonction Lambda illustré dans le fichier pour AWS CLI AWS Lambda\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/lambda_simple_function.png)
**Pour invoquer un exemple de fonction**
1. Connectez-vous à votre instance de base de données avec `psql` ou pgAdmin.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Appelez la fonction en utilisant son ARN.
```
SELECT * from aws_lambda.invoke(aws_commons.create_lambda_function_arn('arn:aws:lambda:aws-region:444455556666:function:simple', 'us-west-1'), '{"body": "Hello from Postgres!"}'::json );
```
La réponse se présente comme suit.
```
status_code | payload | executed_version | log_result
-------------+-------------------------------------------------------+------------------+------------
200 | {"statusCode": 200, "body": "\"Hello from Lambda!\""} | $LATEST |
(1 row)
```
Si votre tentative d’appel ne réussit pas, consultez [Messages d'erreur de fonction Lambda](PostgreSQL-Lambda-errors.md).
## Étape 6 : accorder aux autres utilisateurs l’autorisation d’appeler les fonctions Lambda
À ce stade des procédures, vous êtes le seul, en tant que `rds_superuser`, à pouvoir appeler vos fonctions Lambda. Pour permettre à d’autres utilisateurs d’appeler les fonctions que vous avez créées, vous devez leur accorder des autorisations.
**Pour accorder à d’autres personnes l’autorisation d’appeler les fonctions Lambda**
1. Connectez-vous à votre instance de base de données avec `psql` ou pgAdmin.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Exécutez les commandes SQL suivantes :
```
postgres=> GRANT USAGE ON SCHEMA aws_lambda TO db_username;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA aws_lambda TO db_username;
```
# Exemples : appel de fonctions Lambda à partir de votre instance de base de données RDS pour PostgreSQL
Ci-dessous, vous pouvez trouver plusieurs exemples d’appel de la fonction [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke). La plupart des exemples utilisent la structure composite `aws_lambda_arn_1` que vous créez dans [Étape 4 : utiliser les fonctions d’assistance Lambda avec votre instance de base de données RDS pour PostgreSQL (Facultatif)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function) pour simplifier la transmission des détails de la fonction. Pour obtenir un exemple d’appel asynchrone, reportez-vous à la section [Exemple : appel asynchrone (Event) de fonctions Lambda](#PostgreSQL-Lambda-Event). Tous les autres exemples répertoriés utilisent l’appel synchrone.
Pour en savoir plus sur les types d’appel Lambda, consultez [Appel de fonctions Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html) dans le *Guide du développeur AWS Lambda *. Pour plus d’informations sur `aws_lambda_arn_1`, consultez [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn).
**Topics**
+ [
## Exemple : appel synchrone (RequestResponse) de fonctions Lambda
](#PostgreSQL-Lambda-RequestResponse)
+ [
## Exemple : appel asynchrone (Event) de fonctions Lambda
](#PostgreSQL-Lambda-Event)
+ [
## Exemple : capture du journal d’exécution Lambda dans une réponse de fonction
](#PostgreSQL-Lambda-log-response)
+ [
## Exemple : inclusion du contexte client dans une fonction Lambda
](#PostgreSQL-Lambda-client-context)
+ [
## Exemple : appel d’une version spécifique d’une fonction Lambda
](#PostgreSQL-Lambda-function-version)
## Exemple : appel synchrone (RequestResponse) de fonctions Lambda
Voici deux exemples d’appel synchrone de fonction Lambda. Les résultats de ces appels de fonction `aws_lambda.invoke` sont identiques.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
```
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse');
```
Les paramètres sont décrits comme suit :
+ `:'aws_lambda_arn_1'` — Ce paramètre identifie la structure composite créée dans [Étape 4 : utiliser les fonctions d’assistance Lambda avec votre instance de base de données RDS pour PostgreSQL (Facultatif)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function), avec la fonction d’assistance `aws_commons.create_lambda_function_arn`. Vous pouvez également créer cette structure en ligne dans votre appel `aws_lambda.invoke` comme suit.
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function', 'aws-region'),
'{"body": "Hello from Postgres!"}'::json
);
```
+ `'{"body": "Hello from PostgreSQL!"}'::json` : données utiles JSON à passer à la fonction Lambda.
+ `'RequestResponse'` : type d’appel Lambda.
## Exemple : appel asynchrone (Event) de fonctions Lambda
Voici un exemple d’appel de fonction Lambda asynchrone. Le type d’appel `Event` planifie l’appel de fonction Lambda avec la charge utile d’entrée spécifiée et renvoie une réponse immédiatement. Utiliser le type d’appel `Event` dans certains flux de travail qui ne dépendent pas des résultats de la fonction Lambda.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'Event');
```
## Exemple : capture du journal d’exécution Lambda dans une réponse de fonction
Vous pouvez inclure les 4 derniers Ko du journal d’exécution dans la réponse de la fonction à l’aide du paramètre `log_type` dans votre appel de fonction `aws_lambda.invoke`. Par défaut, ce paramètre est défini sur `None`, mais vous pouvez spécifier `Tail` afin de capturer les résultats du journal d’exécution Lambda dans la réponse, comme indiqué ci-dessous.
```
SELECT *, select convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
Définissez le paramètre [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) de la fonction `log_type` sur `Tail` pour inclure le journal d’exécution dans la réponse. La valeur par défaut du paramètre `log_type` est `None`.
Le `log_result` qui est retourné est une chaîne `base64` encodée. Vous pouvez décoder le contenu à l’aide d’une combinaison des fonctions PostgreSQL `decode` et `convert_from`.
Pour plus d’informations sur `log_type`, consultez [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
## Exemple : inclusion du contexte client dans une fonction Lambda
La fonction `aws_lambda.invoke` possède un paramètre `context` que vous pouvez utiliser pour transférer des informations séparées de la charge utile, comme indiqué ci-dessous.
```
SELECT *, convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
Pour inclure le contexte client, utilisez un objet JSON pour le paramètre [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) de la fonction `context`.
Pour plus d’informations sur le paramètre `context`, consultez la référence [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
## Exemple : appel d’une version spécifique d’une fonction Lambda
Vous pouvez spécifier une version particulière d’une fonction Lambda en incluant le paramètre `qualifier` avec l’appel `aws_lambda.invoke`. Vous trouverez ci-dessous un exemple de ce procédé qui utilise `'custom_version'` comme alias pour la version.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'None', NULL, 'custom_version');
```
Vous pouvez également fournir un qualificatif de fonction Lambda avec les informations de nom de la fonction à la place, comme suit.
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function:custom_version', 'us-west-2'),
'{"body": "Hello from Postgres!"}'::json);
```
Pour plus d’informations sur `qualifier` et d’autres paramètres, consultez la référence [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
# Messages d'erreur de fonction Lambda
Dans la liste suivante, vous trouverez des informations sur les messages d'erreur, avec les causes et les solutions possibles.
+ **Problèmes de configuration de VPC**
Les problèmes de configuration du VPC peuvent entraîner les messages d'erreur suivants lors de la tentative de connexion :
```
ERROR: invoke API failed
DETAIL: AWS Lambda client returned 'Unable to connect to endpoint'.
CONTEXT: SQL function "invoke" statement 1
```
Une cause fréquente de cette erreur est un groupe de sécurité VPC mal configuré. Assurez-vous que vous disposez d'une règle sortante pour TCP ouverte sur le port 443 de votre groupe de sécurité VPC afin que votre VPC puisse se connecter au VPC Lambda.
Si votre instance de base de données est privée, vérifiez la configuration DNS privée de votre VPC. Assurez-vous de définir le `rds.custom_dns_resolution` paramètre sur 1 et de le configurer AWS PrivateLink comme indiqué dans[Étape 1 : configurer votre instance de base de données pour les connexions sortantes vers AWS Lambda](PostgreSQL-Lambda.md#PostgreSQL-Lambda-network). Pour plus d'informations, consultez [Interface VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-private-dns) ().AWS PrivateLink
+ **Manque d'autorisations nécessaires pour appeler les fonctions Lambda**
Si l'un des messages d'erreur suivants s'affiche, l'utilisateur (rôle) qui appelle la fonction ne dispose pas des autorisations nécessaires.
```
ERROR: permission denied for schema aws_lambda
```
```
ERROR: permission denied for function invoke
```
Un utilisateur (rôle) doit recevoir des autorisations spécifiques pour appeler les fonctions Lambda. Pour de plus amples informations, veuillez consulter [Étape 6 : accorder aux autres utilisateurs l’autorisation d’appeler les fonctions Lambda](PostgreSQL-Lambda.md#PostgreSQL-Lambda-grant-users-permissions).
+ **Traitement inapproprié des erreurs dans vos fonctions Lambda4**
Si une fonction Lambda lance une exception pendant le traitement de la demande, `aws_lambda.invoke` échoue avec une erreur PostgreSQL telle que la suivante.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
ERROR: lambda invocation failed
DETAIL: "arn:aws:lambda:us-west-2:555555555555:function:my-function" returned error "Unhandled", details: "".
```
Assurez-vous de gérer les erreurs dans vos fonctions Lambda ou dans votre application PostgreSQL.
# Référence des fonctions et des paramètres AWS Lambda
Voici la référence pour les fonctions et les paramètres à utiliser pour invoquer Lambda avec RDS pour PostgreSQL.
**Topics**
+ [
## aws\$1lambda.invoke
](#aws_lambda.invoke)
+ [
## aws\$1commons.create\$1lambda\$1function\$1arn
](#aws_commons.create_lambda_function_arn)
+ [
## Paramètres aws\$1lambda
](#aws_lambda.parameters)
## aws\$1lambda.invoke
Exécute une fonction Lambda pour une instance de base de données RDS pour PostgreSQL.
Pour plus de détails sur l'appel de fonctions Lambda, consultez également la section [Appel](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) dans le *Manuel du développeur AWS Lambda*.
**Syntaxe**
------
#### [ JSON ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSON,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSON,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
------
#### [ JSONB ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSONB,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSONB,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT
)
```
------Paramètres d'entrée
**function\$1name**
Nom d'identification de la fonction Lambda. La valeur peut être le nom de la fonction, un ARN ou un ARN partiel. Pour obtenir la liste des formats possibles, consultez [Formats de nom de fonction Lambda](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestParameters) dans le *Manuel du développeur AWS Lambda*.
*payload*
Entrée de la fonction Lambda. Le format peut être JSON ou JSONB. Pour plus d’informations, consultez la documentation PostgreSQL sur les [types JSON](https://www.postgresql.org/docs/current/datatype-json.html).
*région*
(Facultatif) Région Lambda de la fonction. Par défaut, RDS résout la Région AWS à partir de l’ARN complet dans le `function_name` ou utilise la Région de l’instance de base de données RDS pour PostgreSQL. Si cette valeur de région est en conflit avec celle fournie dans l'ARN `function_name`, une erreur est déclenchée.
*invocation\$1type*
Type d'appel de la fonction Lambda. La valeur est sensible à la casse. Les valeurs possibles sont notamment les suivantes :
+ `RequestResponse` – Valeur par défaut Ce type d'appel d'une fonction Lambda est synchrone et renvoie une charge utile de réponse dans le résultat. Utilisez le type d'appel `RequestResponse` lorsque votre flux de travail dépend de la réception immédiate du résultat de la fonction Lambda.
+ `Event` – Ce type d'appel d'une fonction Lambda est asynchrone et retourne une réponse immédiatement sans retourner de charge utile. Utilisez le type d'appel `Event` lorsque vous n'avez pas besoin des résultats de la fonction Lambda avant que votre flux de travail ne progresse.
+ `DryRun` – Ce type d'appel teste l'accès sans exécuter la fonction Lambda.
*log\$1type*
Type de journal Lambda à renvoyer dans le paramètre de sortie `log_result`. La valeur est sensible à la casse. Les valeurs possibles sont notamment les suivantes :
+ Tail – Le paramètre de sortie `log_result` renvoyé inclura les 4 derniers Ko du journal d'exécution.
+ None – Aucune information de journal Lambda n'est renvoyée.
*context*
Contexte client au format JSON ou JSONB. Les champs à utiliser incluent alors `custom` et `env`.
*qualifier*
Qualificateur qui identifie la version d'une fonction Lambda à appeler. Si cette valeur est en conflit avec celle fournie dans l'ARN `function_name`, une erreur est déclenchée.Paramètres de sortie
*status\$1code*
Code de réponse d'état HTTP. Pour plus d'informations, consultez [Éléments de réponse à l'appel de la fonction Lambda](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseElements) dans le *AWS LambdaManuel du développeur *.
*payload*
Informations renvoyées à partir de la fonction Lambda exécutée. Le format est en JSON ou JSONB.
*executed\$1version*
Version de la fonction Lambda exécutée.
*log\$1result*
Informations du journal d'exécution renvoyées si la valeur `log_type` est `Tail` lorsque la fonction Lambda a été appelée. Le résultat contient les 4 derniers Ko du journal d'exécution codé en Base64.
## aws\$1commons.create\$1lambda\$1function\$1arn
Crée une structure `aws_commons._lambda_function_arn_1` pour contenir les informations de nom de fonction Lambda. Vous pouvez utiliser les résultats de la fonction `aws_commons.create_lambda_function_arn` dans le paramètre `function_name` de la fonction [aws\$1lambda.invoke](#aws_lambda.invoke) aws\$1lambda.invoke.
**Syntaxe**
```
aws_commons.create_lambda_function_arn(
function_name TEXT,
region TEXT DEFAULT NULL
)
RETURNS aws_commons._lambda_function_arn_1
```Paramètres d'entrée
*function\$1name*
Chaîne de texte obligatoire contenant le nom de la fonction Lambda. La valeur peut être un nom de fonction, un ARN partiel ou un ARN complet.
*région*
Chaîne de texte facultative contenant la région AWS dans laquelle se trouve la fonction Lambda. Pour obtenir la liste des noms de régions et les valeurs associées, consultez [Régions, zones de disponibilité et zones locales ](Concepts.RegionsAndAvailabilityZones.md).
## Paramètres aws\$1lambda
Dans le tableau, vous pouvez trouver les paramètres associés à la fonction `aws_lambda`.
| Paramètre | Description |
| --- | --- |
| `aws_lambda.connect_timeout_ms` | Il s’agit d’un paramètre dynamique qui définit le temps d’attente maximal lors de la connexion à AWS Lambda. Les valeurs par défaut sont `1000`. Les valeurs autorisées pour ce paramètre sont comprises entre 1 et 900 000. |
| `aws_lambda.request_timeout_ms` | Il s’agit d’un paramètre dynamique qui définit le temps d’attente maximal lors de la réception d’une réponse d’AWS Lambda. Les valeurs par défaut sont `3000`. Les valeurs autorisées pour ce paramètre sont comprises entre 1 et 900 000. |
| `aws_lambda.endpoint_override` | Indique le point de terminaison qui peut être utilisé pour se connecter à AWS Lambda. Une chaîne vide sélectionne le point de terminaison AWS Lambda par défaut pour la région. La base de données doit être redémarrée pour que ce changement de paramètre statique soit pris en compte. |
# Tâches courantes d’administration de bases de données pour Amazon RDS pour PostgreSQL
Les administrateurs de base de données (DBAs) exécutent diverses tâches lors de l'administration d'une instance de base de données Amazon RDS for PostgreSQL. Si vous êtes administrateur de base de données déjà familier avec PostgreSQL, vous devez connaître certaines des différences importantes entre l’exécution de PostgreSQL sur votre matériel et RDS pour PostgreSQL. Par exemple, comme il s'agit d'un service géré, Amazon RDS n'autorise pas l'accès shell à vos instances de base de données. Cela signifie que vous n'avez pas d'accès direct à `pg_hba.conf` et aux autres fichiers de configuration. Pour RDS pour PostgreSQL, les modifications généralement apportées au fichier de configuration PostgreSQL d’une instance sur site sont apportées à un groupe de paramètres de base de données personnalisé associé à l’instance de base de données RDS pour PostgreSQL. Pour de plus amples informations, veuillez consulter [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Vous ne pouvez pas non plus accéder aux fichiers journaux de la même manière qu'avec une instance PostgreSQL sur site. Pour en savoir plus sur la journalisation, consultez [Fichiers journaux de base de données RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md).
Autre exemple, vous n'avez pas accès au compte `superuser` PostgreSQL. Sur RDS pour PostgreSQL, le rôle `rds_superuser` dispose des privilèges les plus élevés. Il est accordé à `postgres` au moment de la configuration. Que vous soyez familier avec l’utilisation de PostgreSQL sur site ou que vous n’ayez aucune expérience avec RDS pour PostgreSQL, nous vous recommandons de comprendre le rôle `rds_superuser` et de vous renseigner sur l’utilisation des rôles, des utilisateurs, des groupes et des autorisations. Pour de plus amples informations, veuillez consulter [Comprendre les rôles et les autorisations PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Voici quelques tâches DBA courantes pour RDS pour PostgreSQL.
**Topics**
+ [
# Collations prises en charge dans pour PostgreSQL
](PostgreSQL-Collations.md)
+ [
# Comprendre les rôles et les autorisations PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [
# Gestion des connexions inactives dans PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.md)
+ [
# Utilisation de la fonction autovacuum de PostgreSQL sur Amazon RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [
# Gestion d'un nombre élevé d'objets dans Amazon RDS pour PostgreSQL Amazon Aurora
](PostgreSQL.HighObjectCount.md)
+ [
#
](Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.md)
+ [
## Utilisation de mécanismes de journalisation pris en charge par RDS pour PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [
# Gestion des fichiers temporaires avec PostgreSQL
](PostgreSQL.ManagingTempFiles.md)
+ [
## Utilisation de pgBadger pour l'analyse de journal serveur avec PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Badger)
+ [
## Utilisation PGSnapper pour la surveillance de PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Snapper)
+ [
#
](PostgreSQL.CustomCasts.md)
+ [
# Meilleures pratiques pour les requêtes parallèles dans pour PostgreSQL
](PostgreSQL.ParallelQueries.md)
+ [
# Utilisation de paramètres sur votre instance de base de données RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
# Collations prises en charge dans pour PostgreSQL
Les classements sont un ensemble de règles qui déterminent la manière dont les chaînes de caractères stockées dans la base de données sont triées et comparées. Les classements jouent un rôle fondamental dans le système informatique et sont inclus dans le système d’exploitation. Les classements changent au fil du temps lorsque de nouveaux caractères sont ajoutés aux langues ou lorsque les règles de classement changent.
Les bibliothèques de classement définissent des règles et des algorithmes spécifiques pour un classement. Les bibliothèques de classement les plus populaires utilisées dans PostgreSQL sont GNU C (glibc) et les composants d’internationalisation pour Unicode (ICU). Par défaut, RDS pour PostgreSQL utilise le classement glibc qui inclut les ordres de tri des caractères Unicode pour les séquences de caractères multi-octets.
Lorsque vous créez une nouvelle instance de base de données dans RDS pour PostgreSQL, le classement disponible est vérifié dans le système d’exploitation. Les paramètres PostgreSQL de la commande `CREATE DATABASE` `LC_COLLATE` et `LC_CTYPE` sont utilisés pour spécifier un classement, qui constitue le classement par défaut dans cette base de données. Vous pouvez également utiliser le paramètre `LOCALE` dans `CREATE DATABASE` pour définir ces paramètres. Cela détermine le classement par défaut pour les chaînes de caractères dans la base de données et les règles de classification des caractères sous forme de lettres, de chiffres ou de symboles. Vous pouvez également choisir un classement à utiliser sur une colonne, un index ou une requête.
RDS pour PostgreSQL dépend de la bibliothèque glibc du système d’exploitation pour la prise en charge du classement. L’instance RDS pour PostgreSQL est régulièrement mise à jour avec les dernières versions du système d’exploitation. Ces mises à jour incluent parfois une version plus récente de la bibliothèque glibc. Dans de rares cas, les nouvelles versions de glibc modifient l’ordre de tri ou le classement de certains caractères, ce qui peut entraîner un tri différent des données ou la production d’entrées d’index non valides. Si vous découvrez des problèmes d’ordre de tri pour le classement lors d’une mise à jour, vous devrez peut-être reconstruire les index.
Pour réduire les impacts possibles des mises à jour glibc, RDS pour PostgreSQL inclut désormais une bibliothèque de classement par défaut indépendante. Cette bibliothèque de classement est disponible dans RDS pour PostgreSQL 14.6, 13.9, 12.13, 11.18, 10.23 et les versions mineures plus récentes. Elle est compatible avec glibc 2.26-59.amzn2 et assure la stabilité de l’ordre de tri afin d’éviter des résultats de requêtes incorrects.
# Comprendre les rôles et les autorisations PostgreSQL
Lorsque vous créez une instance de base de RDS pour PostgreSQL à l'aide de, un compte administrateur est créé en AWS Management Console même temps. Par défaut, son nom est `postgres`, comme illustré dans la capture d'écran ci-dessous :
![\[L'identité de connexion par défaut pour les informations d'identification sur la page Create database (Créer une base de données) est postgres.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/default-login-identity-apg-rpg.png)
Vous pouvez choisir un autre nom plutôt que d'accepter le nom par défaut (`postgres`). Le nom que vous choisissez doit commencer par une lettre et comporter entre 1 et 16 caractères alphanumériques. Par souci de simplicité, nous nous référons à ce compte utilisateur principal par sa valeur par défaut (`postgres`) tout au long de ce manuel.
Si vous utilisez le `create-db-instance` AWS CLI plutôt que le AWS Management Console, vous créez le nom en le transmettant avec le `master-username` paramètre dans la commande. Pour plus d'informations, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
Que vous utilisiez l'API AWS Management Console AWS CLI, la ou l'API Amazon RDS, que vous utilisiez le `postgres` nom par défaut ou que vous choisissiez un autre nom, ce premier compte utilisateur de base de données est membre du `rds_superuser` groupe et dispose de `rds_superuser` privilèges.
**Topics**
+ [
# Comprendre le rôle rds\$1superuser
](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)
+ [
# Contrôle de l'accès utilisateur à la base de données PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [
# Délégation et contrôle de la gestion des mots de passe utilisateur
](Appendix.PostgreSQL.CommonDBATasks.RestrictPasswordMgmt.md)
+ [
# Utilisation de SCRAM pour le chiffrement de mot de passe PostgreSQL
](PostgreSQL_Password_Encryption_configuration.md)
# Comprendre le rôle rds\$1superuser
Dans PostgreSQL, un *rôle* peut définir un utilisateur, un groupe ou un ensemble d’autorisations spécifiques accordées à un groupe ou à un utilisateur pour divers objets de la base de données. Les commandes PostgreSQL `CREATE USER` et `CREATE GROUP` ont été remplacées par la commande `CREATE ROLE` plus générique avec des propriétés spécifiques permettant de distinguer les utilisateurs de la base de données. Un utilisateur de base de données peut être considéré comme un rôle disposant du privilège LOGIN.
**Note**
Les commandes `CREATE USER` et `CREATE GROUP` peuvent toujours être utilisées. Pour plus d’informations, consultez [Database Roles](https://www.postgresql.org/docs/current/user-manag.html) dans la documentation de PostgreSQL.
L’utilisateur `postgres` est l’utilisateur de base de données disposant des privilèges les plus élevés sur votre instance de base de données RDS pour PostgreSQL. Il présente les caractéristiques définies par l’instruction `CREATE ROLE` suivante.
```
CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'
```
Sauf indication contraire, les propriétés `NOSUPERUSER`, `NOREPLICATION`, `INHERIT` et `VALID UNTIL 'infinity'` sont les options par défaut de CREATE ROLE.
Par défaut, `postgres` fait en sorte que des privilèges soient octroyés au rôle `rds_superuser` ainsi que des autorisations permettant de créer des rôles et des bases de données. Le rôle `rds_superuser` permet à l’utilisateur `postgres` d’effectuer les opérations suivantes :
+ Ajoutez les extensions qu’il est possible d’utiliser avec Amazon RDS. Pour plus d’informations, consultez [Utilisation des fonctions PostgreSQL prises en charge par Amazon RDS pour PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.md)
+ Créer des rôles pour les utilisateurs et leur accorder des privilèges. Pour plus d’informations, consultez [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) et [GRANT](https://www.postgresql.org/docs/14/sql-grant.html) dans la documentation de PostgreSQL.
+ Créer des bases de données. Pour plus d’informations, consultez [CREATE DATABASE](https://www.postgresql.org/docs/14/sql-createdatabase.html) dans la documentation de PostgreSQL.
+ Accorder des privilèges `rds_superuser` aux rôles utilisateur qui ne disposent pas de ces privilèges, et révoquer les privilèges si nécessaire. Nous vous recommandons d’accorder ce rôle uniquement aux utilisateurs effectuant des tâches de super-utilisateur. En d'autres termes, vous pouvez attribuer ce rôle aux administrateurs de base de données (DBAs) ou aux administrateurs système.
+ Accorder (et révoquer) le rôle `rds_replication` aux utilisateurs de base de données qui ne possèdent pas le rôle `rds_superuser`.
+ Accorder (et révoquer) le rôle `rds_password` aux utilisateurs de base de données qui ne possèdent pas le rôle `rds_superuser`.
+ Obtenir des informations d’état sur toutes les connexions à la base de données en utilisant la vue `pg_stat_activity`. En cas de besoin, `rds_superuser` peut arrêter toutes les connexions à l’aide de `pg_terminate_backend` ou `pg_cancel_backend`.
Dans l’instruction `CREATE ROLE postgres...`, vous pouvez voir que le rôle utilisateur `postgres` rejette spécifiquement les autorisations `superuser` PostgreSQL. RDS pour PostgreSQL étant un service géré, vous ne pouvez ni accéder au système d’exploitation hôte, ni vous connecter à l’aide du compte `superuser` PostgreSQL. La plupart des tâches qui exigent un accès `superuser` sur une instance autonome de PostgreSQL sont gérées automatiquement par Amazon RDS.
Pour plus d’informations sur l’octroi de privilèges, consultez [GRANT](http://www.postgresql.org/docs/current/sql-grant.html) dans la documentation de PostgreSQL.
Le rôle `rds_superuser` est l’un des nombreux rôles *prédéfinis* d’un Instance de base de données RDS pour PostgreSQL.
**Note**
Dans PostgreSQL 13 et versions antérieures, les rôles *prédéfinis* s’appellent rôles *par défaut*.
La liste suivante répertorie certains des autres rôles prédéfinis créés automatiquement pour un nouveau Instance de base de données RDS pour PostgreSQL. Les rôles prédéfinis et leurs privilèges ne peuvent pas être modifiés. Vous ne pouvez pas supprimer, renommer ou modifier les privilèges de ces rôles prédéfinis. Toute tentative de ce type génère une erreur.
+ **rds\$1password** : rôle pouvant modifier les mots de passe et configurer des contraintes de mot de passe pour les utilisateurs de base de données. Le rôle `rds_superuser` se voit accorder ce rôle par défaut et peut accorder le rôle aux utilisateurs de base de données. Pour plus d’informations, consultez [Contrôle de l'accès utilisateur à la base de données PostgreSQLContrôle de l'accès utilisateur à PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md).
+ Pour les versions de RDS pour PostgreSQL antérieures à 14, le rôle `rds_password` peut modifier les mots de passe et configurer des contraintes de mot de passe pour les utilisateurs de bases de données et les utilisateurs ayant un rôle `rds_superuser`. À partir de RDS pour PostgreSQL versions 14 et ultérieures, le rôle `rds_password` peut modifier les mots de passe et configurer des contraintes de mot de passe uniquement pour les utilisateurs de bases de données. Seuls les utilisateurs ayant le rôle `rds_superuser` peuvent effectuer ces actions sur d’autres utilisateurs ayant le rôle `rds_superuser`.
+ **rdsadmin** : rôle créé pour gérer la plupart des tâches de gestion que l’administrateur qui utilise les privilèges `superuser` aurait exécutées sur une base de données PostgreSQL autonome. Ce rôle est utilisé en interne par RDS pour PostgreSQL pour de nombreuses tâches de gestion.
+ **rdstopmgr** : rôle utilisé en interne par Amazon RDS pour prendre en charge les déploiements multi-AZ.
+ **rds\$1reserved** : rôle utilisé en interne par Amazon RDS pour réserver des connexions à la base de données.
# Affichage des rôles et de leurs privilèges
Vous pouvez afficher les rôles prédéfinis et leurs privilèges dans votre instance de base de données RDS pour PostgreSQL à l’aide de différentes commandes en fonction de votre version de PostgreSQL. Pour voir tous les rôles prédéfinis, vous pouvez vous connecter à votre instance de base de données RDS pour PostgreSQL et exécuter les commandes suivantes à l’aide de `psql`.
**Pour `psql` 15 et versions antérieures**
Connectez-vous à votre instance de base de données RDS pour PostgreSQL et utilisez la commande `\du` dans psql :
```
postgres=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+------------------------------------------------------
postgres | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
rds_ad | Cannot login | {}
rds_iam | Cannot login | {}
rds_password | Cannot login | {}
rds_replication | Cannot login | {}
rds_superuser | Cannot login | {pg_monitor,pg_signal_backend,rds_password,rds_replication}
rdsadmin | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
| Password valid until infinity |
```
**Pour `psql` 16 et versions ultérieures**
```
postgres=> \drg+
List of role grants
Role name | Member of | Options | Grantor
---------------+-----------------------------+---------------------+----------
postgres | rds_superuser | INHERIT, SET | rdsadmin
rds_superuser | pg_checkpoint | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_monitor | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_signal_backend | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_use_reserved_connections | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_password | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_replication | ADMIN, INHERIT, SET | rdsadmin
```
Pour vérifier l’appartenance à un rôle sans dépendance de version, vous pouvez utiliser la requête SQL suivante :
```
SELECT m.rolname AS "Role name", r.rolname AS "Member of"
FROM pg_catalog.pg_roles m
JOIN pg_catalog.pg_auth_members pam ON (pam.member = m.oid)
LEFT JOIN pg_catalog.pg_roles r ON (pam.roleid = r.oid)
LEFT JOIN pg_catalog.pg_roles g ON (pam.grantor = g.oid)
WHERE m.rolname !~ '^pg_'
ORDER BY 1, 2;
```
Dans la sortie, vous pouvez voir que `rds_superuser` n’est pas un rôle utilisateur de base de données (il ne peut pas se connecter), mais qu’il dispose des privilèges de nombreux autres rôles. Vous pouvez également voir que l’utilisateur de base de données `postgres` est membre du rôle `rds_superuser`. Comme mentionné précédemment, `postgres` est la valeur par défaut sur la page **Create database** (Créer une base de données) de la console Amazon RDS. Si vous avez choisi un autre nom, ce nom apparaît dans la liste des rôles.
# Contrôle de l'accès utilisateur à la base de données PostgreSQL
Les nouvelles bases de données de PostgreSQL sont toujours créées avec un ensemble de privilèges par défaut dans le schéma `public` de la base de données, qui permet à tous les utilisateurs et rôles de base de données de créer des objets. Ces privilèges permettent aux utilisateurs de base de données de se connecter à la base de données, par exemple, et de créer des tables temporaires lorsqu'ils sont connectés.
Pour mieux contrôler l'accès des utilisateurs aux instances de base de données que vous créez sur votre instance de base de données RDS for PostgreSQL, nous vous recommandons de révoquer ces privilèges `public` par défaut. Vous accordez ensuite des privilèges spécifiques aux utilisateurs de base de données de manière plus détaillée, comme indiqué dans la procédure suivante.
**Pour configurer des rôles et des privilèges pour une nouvelle instance de base de données**
Supposons que vous configuriez une base de données sur une instance de base de données RDS for PostgreSQL récemment créée à l'usage de plusieurs chercheurs, qui ont tous besoin d'un accès en lecture/écriture à la base de données.
1. Utilisez `psql` (ou pgAdmin) pour vous connecter à votre instance de base de données RDS for PostgreSQL :
```
psql --host=your-db-instance.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Lorsque vous y êtes invité, saisissez votre mot de passe. Le client `psql` se connecte à la base de données de connexions administratives par défaut, `postgres=>`, et l'affiche sous forme d'invite.
1. Pour empêcher les utilisateurs de base de données de créer des objets dans le schéma `public`, procédez comme suit :
```
postgres=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
```
1. Vous créez ensuite une instance de base de données :
```
postgres=> CREATE DATABASE lab_db;
CREATE DATABASE
```
1. Révoquez tous les privilèges du schéma `PUBLIC` sur cette nouvelle base de données.
```
postgres=> REVOKE ALL ON DATABASE lab_db FROM public;
REVOKE
```
1. Créez un rôle pour les utilisateurs de base de données.
```
postgres=> CREATE ROLE lab_tech;
CREATE ROLE
```
1. Donnez aux utilisateurs de base de données disposant de ce rôle la possibilité de se connecter à la base de données.
```
postgres=> GRANT CONNECT ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Accordez à tous les utilisateurs dotés du rôle `lab_tech` tous les privilèges sur cette base de données.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Créez des utilisateurs de base de données, comme suit :
```
postgres=> CREATE ROLE lab_user1 LOGIN PASSWORD 'change_me';
CREATE ROLE
postgres=> CREATE ROLE lab_user2 LOGIN PASSWORD 'change_me';
CREATE ROLE
```
1. Accordez à ces deux utilisateurs les privilèges associés au rôle lab\$1tech :
```
postgres=> GRANT lab_tech TO lab_user1;
GRANT ROLE
postgres=> GRANT lab_tech TO lab_user2;
GRANT ROLE
```
À ce stade, `lab_user1` et `lab_user2` peuvent se connecter à la base de données `lab_db`. Cet exemple ne respecte pas les bonnes pratiques pour une utilisation en entreprise, qui peuvent inclure la création de plusieurs instances de base de données, différents schémas et l'octroi d'autorisations limitées. Pour des informations plus complètes et des scénarios supplémentaires, consultez [Managing PostgreSQL Users and Roles](https://aws.amazon.com/blogs//database/managing-postgresql-users-and-roles/).
Pour plus d'informations sur les privilèges dans les bases de données PostgreSQL, veuillez consulter la commande [GRANT](https://www.postgresql.org/docs/current/static/sql-grant.html) dans la documentation PostgreSQL.
# Délégation et contrôle de la gestion des mots de passe utilisateur
En tant qu'administrateur de base de données, vous souhaitez peut-être déléguer la gestion des mots de passe utilisateur. Vous souhaitez peut-être également empêcher les utilisateurs de base de données de modifier leurs mots de passe ou de reconfigurer les contraintes de mot de passe, telles que la durée de vie d'un mot de passe. Pour vous assurer que seuls les utilisateurs de base de données que vous choisissez peuvent modifier les paramètres de mot de passe, vous pouvez activer la fonctionnalité de gestion restreinte des mots de passe. Lorsque vous activez cette fonctionnalité, seuls les utilisateurs de base de données qui ont obtenu le rôle `rds_password` peuvent gérer les mots de passe.
**Note**
Pour utiliser la gestion restreinte des mots de passe, votre instance de base de données RDS for PostgreSQL doit exécuter PostgreSQL 10.6 ou versions ultérieures.
Par défaut, cette fonctionnalité est désactivée (`off`), comme illustré ci-dessous :
```
postgres=> SHOW rds.restrict_password_commands;
rds.restrict_password_commands
--------------------------------
off
(1 row)
```
Pour l'activer, vous utilisez un groupe de paramètres personnalisé et redéfinissez le paramètre `rds.restrict_password_commands` sur 1. Assurez-vous de redémarrer votre instance de base de données RDS for PostgreSQL pour que le réglage prenne effet.
Lorsque cette fonctionnalité est activée, les privilèges `rds_password` sont requis pour les commandes SQL suivantes :
```
CREATE ROLE myrole WITH PASSWORD 'mypassword';
CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword';
ALTER ROLE myrole VALID UNTIL '2023-01-01';
ALTER ROLE myrole RENAME TO myrole2;
```
Le changement de nom d'un rôle (`ALTER ROLE myrole RENAME TO newname`) est également restreint si le mot de passe utilise l'algorithme de MD5 hachage.
Lorsque cette fonctionnalité est activée, toute tentative d'exécution de l'une de ces commandes SQL sans les autorisations de rôle `rds_password` génère l'erreur suivante :
```
ERROR: must be a member of rds_password to alter passwords
```
Nous vous recommandons de n'accorder `rds_password` qu'à quelques rôles utilisés exclusivement pour la gestion des mots de passe. Si vous accordez des privilèges `rds_password` aux utilisateurs de base de données qui ne disposent pas de privilèges `rds_superuser`, vous devez également leur accorder l'attribut `CREATEROLE`.
Assurez-vous de vérifier les exigences de mot de passe telles que la date d'expiration et le niveau de complexité requis du côté du client. Si vous utilisez votre propre utilitaire côté client pour les modifications relatives aux mots de passe, l'utilitaire doit être membre de `rds_password` et disposer des privilèges `CREATE ROLE`.
# Utilisation de SCRAM pour le chiffrement de mot de passe PostgreSQL
Le *mécanisme d'authentification Salted Challenge Response (SCRAM)* est une alternative à l'algorithme message digest (MD5) par défaut de PostgreSQL pour chiffrer les mots de passe. Le mécanisme d'authentification SCRAM est considéré comme plus sûr que. MD5 Pour en savoir plus sur ces deux approches différentes de sécurisation des mots de passe, consultez [Password Authentication](https://www.postgresql.org/docs/14/auth-password.html) (Authentification par mot de passe) dans la documentation PostgreSQL.
Nous vous recommandons d'utiliser SCRAM plutôt que MD5 comme schéma de chiffrement de mot de passe pour votre cluster de bases de données . Instance de base de données RDS pour PostgreSQL. Il s’agit d’un mécanisme stimulation/réponse cryptographique qui utilise l’algorithme scram-sha-256 pour l’authentification par mot de passe et le chiffrement de mot de passe.
Vous devrez peut-être mettre à jour les bibliothèques pour vos applications clientes de sorte qu’elles prennent en charge SCRAM. Par exemple, les versions JDBC antérieures à 42.2.0 ne prennent pas en charge SCRAM. Pour plus d’informations, consultez [PostgreSQL JDBC Driver](https://jdbc.postgresql.org/changelogs/2018-01-17-42.2.0-release/) (Pilote JDBC PostgreSQL) dans la documentation du pilote JDBC PostgreSQL. Pour obtenir la liste des autres pilotes PostgreSQL prenant en charge SCRAM, consultez la [liste des pilotes](https://wiki.postgresql.org/wiki/List_of_drivers) dans la documentation PostgreSQL.
RDS pour PostgreSQL versions 13.1 et ultérieures prennent en charge scram-sha-256. Ces versions vous permettent également de configurer votre instance de base de données pour qu’elle requiert SCRAM, comme indiqué dans les procédures suivantes.
## Configuration du cluster de de base de données PostgreSQL nécessite de la SCRAM
Pour , vous pouvez exiger que l’instance de base de données RDS pour PostgreSQL n’accepte que les mots de passe qui utilisent l’algorithme scram-sha-256.
**Important**
Pour les proxys RDS existants avec des bases de données PostgreSQL, si vous modifiez l’authentification de base de données pour utiliser uniquement `SCRAM`, le proxy devient indisponible pendant 60 secondes au maximum. Pour éviter ce problème, effectuez l’une des actions suivantes :
Veillez à ce que la base de données permette à la fois l’authentification `SCRAM` et `MD5`.
Pour utiliser uniquement l’authentification `SCRAM`, créez un nouveau proxy, migrez le trafic de votre application vers ce nouveau proxy, puis supprimez le proxy précédemment associé à la base de données.
Avant d’apporter des modifications à votre système, assurez-vous de bien comprendre le processus complet, comme suit :
+ Obtenez des informations sur tous les rôles et sur le chiffrement des mots de passe pour tous les utilisateurs de base de données.
+ Revérifiez les paramètres de votre instance de base de données RDS pour PostgreSQL qui contrôlent le chiffrement des mots de passe.
+ Si votre instance de base de données RDS pour PostgreSQL utilise un groupe de paramètres par défaut, vous devez créer un groupe de paramètres de base de données personnalisé et l’appliquer à votre instance de base de données RDS pour PostgreSQL de sorte à pouvoir modifier les paramètres si nécessaire. Si votre instance de base de données RDS pour PostgreSQL utilise un groupe de paramètres personnalisé, vous pouvez modifier ultérieurement les paramètres nécessaires dans le processus, selon vos besoins.
+ Remplacez le paramètre `password_encryption` par `scram-sha-256`.
+ Informez tous les utilisateurs de la base de données qu’ils doivent mettre à jour leurs mots de passe. Faites de même pour votre compte `postgres`. Les nouveaux mots de passe sont chiffrés et stockés à l’aide de l’algorithme scram-sha-256.
+ Vérifiez que tous les mots de passe utilisent le même type de chiffrement.
+ Si tous les mots de passe utilisent scram-sha-256, vous pouvez modifier le paramètre `rds.accepted_password_auth_method` de `md5+scram` à `scram-sha-256`.
**Avertissement**
Après avoir changé `rds.accepted_password_auth_method` pour scram-sha-256 uniquement, tous les utilisateurs (rôles) avec des mots de passe chiffrés par `md5` ne peuvent pas se connecter.
### Préparez-vous à avoir besoin de SCRAM pour votre instance de base de données
Avant d’apporter des modifications à votre instance de base de données RDS pour PostgreSQL, vérifiez tous les comptes utilisateurs de base de données existants. Vérifiez également le type de chiffrement utilisé pour les mots de passe. Pour ce faire, utilisez l’extension `rds_tools`. Pour savoir quelles versions de PostgreSQL prennent en charge `rds_tools`, consultez [Versions d’extension pour Amazon RDS pour PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html).
**Pour obtenir la liste des utilisateurs de base de données (rôles) et des méthodes de chiffrement des mots de passe**
1. Utilisez `psql` pour vous connecter à votre instance de base de données RDS pour PostgreSQL, comme suit.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Installez l’extension `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools;
CREATE EXTENSION
```
1. Obtenez la liste des rôles et des méthodes de chiffrement.
```
postgres=> SELECT * FROM
rds_tools.role_password_encryption_type();
```
Vous voyez des résultats similaires à ce qui suit.
```
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | md5
user_465 | md5
postgres | md5
(8 rows)
```
### Création d’un groupe de paramètres de base de données personnalisé
**Note**
Si votre instance de base de données RDS pour PostgreSQL utilise déjà un groupe de paramètres personnalisé, vous n’avez pas besoin d’en créer un.
Pour obtenir un aperçu des groupes de paramètres pour Amazon RDS, consultez [Utilisation de paramètres sur votre instance de base de données RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
Le type de chiffrement utilisé pour les mots de passe est défini dans un paramètre, `password_encryption`. Le chiffrement autorisé par l’instance de base de données RDS pour PostgreSQL est défini dans un autre paramètre, `rds.accepted_password_auth_method`. Le remplacement de l’un de ces paramètres par une valeur autre que celle par défaut requiert de créer un groupe de paramètres de base de données personnalisé et de l’appliquer à votre instance.
Vous pouvez également utiliser l'API AWS Management Console ou l'API RDS pour créer un de base de données personnalisé. Pour plus d'informations, consultez
Vous pouvez maintenant employer le groupe de paramètres personnalisés avec votre instance de base de données.
**Pour créer un groupe de de paramètres de base de données**
1. Utilisez la commande CLI `[create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) ` pour créer le groupe de paramètres de base de données personnalisé. Cet exemple utilise `postgres13` comme source pour ce groupe de paramètres personnalisé.
Pour Linux, macOS ou Unix :
```
aws rds create-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--db-parameter-group-family postgres13 --description 'Custom parameter group for SCRAM'
```
Pour Windows :
```
aws rds create-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--db-parameter-group-family postgres13 --description "Custom DB parameter group for SCRAM"
```
1. Utilisez la commande CLI `[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)` pour appliquer ce groupe de paramètres personnalisé à votre cluster de bases de données RDS pour PostgreSQL.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance --db-instance-identifier 'your-instance-name' \
--db-parameter-group-name "docs-lab-scram-passwords
```
Pour Windows :
```
aws rds modify-db-instance --db-instance-identifier "your-instance-name" ^
--db-parameter-group-name "docs-lab-scram-passwords
```
Pour resynchroniser votre instance de base de données RDS pour PostgreSQL avec votre groupe de paramètres de base de données personnalisé, vous devez redémarrer l’instance principale et toutes les autres instances du cluster. Planifiez cette opération pendant votre fenêtre de maintenance habituelle afin de minimiser l’impact sur vos utilisateurs.
### Configuration du chiffrement des mots de passe pour utiliser SCRAM
Le mécanisme de chiffrement du mot de passe utilisé par une instance de base de données RDS pour PostgreSQL est défini(e) dans le groupe de paramètres de base de données dans le paramètre `password_encryption`. Les valeurs autorisées incluent une valeur non définie, `md5` ou `scram-sha-256`. La valeur par défaut dépend de la version de RDS pour PostgreSQL, comme suit :
+ RDS pour PostgreSQL versions 14 et ultérieures : la valeur par défaut est `scram-sha-256`
+ RDS pour PostgreSQL 13 : la valeur par défaut est `md5`
En attachant un groupe de paramètres de base de données personnalisé à votre instance de base de données RDS pour PostgreSQL, vous pouvez modifier les valeurs du paramètre de chiffrement des mots de passe.
![\[Puis, la console RDS affiche les valeurs par défaut des paramètres password_encryption pour RDS pour PostgreSQL.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rpg-pwd-encryption-md5-scram-1.png)
**Pour remplacer le paramètre de chiffrement des mots de passe par scram-sha-256**
+ Remplacez la valeur du chiffrement des mots de passe par scram-sha-256, comme indiqué ci-après. Cette modification peut être appliquée immédiatement, car le paramètre est dynamique. Aucun redémarrage n’est donc nécessaire pour que la modification soit appliquée.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group --db-parameter-group-name \
'docs-lab-scram-passwords' --parameters 'ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate'
```
Pour Windows :
```
aws rds modify-db-parameter-group --db-parameter-group-name ^
"docs-lab-scram-passwords" --parameters "ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate"
```
### Migration des mots de passe des rôles utilisateur vers SCRAM
Vous pouvez migrer les mots de passe pour les rôles d’utilisateur vers SCRAM comme décrit ci-dessous.
**Pour migrer les mots de passe des utilisateurs (rôles) de base de données MD5 vers SCRAM**
1. Connectez-vous en tant qu’utilisateur administrateur (nom d’utilisateur par défaut, `postgres`) comme suit.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Vérifiez la valeur du paramètre `password_encryption` sur votre instance de base de données RDS pour PostgreSQL à l’aide de la commande suivante.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
md5
(1 row)
```
1. Remplacez la valeur de ce paramètre par scram-sha-256. Pour de plus amples informations, veuillez consulter [Configuration du chiffrement des mots de passe pour utiliser SCRAM](#PostgreSQL_Password_Encryption_configuration.configure-password-encryption).
1. Vérifiez à nouveau la valeur pour vous assurer qu’elle est maintenant réglée sur `scram-sha-256`, comme suit.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
scram-sha-256
(1 row)
```
1. Demandez à tous les utilisateurs de base de données de modifier leurs mots de passe. Veillez également à modifier votre propre mot de passe pour le compte `postgres` (utilisateur de base de données avec privilèges `rds_superuser`).
```
labdb=> ALTER ROLE postgres WITH LOGIN PASSWORD 'change_me';
ALTER ROLE
```
1. Répétez l’opération pour toutes les bases de données de votre Instance de base de données RDS pour PostgreSQL.
### Modification du paramètre de sorte à utiliser SCRAM
Il s’agit de la dernière étape du processus. Une fois que vous avez effectué la modification de la procédure suivante, tous les comptes utilisateurs (rôles) qui utilisent toujours le chiffrement `md5` pour les mots de passe ne pourront pas se connecter au Instance de base de données RDS pour PostgreSQL.
Le paramètre `rds.accepted_password_auth_method` spécifie la méthode de chiffrement acceptée par l’instance de base de données RDS pour PostgreSQL pour un mot de passe utilisateur pendant le processus de connexion. La valeur par défaut est `md5+scram`, ce qui signifie que l’une des méthodes est acceptée. L’image suivante indique la valeur par défaut de ce paramètre.
![\[La console RDS affiche les valeurs par défaut et autorisées pour les paramètres rds.accepted_password_auth_method.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/pwd-encryption-md5-scram-2.png)
Les valeurs autorisées pour ce paramètre sont `md5+scram` ou `scram`. Si la valeur de ce paramètre est remplacée par `scram`, le paramètre devient obligatoire.
**Pour modifier la valeur du paramètre afin d’exiger l’authentification SCRAM pour les mots de passe**
1. Vérifiez que tous les mots de passe utilisateur de toutes les bases de données de votre instance de base de données RDS pour PostgreSQL utilisent `scram-sha-256` pour le chiffrement des mots de passe. Pour ce faire, interrogez `rds_tools` pour obtenir le rôle (utilisateur) et le type de chiffrement, comme suit.
```
postgres=> SELECT * FROM rds_tools.role_password_encryption_type();
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | scram-sha-256
user_465 | scram-sha-256
postgres | scram-sha-256
( rows)
```
1. Répétez la requête sur toutes les instances de base de données de votre Instance de base de données RDS pour PostgreSQL.
Si tous les mots de passe utilisent scram-sha-256, vous pouvez continuer.
1. Remplacez la valeur de l’authentification par mot de passe acceptée par scram-sha-256, comme suit.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--parameters 'ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate'
```
Pour Windows :
```
aws rds modify-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--parameters "ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate"
```
# Gestion des connexions inactives dans PostgreSQL
Les connexions inactives se produisent lorsqu’une session de base de données reste active sur le serveur alors que l’application cliente a été abandonnée ou interrompue de manière anormale. Cette situation se produit généralement lorsque les processus clients se bloquent ou se terminent de manière inattendue sans fermer correctement leurs connexions à la base de données ou sans annuler les demandes en cours.
PostgreSQL identifie et nettoie efficacement les connexions inactives lorsque les processus du serveur sont inactifs ou tentent d’envoyer des données aux clients. Cependant, la détection est difficile pour les sessions inactives, pour les sessions qui attendent une entrée du client ou pour les sessions qui exécutent activement des requêtes. Pour gérer ces scénarios, PostgreSQL fournit les paramètres `tcp_keepalives_*`, `tcp_user_timeout` et `client_connection_check_interval`.
**Topics**
+ [
## Comprendre TCP Keepalive
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Understanding)
+ [
## Principaux paramètres TCP keepalive dans RDS pour PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Parameters)
+ [
## Cas d’utilisation des paramètres TCP Keepalive
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.UseCases)
+ [
## Bonnes pratiques
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.BestPractices)
## Comprendre TCP Keepalive
TCP Keepalive est un mécanisme de niveau protocole qui permet de maintenir et de vérifier l’intégrité de la connexion. Chaque connexion TCP gère les paramètres au niveau du noyau, lesquels régissent le comportement de keepalive. Lorsque le minuteur Keepalive expire, le système procède comme suit :
+ Il envoie un paquet de test sans aucune donnée, en définissant l’indicateur ACK.
+ Attend une réponse du point de terminaison distant conformément aux TCP/IP spécifications.
+ Il gère l’état de la connexion en fonction de la réponse ou de l’absence de réponse.
## Principaux paramètres TCP keepalive dans RDS pour PostgreSQL
| Paramètre | Description | Valeurs par défaut |
| --- |--- |--- |
| tcp\$1keepalives\$1idle | Spécifie le nombre de secondes d'inactivité avant l'envoi du message keepalive. | 300 |
| tcp\$1keepalives\$1interval | Spécifie le nombre de secondes entre les retransmissions de messages keepalive non reconnus. | 30 |
| tcp\$1keepalives\$1count | Nombre maximum de messages KeepAlive perdus avant de déclarer la fin de la connexion | 2 |
| tcp\$1user\$1timeout | Spécifie la durée (en millisecondes) pendant laquelle les données non reconnues peuvent rester avant de fermer de force la connexion. | 0 |
| client\$1connection\$1check\$1interval | Définit l'intervalle (en millisecondes) pour vérifier l'état de la connexion client lors de requêtes de longue durée. Cela garantit une détection plus rapide des connexions fermées. | 0 |
## Cas d’utilisation des paramètres TCP Keepalive
### Maintien en vie des sessions inactives
Pour éviter que des connexions inactives ne soient arrêtées par des pare-feux ou des routeurs pour cause d’inactivité :
+ Configurez `tcp_keepalives_idle` pour envoyer des paquets keepalive à intervalles réguliers.
### Détection des connexions inactives
Pour détecter rapidement les connexions inactives, procédez comme suit :
+ Ajustez `tcp_keepalives_idle`, `tcp_keepalives_interval` et `tcp_keepalives_count`. Par exemple, avec les paramètres par défaut d’Aurora PostgreSQL, il faut environ une minute (2 tests de 30 secondes) pour détecter une connexion inactive. La réduction de ces valeurs peut accélérer la détection.
+ Utilisez `tcp_user_timeout` pour spécifier le temps d’attente maximal pour un accusé de réception.
Les paramètres TCP keepalive aident le noyau à détecter les connexions inactives, mais PostgreSQL peut ne pas agir tant que le socket n’est pas utilisé. Si une session exécute une longue requête, il est possible que les connexions inactives ne soient détectées qu’une fois la requête terminée. Dans PostgreSQL 14 et versions ultérieures, `client_connection_check_interval` peut accélérer la détection des connexions inactives en interrogeant régulièrement le socket lors de l’exécution de la requête.
## Bonnes pratiques
+ **Définissez des intervalles keepalive raisonnables :** réglez `tcp_user_timeout`, `tcp_keepalives_idle`, `tcp_keepalives_count` et `tcp_keepalives_interval` pour équilibrer la vitesse de détection et l’utilisation des ressources.
+ **Optimisez les conditions pour votre environnement :** alignez les paramètres sur le comportement du réseau, les politiques de pare-feu et les besoins des sessions.
+ **Tirez parti des fonctionnalités de PostgreSQL :** utilisez `client_connection_check_interval` dans PostgreSQL versions 14 et ultérieures pour des contrôles de connexion efficaces.
# Utilisation de la fonction autovacuum de PostgreSQL sur Amazon RDS pour PostgreSQL
Nous vous conseillons vivement d’utiliser la fonction autovacuum afin de maintenir l’intégrité de votre instance de base de données PostgreSQL. La fonction autovacuum automatise le lancement des commandes VACUUM et ANALYZE. Elle vérifie les tables ayant eu un grand nombre de tuples insérés, mis à jour ou supprimés. Après cette vérification, elle récupère le stockage en supprimant les données ou les tuples obsolètes de la base de données PostgreSQL.
Par défaut, la fonction autovacuum est activée sur les instances de base de données RDS pour PostgreSQL que vous créez en utilisant l’un des groupes de paramètres de base de données PostgreSQL par défaut. Les autres paramètres de configuration associés à la fonction autovacuum sont également définis par défaut. Comme ces valeurs par défaut sont relativement génériques, vous pouvez bénéficier du réglage de certains paramètres associés à la fonction d’autovacuum pour votre charge de travail spécifique.
Vous trouverez ci-dessous de plus amples informations sur l’autovacuum et sur la façon de régler certains de ses paramètres sur votre instance de base de données RDS pour PostgreSQL. Pour obtenir des informations générales, consultez [Bonnes pratiques pour utiliser les moteurs de stockage PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL).
**Topics**
+ [
## Allocation de mémoire pour la fonction autovacuum
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory)
+ [
## Réduction de la probabilité de bouclage de l’ID de transaction
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)
+ [
# Déterminer si les tables de votre base de données ont besoin d’une opération VACUUM
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.NeedVacuuming.md)
+ [
# Déterminer les tables actuellement éligibles pour autovacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.EligibleTables.md)
+ [
# Déterminer si autovacuum est en cours d'exécution et pour combien de temps
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AutovacuumRunning.md)
+ [
# Réalisation d’un gel manuel du processus vacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)
+ [
# Réindexation d'une table pendant l'exécution du processus autovacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Reindexing.md)
+ [
# Gestion de la fonction autovacuum avec de grands index
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md)
+ [
# Autres paramètres qui affectent la fonction d'autovacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.OtherParms.md)
+ [
# Définition des paramètres d'autovacuum au niveau de la table
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.TableParameters.md)
+ [
# Enregistrement des activités d'autovacuum et de vacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)
+ [
# Comprendre le comportement de l’autovacuum avec les bases de données non valides
](appendix.postgresql.commondbatasks.autovacuumbehavior.md)
+ [
# Identification et résolution des bloqueurs de vacuum agressifs dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.md)
## Allocation de mémoire pour la fonction autovacuum
L’un des paramètres les plus importants qui influencent les performances d’autovacuum est [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM). Dans RDS pour PostgreSQL versions 14 et antérieures, le paramètre `autovacuum_work_mem` est défini sur -1, ce qui indique que le paramètre `maintenance_work_mem` est utilisé à la place. Pour toutes les autres versions, `autovacuum_work_mem` est déterminé par GREATEST (\$1DBInstanceClassMemory/32768\$1, 65536).
Les opérations d'aspiration manuelles utilisent toujours ce `maintenance_work_mem` réglage, le réglage par défaut étant GREATEST (\$1DBInstanceClassMemory/63963136 \$11024\$1, 65536), et il peut également être ajusté au niveau de la session à l'aide de la commande pour des opérations manuelles plus ciblées. `SET` `VACUUM`
`autovacuum_work_mem` détermine la mémoire permettant à l’autovacuum de contenir les identifiants des tuples inactifs (`pg_stat_all_tables.n_dead_tup`) pour les opérations de vacuum d’index.
Lors des calculs visant à déterminer la valeur du paramètre `autovacuum_work_mem`, tenez compte des points suivants :
+ Si vous définissez une valeur trop basse pour ce paramètre, le processus vacuum pourrait avoir à analyser la table plusieurs fois pour mener à bien sa tâche. Ces nombreuses analyses peuvent avoir un impact négatif sur les performances. Pour les instances plus grandes, le réglage de `maintenance_work_mem` ou `autovacuum_work_mem` sur au moins 1 Go peut améliorer les performances des opérations de vacuum des tables contenant un grand nombre de tuples inactifs. Cependant, dans les versions 16 et antérieures de PostgreSQL, l’utilisation de la mémoire de vacuum est limitée à 1 Go, ce qui est suffisant pour traiter environ 179 millions de tuples inactifs en un seul passage. Si une table contient plus de tuples inactifs que cela, l’opération de vacuum doit effectuer plusieurs passages dans les index de la table, ce qui augmente considérablement le temps requis. À partir de la version 17 de PostgreSQL, il n’y a pas de limite de 1 Go et l’autovacuum peut traiter plus de 179 millions de tuples en utilisant des arbres radix.
Un identifiant de tuple a une taille de 6 octets. Pour estimer la mémoire nécessaire afin d’effectuer le vacuum d’un index d’une table, interrogez `pg_stat_all_tables.n_dead_tup` pour chercher le nombre de tuples inactifs, puis multipliez ce nombre par 6 pour déterminer la mémoire requise pour effectuer le vacuum de l’index en un seul passage. Vous pouvez utiliser la requête suivante :
```
SELECT
relname AS table_name,
n_dead_tup,
pg_size_pretty(n_dead_tup * 6) AS estimated_memory
FROM
pg_stat_all_tables
WHERE
relname = 'name_of_the_table';
```
+ Le paramètre `autovacuum_work_mem` fonctionne en conjonction avec le paramètre `autovacuum_max_workers`. Chaque application de travail parmi `autovacuum_max_workers` peut utiliser la mémoire que vous allouez. Si vous avez beaucoup de petites tables, allouez plus de `autovacuum_max_workers` et moins de `autovacuum_work_mem`. Si vous avez de grandes tables (d’une taille supérieure à 100 Go), allouez plus de mémoire et moins de processus de travail. Vous devez avoir alloué suffisamment de mémoire pour pouvoir prendre en charge votre plus grande table. Assurez-vous donc que la combinaison des processus de travail et de la mémoire est égale à la mémoire totale que vous souhaitez allouer.
## Réduction de la probabilité de bouclage de l’ID de transaction
Dans certains cas, les valeurs du groupe de paramètres associées à la fonction autovacuum peuvent ne pas être suffisamment agressives pour empêcher le bouclage de l’ID de transaction. Pour résoudre ce problème, RDS pour PostgreSQL fournit un mécanisme qui adapte automatiquement les valeurs des paramètres d’autovacuum. *Autovacuum adaptatif* est une fonctionnalité pour RDS pour PostgreSQL. Une explication détaillée du [bouclage de l’ID de transaction](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) figure dans la documentation PostgreSQL.
L’autovacuum adaptatif est activé par défaut pour les instances RDS pour PostgreSQL avec le paramètre dynamique `rds.adaptive_autovacuum` défini sur ON. Nous vous recommandons vivement de garder cette option activée. Toutefois, pour désactiver le réglage adaptatif des paramètres d’autovacuum, définissez le paramètre `rds.adaptive_autovacuum` sur 0 ou OFF.
Le bouclage de l’ID de transaction reste possible même lorsque Amazon RDS Amazon RDS ajuste les paramètres d’autovacuum. Nous vous encourageons à implémenter une CloudWatch alarme Amazon pour l'encapsulation des identifiants de transaction. Pour plus d'informations, consultez l'article [Implémenter un système d'alerte précoce pour l'encapsulation des identifiants de transaction dans RDS pour PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) sur le blog de base de données. AWS
Lorsque le réglage adaptatif des paramètres d'aspiration automatique est activé, Amazon RDS commence à ajuster les paramètres d'aspiration automatique lorsque la CloudWatch métrique `MaximumUsedTransactionIDs` atteint la valeur du `autovacuum_freeze_max_age` paramètre ou 500 000 000, la valeur la plus élevée étant retenue.
Amazon RDS continue à ajuster les paramètres pour la fonction autovacuum si une table continue à s’orienter vers le bouclage de l’ID de transaction. Chacun de ces ajustements dédie plus de ressources à la fonction d’autovacuum pour éviter le bouclage. Amazon RDS met à jour les paramètres suivants associés à la fonction d’autovacuum :
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
+ [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM)
+ [autovacuum\$1naptime](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-NAPTIME)
RDS modifie ces paramètres seulement si la nouvelle valeur rend la fonction d’autovacuum plus agressive. Ces paramètres sont modifiés dans la mémoire sur l’instance de base de données. Les valeurs figurant dans le groupe de paramètres ne sont pas modifiées. Pour afficher les paramètres en mémoire actuels, utilisez la commande SQL [SHOW](https://www.postgresql.org/docs/current/sql-show.html) de PostgreSQL.
Chaque fois que Amazon RDS modifie l’un de ces paramètres d’autovacuum, il génère un événement pour l’instance de base de données concernée. Cet événement est visible sur AWS Management Console et via l'API Amazon RDS. Une fois que la `MaximumUsedTransactionIDs` CloudWatch métrique est revenue en dessous du seuil, Amazon RDS réinitialise les paramètres relatifs à l'autovacuum en mémoire aux valeurs spécifiées dans le groupe de paramètres. Il génère ensuite un autre événement correspondant à cette modification.
# Déterminer si les tables de votre base de données ont besoin d’une opération VACUUM
Vous pouvez utiliser la requête suivante pour afficher le nombre de transactions dégelées dans une base de données. La `datfrozenxid` colonne de la `pg_database` ligne d'une base de données est la limite inférieure de la transaction normale qui IDs apparaît dans cette base de données. Cette colonne représente le minimum des valeurs `relfrozenxid` par table au sein de la base de données.
```
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;
```
Par exemple, les résultats de l’exécution de la requête précédente pourraient être les suivants.
```
datname | age
mydb | 1771757888
template0 | 1721757888
template1 | 1721757888
rdsadmin | 1694008527
postgres | 1693881061
(5 rows)
```
Lorsque l'âge d'une base de données atteint 2 milliards de transactions IDs, l'ID de transaction (XID) est contourné et la base de données passe en lecture seule. Vous pouvez utiliser cette requête pour produire une métrique et l’exécuter plusieurs fois par jour. Par défaut, autovacuum est défini pour conserver un âge de transactions inférieur à 200,000,000 ([https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)).
Un exemple de politique de surveillance peut ressembler à ceci :
+ Définissez la valeur `autovacuum_freeze_max_age` sur 200 millions de transactions.
+ Si une table atteint les 500 millions de transactions dégelées, elle déclenche une alarme de faible gravité. Ce n’est pas une valeur déraisonnable, mais elle peut indiquer que la fonction d’autovacuum ne suit pas.
+ Si l’âge d’une table atteint 1 milliard, cela doit être considéré comme une alarme exigeant une action. En général, il est conseillé de conserver des âges plus proches de `autovacuum_freeze_max_age` pour des raisons de performances. Nous vous recommandons d’enquêter en appliquant les recommandations suivantes.
+ Si une table atteint les 1,5 million de transactions non vidées, elle déclenche une alarme de haute gravité. Selon la rapidité avec laquelle votre base de données utilise les transactions IDs, cette alarme peut indiquer que le système n'a plus le temps d'exécuter Autovacuum. Dans ce cas, nous vous recommandons une résolution immédiate.
Si une table enfreint constamment ces seuils, vous devez continuer à modifier vos paramètres d’autovacuum. Par défaut, l’utilisation manuelle de VACUUM (pour lequel les retards basés sur les coûts sont désactivés) est plus agressive que le processus d’autovacuum par défaut, mais elle est également plus intrusive pour le système dans son ensemble.
Nous vous recommandons la procédure suivante :
+ Gardez tout cela à l’esprit et activez un mécanisme de surveillance afin de connaître l’âge de vos transactions les plus anciennes.
Pour plus d'informations sur la création d'un processus qui vous avertit de l'encapsulation des identifiants de transaction, consultez le billet de blog consacré à la AWS base de données [Implémentation d'un système d'alerte précoce pour l'encapsulation des identifiants de transaction dans Amazon RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/).
+ Pour les tables plus occupées, procédez régulièrement au gel manuel du processus de vacuum pendant une fenêtre de maintenance, en plus de compter sur la fonction d’autovacuum. Pour plus d’informations sur le gel manuel du processus vacuum, consultez [Réalisation d’un gel manuel du processus vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
# Déterminer les tables actuellement éligibles pour autovacuum
Souvent, une ou deux tables ont besoin d’une opération VACUUM. Les tables dont la valeur `relfrozenxid` est supérieure au nombre de transactions dans `autovacuum_freeze_max_age` sont toujours ciblées par la fonction d’autovacuum. Sinon, si le nombre de tuples rendus obsolètes depuis la dernière opération VACUUM dépasse le seuil de vacuum, la table est vidée.
Le [seuil d’autovacuum](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM) est défini comme suit :
```
Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples
```
où le `vacuum base threshold` est `autovacuum_vacuum_threshold`, le `vacuum scale factor` est `autovacuum_vacuum_scale_factor` et le `number of tuples` est `pg_class.reltuples`.
Pendant que vous êtes connecté à votre base de données, exécutez la requête suivante pour afficher la liste des tables qu’autovacuum considère comme éligibles pour une action vacuum.
```
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM
pg_settings WHERE name = 'autovacuum_vacuum_threshold'),
vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM
pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'),
fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'),
sto AS (select opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt)
SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
age(relfrozenxid) as xid_age,
coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age,
(coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM
pg_class c join pg_namespace ns on ns.oid = c.relnamespace
join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1)
left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid
left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid
left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid
WHERE c.relkind = 'r' and nspname <> 'pg_catalog'
AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) *
c.reltuples <= n_dead_tup)
ORDER BY age(relfrozenxid) DESC LIMIT 50;
```
# Déterminer si autovacuum est en cours d'exécution et pour combien de temps
Si vous avez besoin de vider manuellement une table, vous devez déterminer si autovacuum est en cours d'exécution. Si c'est le cas, vous devrez peut-être ajuster les paramètres pour le faire fonctionner plus efficacement, ou mettre fin à autovacuum afin de pouvoir exécuter manuellement VACUUM.
Utilisez la requête suivante pour déterminer si autovacuum est en cours d'exécution, pendant combien de temps il a été en cours d'exécution et s'il est en attente sur une autre session.
```
SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query
FROM pg_stat_activity
WHERE upper(query) LIKE '%VACUUM%'
ORDER BY xact_start;
```
Après l'exécution de la requête, vous devez obtenir un résultat similaire à ce qui suit.
```
datname | usename | pid | state | wait_event | xact_runtime | query
--------+----------+-------+--------+------------+-------------------------+--------------------------------------------------------------------------------------------------------
mydb | rdsadmin | 16473 | active | | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound)
mydb | rdsadmin | 22553 | active | | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound)
mydb | rdsadmin | 41909 | active | | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3
mydb | rdsadmin | 618 | active | | 00:00:00 | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+
| | | | | | FROM pg_stat_activity +
| | | | | | WHERE query like '%VACUUM%' +
| | | | | | ORDER BY xact_start; +
```
Plusieurs problèmes peuvent occasionner des longueurs d'exécution (plusieurs jours) d'une session autovacuum. Le problème le plus courant est que la valeur de votre paramètre [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) est trop basse pour la taille de la table ou pour la fréquence des mises à jour.
Nous vous recommandons d'utiliser la formule suivante pour définir la valeur du paramètre `maintenance_work_mem`.
```
GREATEST({DBInstanceClassMemory/63963136*1024},65536)
```
De courtes sessions autovacuum peuvent également indiquer des problèmes :
+ Cela peut indiquer un nombre `autovacuum_max_workers` insuffisant pour votre charge de travail. Dans ce cas, vous devez indiquer le nombre d'exécutants.
+ Cela peut indiquer une corruption d'index (la fonction d'autovacuum se bloque et redémarre sur la même relation, mais ne progresse pas). Dans ce cas, exécutez un `vacuum freeze verbose table` manuel pour voir la cause exacte.
# Réalisation d’un gel manuel du processus vacuum
Vous pouvez effectuer un gel manuel sur une table pour laquelle un processus vacuum est déjà en cours. C’est utile si vous avez identifié une table avec un âge proche de 2 milliards de transactions (ou supérieur à tous les seuils que vous surveillez).
Les étapes suivantes sont fournies à titre informatif et il existe plusieurs variantes de ce processus. Par exemple, pendant le test, supposons que vous trouviez que la valeur du paramètre [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) a été définie trop bas et que vous devez agir immédiatement sur une table. Toutefois, vous ne voulez pas renvoyer l’instance à l’expéditeur pour le moment. À l’aide des requêtes des sections précédentes, vous déterminez quelle table pose problème et remarquez une session autovacuum en cours d’exécution depuis longtemps. Vous savez que vous devez modifier le paramètre `maintenance_work_mem`, mais vous devez également agir immédiatement et effectuer un processus vacuum sur la table concernée. La procédure suivante montre ce que vous devez faire dans cette situation.
**Pour procéder manuellement au gel du processus vacuum**
1. Ouvrez les deux sessions de la base de données contenant la table sur laquelle vous voulez effectuer le processus vacuum. Pour la seconde session, utilisez « écran » ou un autre utilitaire qui gère la session si votre connexion est abandonnée.
1. Dans la première session, obtenez le PID de la session autovacuum en cours d’exécution sur la table.
Exécutez la requête suivante pour obtenir le PID de la session autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY
xact_start;
```
1. Dans la deuxième session, calculez la quantité de mémoire dont vous avez besoin pour cette opération. Dans cet exemple, nous déterminons que nous pouvons nous permettre d’utiliser jusqu’à 2 Go de mémoire pour cette opération. Nous affectons donc 2 Go à [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) pour la session en cours.
```
SET maintenance_work_mem='2 GB';
SET
```
1. Dans la deuxième session, émettez une commande `vacuum freeze verbose` pour la table. Le paramètre de mode détaillé est utile, car il vous permet de voir l’activité bien qu’il n’existe actuellement aucun rapport d’avancement de cette opération dans PostgreSQL.
```
\timing on
Timing is on.
vacuum freeze verbose pgbench_branches;
```
```
INFO: vacuuming "public.pgbench_branches"
INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions
in 43 out of 43 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9347 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
Time: 2.765 ms
```
1. Dans la première session, si l’autovacuum provoquait un blocage de la session de vacuum, `pg_stat_activity` indique que l’attente a la valeur `T` pour votre session de vacuum. Dans ce cas, mettez fin au processus d’autovacuum comme suit.
```
SELECT pg_terminate_backend('the_pid');
```
**Note**
Certaines versions antérieures d’Amazon RDS ne peuvent pas mettre fin à un processus d’autovacuum à l’aide de la commande précédente et échouent avec l’erreur suivante : `ERROR: 42501: must be a superuser to terminate superuser process LOCATION: pg_terminate_backend, signalfuncs.c:227`.
À ce stade, votre session commence. L’autovacuum redémarre immédiatement parce que cette table figure probablement tout en haut de sa liste de tâches.
1. Lancez votre commande `vacuum freeze verbose` dans la session 2, puis terminez le processus autovacuum de la session 1.
# Réindexation d'une table pendant l'exécution du processus autovacuum
Si un index a été corrompu, la fonction d'autovacuum continue à traiter la table et échoue. Si vous essayez d'effectuer un processus vacuum manuel dans cette situation, vous recevez un message d'erreur similaire à ce qui suit.
```
postgres=> vacuum freeze pgbench_branches;
ERROR: index "pgbench_branches_test_index" contains unexpected
zero page at block 30521
HINT: Please REINDEX it.
```
Lorsque l'index est corrompu et que la fonction d'autovacuum tente de s'exécuter sur la table, vous vous heurtez à une session autovacuum déjà en cours d'exécution. Lorsque vous émettez une commande [REINDEX](https://www.postgresql.org/docs/current/static/sql-reindex.html), vous retirez un verrou exclusif sur la table. Les opérations d'écriture sont bloquées, ainsi que les opérations de lecture qui utilisent cet index spécifique.
**Pour réindexer une table lorsque la fonction d'autovacuum est en cours d'exécution sur la table**
1. Ouvrez les deux sessions de la base de données contenant la table sur laquelle vous voulez effectuer le processus vacuum. Pour la seconde session, utilisez « écran » ou un autre utilitaire qui gère la session si votre connexion est abandonnée.
1. Dans la première session, obtenez le PID de la session autovacuum en cours d'exécution sur la table.
Exécutez la requête suivante pour obtenir le PID de la session autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY
xact_start;
```
1. Dans la deuxième session, émettez la commande reindex.
```
\timing on
Timing is on.
reindex index pgbench_branches_test_index;
REINDEX
Time: 9.966 ms
```
1. Dans la première session, si autovacuum provoquait un blocage du processus, vous voyez dans `pg_stat_activity` que l'attente a la valeur « T » pour votre session vacuum. Dans ce cas, vous mettrez fin au processus autovacuum.
```
SELECT pg_terminate_backend('the_pid');
```
À ce stade, votre session commence. Il est important de noter que la fonction d'autovacuum redémarre immédiatement parce que cette table figure probablement tout en haut de sa liste de tâches.
1. Lancez votre commande dans la session 2, puis terminez le processus autovacuum de la session 1.
# Gestion de la fonction autovacuum avec de grands index
Dans le cadre de son fonctionnement, la fonction *autovacuum* effectue plusieurs [phases de mise à vide](https://www.postgresql.org/docs/current/progress-reporting.html#VACUUM-PHASES) lorsqu’elle s’exécute sur une table. Avant que la table ne soit nettoyée, tous ses index sont d’abord vidés. Lorsque vous supprimez plusieurs grands index, cette phase consomme beaucoup de temps et de ressources. Par conséquent, il est recommandé de contrôler le nombre d’index d’une table et d’éliminer les index inutilisés.
Pour ce processus, vérifiez d’abord la taille globale de l’index. Déterminez ensuite s’il existe des index potentiellement inutilisés qui peuvent être supprimés comme le montrent les exemples suivants.
**Pour vérifier la taille de la table et de ses index**
```
postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));
pg_size_pretty
6404 MB
(1 row)
```
```
postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));
pg_size_pretty
11 GB
(1 row)
```
Dans cet exemple, la taille des index est supérieure à celle de la table. Cette différence peut entraîner des problèmes de performances, car les index sont surchargés ou inutilisés, ce qui a une incidence sur la fonction autovacuum ainsi que sur les opérations d’insertion.
**Pour vérifier la présence d’index inutilisés**
À l’aide de la vue [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW), vous pouvez vérifier la fréquence d’utilisation d’un index avec la colonne `idx_scan`. Dans l’exemple suivant, les index non utilisés ont la valeur `idx_scan` définie sur `0`.
```
postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
-------+------------+------------+------------------+-----------------------+----------+--------------+---------------
16433 | 16454 | public | pgbench_accounts | index_f | 6 | 6 | 0
16433 | 16450 | public | pgbench_accounts | index_b | 3 | 199999 | 0
16433 | 16447 | public | pgbench_accounts | pgbench_accounts_pkey | 0 | 0 | 0
16433 | 16452 | public | pgbench_accounts | index_d | 0 | 0 | 0
16433 | 16453 | public | pgbench_accounts | index_e | 0 | 0 | 0
16433 | 16451 | public | pgbench_accounts | index_c | 0 | 0 | 0
16433 | 16449 | public | pgbench_accounts | index_a | 0 | 0 | 0
(7 rows)
```
```
postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
schemaname | relname | indexrelname | idx_scan
------------+------------------+-----------------------+----------
public | pgbench_accounts | index_f | 6
public | pgbench_accounts | index_b | 3
public | pgbench_accounts | pgbench_accounts_pkey | 0
public | pgbench_accounts | index_d | 0
public | pgbench_accounts | index_e | 0
public | pgbench_accounts | index_c | 0
public | pgbench_accounts | index_a | 0
(7 rows)
```
**Note**
Ces statistiques sont incrémentielles à partir du moment où elles sont réinitialisées. Supposons que vous disposiez d’un index qui n’est utilisé qu’à la fin d’un trimestre ou uniquement pour un rapport spécifique. Il est possible que cet index n’ait pas été utilisé depuis la réinitialisation des statistiques. Pour plus d’informations, consultez [Statistics Functions](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-STATS-FUNCTIONS) (Fonctions statistiques). Les index utilisés pour renforcer l’unicité ne seront pas analysés et ne devraient pas être identifiés comme des index inutilisés. Pour identifier les index inutilisés, vous devez avoir une connaissance approfondie de l’application et de ses requêtes.
Pour vérifier quand les statistiques ont été réinitialisées pour la dernière fois pour une base de données, utilisez [ https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW]( https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW)
```
postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';
datname | stats_reset
----------+-------------------------------
postgres | 2022-11-17 08:58:11.427224+00
(1 row)
```
## Vidage d’une table le plus rapidement possible
**RDS pour PostgreSQL versions 12 et ultérieures**
Si vous avez trop d’index dans une grande table, il se peut que votre instance de base de données soit proche du bouclage de l’ID de transaction (XID), c’est-à-dire lorsque le compteur XID revient à zéro. Si elle n’est pas vérifiée, cette situation peut entraîner une perte de données. Toutefois, vous pouvez rapidement vider la table sans nettoyer les index. Dans RDS pour PostgreSQL versions 12 et ultérieures, vous pouvez utiliser VACUUM avec la clause [https://www.postgresql.org/docs/current/sql-vacuum.html](https://www.postgresql.org/docs/current/sql-vacuum.html).
```
postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;
INFO: vacuuming "public.pgbench_accounts"
INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
```
Si une session de mise à vide automatique est déjà en cours, vous devez y mettre fin pour démarrer le processus VACUUM manuel. Pour plus d’informations sur le gel manuel du processus vacuum, consultez [Réalisation d’un gel manuel du processus vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
**Note**
Ignorer régulièrement le nettoyage de l’index entraîne un gonflement de l’index, ce qui dégrade les performances des analyses. L’index conserve les lignes inactives et le tableau conserve les pointeurs de ligne inactive. Par conséquent, `pg_stat_all_tables.n_dead_tup` augmente jusqu’à l’exécution d’un autovacuum ou d’un VACUUM manuel avec nettoyage d’index. Une bonne pratique consiste à n’utiliser la procédure précédente que pour empêcher le bouclage de l’ID de transaction.
**RDS pour PostgreSQL versions 11 et ultérieures**
Toutefois, dans RDS pour PostgreSQL versions 11 et ultérieures, la seule façon de permettre au processus vacuum de se terminer plus rapidement est de réduire le nombre d’index sur une table. La suppression d’un index peut affecter les plans de requête. Nous vous recommandons de supprimer d’abord les index inutilisés, puis de les supprimer lorsque le bouclage de l’ID de transaction est très proche. Une fois le processus vacuum terminé, vous pouvez recréer ces index.
# Autres paramètres qui affectent la fonction d'autovacuum
Cette requête affiche les valeurs de certains des paramètres qui ont un impact direct sur la fonction d'autovacuum et son comportement. Les [paramètres d'autovacuum](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html) sont décrits en détails dans la documentation PostgreSQL.
```
SELECT name, setting, unit, short_desc
FROM pg_settings
WHERE name IN (
'autovacuum_max_workers',
'autovacuum_analyze_scale_factor',
'autovacuum_naptime',
'autovacuum_analyze_threshold',
'autovacuum_analyze_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_cost_delay',
'autovacuum_vacuum_cost_limit',
'vacuum_cost_limit',
'autovacuum_freeze_max_age',
'maintenance_work_mem',
'vacuum_freeze_min_age');
```
Tous ces paramètres affectent la fonction d'autovacuum, mais les plus importants sont :
+ [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE_WORK_MEM)
+ [autovacuum\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)
+ [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS)
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
# Définition des paramètres d'autovacuum au niveau de la table
Les [paramètres de stockage](https://www.postgresql.org/docs/current/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS) liés à la fonction d'autovacuum peuvent être définis au niveau de la table, ce qui peut être plus judicieux que de modifier le comportement de toute la base de données. Pour les grandes tables, vous devrez peut-être définir des paramètres agressifs et il est déconseillé de faire en sorte que la fonction d'autovacuum se comporte de cette manière pour toutes les tables.
La requête suivante affiche les tables qui ont actuellement des options en place au niveau de la table.
```
SELECT relname, reloptions
FROM pg_class
WHERE reloptions IS NOT null;
```
Par exemple, cela peut être utile sur les tables qui sont beaucoup plus grandes que le reste de vos tables. Supposez que vous avez une table de 300 Go et 30 autres tables de moins de 1 Go. Dans ce cas, vous pouvez définir des paramètres spécifiques pour votre grande table afin de ne pas modifier le comportement de l'intégralité de votre système.
```
ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);
```
Cela permet de désactiver le retard d'autovacuum basé sur les coûts pour cette table au détriment d'une plus grande utilisation des ressources sur votre système. Normalement, l'autovacuum s'arrête pour `autovacuum_vacuum_cost_delay` à chaque fois que `autovacuum_cost_limit` est atteinte. Pour plus d'informations, veuillez consulter la documentation PostgreSQL concernant le [processus de vacuum basé sur les coûts](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST).
# Enregistrement des activités d'autovacuum et de vacuum
Les informations sur les activités d'autovacuum sont envoyées au `postgresql.log` en fonction du niveau spécifié dans le paramètre `rds.force_autovacuum_logging_level`. Voici les valeurs autorisées pour ce paramètre et les versions de PostgreSQL pour lesquelles cette valeur est le paramètre par défaut :
+ `disabled` (PostgreSQL 10, PostgreSQL 9.6)
+ `debug5`, `debug4`, `debug3`, `debug2`, `debug1`
+ `info` (PostgreSQL 12, PostgreSQL 11)
+ `notice`
+ `warning` (PostgreSQL versions 13 et ultérieures)
+ `error`, journal, `fatal`, `panic`
`rds.force_autovacuum_logging_level` fonctionne avec le paramètre `log_autovacuum_min_duration`. La valeur du paramètre `log_autovacuum_min_duration` est le seuil (en millisecondes) au-dessus duquel les actions autovacuum sont enregistrées. Une valeur de `-1` n'enregistre rien, tandis qu'une valeur de 0 enregistre toutes les actions. Comme avec `rds.force_autovacuum_logging_level`, valeurs par défaut pour `log_autovacuum_min_duration` dépendent de la version, comme suit :
+ `10000 ms` : PostgreSQL 14, PostgreSQL 13, PostgreSQL 12 et PostgreSQL 11
+ `(empty)` : aucune valeur par défaut pour PostgreSQL 10 et PostgreSQL 9.6
Nous vous recommandons de définir le `rds.force_autovacuum_logging_level` à la valeur `WARNING`. Nous vous recommandons également de définir `log_autovacuum_min_duration` à une valeur comprise entre 1000 et 5000. Un paramètre de 5000 journaux d'activité qui prend plus de 5000 millisecondes. Tout paramètre autre que -1 enregistre également les messages si l'action autovacuum est ignorée en raison d'un verrouillage en conflit ou d'une perte simultanée de relations. Pour plus d'informations, veuillez consulter [Action Vacuum automatique](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) dans la documentation PostgreSQL.
Pour résoudre les problèmes, vous pouvez modifier le paramètre `rds.force_autovacuum_logging_level` à l'un des niveaux de débogage, de `debug1` jusqu'à `debug5` pour obtenir les informations les plus détaillées. Nous vous recommandons d'utiliser les paramètres de débogage pendant de courtes périodes et à des fins de dépannage uniquement. Pour en savoir plus, veuillez consulter la rubrique [Quand journaliser](https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN) dans la documentation de PostgreSQL.
**Note**
PostgreSQL permet au compte `rds_superuser` d'afficher les sessions autovacuum dans `pg_stat_activity`. Par exemple, vous pouvez identifier et mettre fin à la session qui bloque l'exécution d'une commande ou empêche la commande de s'exécuter plus lentement qu'une commande vacuum exécutée manuellement.
# Comprendre le comportement de l’autovacuum avec les bases de données non valides
Une nouvelle valeur `-2` est introduite dans la colonne `datconnlimit` du catalogue `pg_database` pour indiquer que les bases de données qui ont été interrompues au milieu de l’opération DROP DATABASE ne sont pas valides.
Cette nouvelle valeur est disponible dans les versions suivantes de RDS pour PostgreSQL :
+ Version 15.4 et toutes les versions ultérieures
+ 14.9 et versions ultérieures
+ 13.12 et versions ultérieures
+ 12.16 et versions ultérieures
+ 11.21 et versions ultérieures
Les bases de données non valides n’affectent pas la capacité de la fonction d’autovacuum à geler la fonctionnalité des bases de données valides. Autovacuum ignore les bases de données non valides. Par conséquent, les opérations de vacuum régulières continueront à fonctionner correctement et efficacement pour toutes les bases de données valides de votre environnement PostgreSQL.
**Topics**
+ [
## Surveillance de l’ID de transaction
](#appendix.postgresql.commondbatasks.autovacuum.monitorxid)
+ [
## Ajustement de la requête de surveillance
](#appendix.postgresql.commondbatasks.autovacuum.monitoradjust)
+ [
## Résolution du problème de base de données non valide
](#appendix.postgresql.commondbatasks.autovacuum.connissue)
## Surveillance de l’ID de transaction
Cette fonction `age(datfrozenxid)` est couramment utilisée pour surveiller l’âge des ID de transaction (XID) des bases de données afin d’empêcher le bouclage de l’ID de transaction.
Les bases de données non valides étant exclues de l’autovacuum, leur compteur d’ID de transaction (XID) peut atteindre la valeur maximale de `2 billion`, revenir à `- 2 billion` et poursuivre ce cycle indéfiniment. Une requête typique pour surveiller le bouclage de l’ID de transaction peut ressembler à ceci :
```
SELECT max(age(datfrozenxid)) FROM pg_database;
```
Cependant, avec l’introduction de la valeur -2 pour `datconnlimit`, les bases de données non valides peuvent fausser les résultats de cette requête. Étant donné que ces bases de données ne sont pas valides et ne doivent pas faire l’objet de contrôles de maintenance réguliers, elles peuvent générer des faux positifs, ce qui vous laisse penser que `age(datfrozenxid)` est supérieur à ce qu’il est réellement.
## Ajustement de la requête de surveillance
Pour garantir une surveillance précise, vous devez ajuster votre requête de surveillance afin d’exclure les bases de données non valides. Suivez cette requête recommandée :
```
SELECT
max(age(datfrozenxid))
FROM
pg_database
WHERE
datconnlimit <> -2;
```
Cette requête garantit que seules les bases de données valides sont prises en compte dans le calcul `age(datfrozenxid)`, ce qui reflète fidèlement l’âge des ID de transaction dans l’environnement PostgreSQL.
## Résolution du problème de base de données non valide
Lorsque vous essayez de vous connecter à une base de données non valide, vous pouvez rencontrer un message d’erreur similaire à ce qui suit :
```
postgres=> \c db1
connection to server at "mydb.xxxxxxxxxx.us-west-2.rds.amazonaws.com" (xx.xx.xx.xxx), port xxxx failed: FATAL: cannot connect to invalid database "db1"
HINT: Use DROP DATABASE to drop invalid databases.
Previous connection kept
```
En outre, si le paramètre `log_min_messages` est défini sur `DEBUG2` ou supérieur, vous remarquerez peut-être que les entrées de journal suivantes indiquent que le processus autovacuum ignore la base de données non valide :
```
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db6"
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db1"
```
Pour résoudre le problème, suivez le `HINT` fourni lors de la tentative de connexion. Connectez-vous à n’importe quelle base de données valide à l’aide de votre compte principal RDS ou d’un compte de base de données doté du rôle `rds_superuser`, puis supprimez les bases de données non valides.
```
SELECT
'DROP DATABASE ' || quote_ident(datname) || ';'
FROM
pg_database
WHERE
datconnlimit = -2 \gexec
```
# Identification et résolution des bloqueurs de vacuum agressifs dans RDS pour PostgreSQL
Dans PostgreSQL, l’opération de vacuum est essentielle pour garantir l’intégrité de la base de données, car elle permet de récupérer de l’espace de stockage et d’éviter les problèmes de [bouclage de l’ID de transaction.](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) Cependant, il peut arriver que l’opération de vacuum ne fonctionne pas comme vous le souhaitez, ce qui peut entraîner une dégradation des performances ou une surcharge de l’espace de stockage et même avoir un impact sur la disponibilité de votre instance de base de données par bouclage de l’ID de transaction. Il est donc essentiel d’identifier et de résoudre ces problèmes pour optimiser les performances et la disponibilité des bases de données. Lisez [Présentation d’autovacuum dans les environnements Amazon RDS pour PostgreSQL](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/) pour en savoir plus sur l’autovacuum.
La fonction `postgres_get_av_diag()` permet d’identifier les problèmes qui empêchent ou retardent la progression du vacuum agressif. Des suggestions sont fournies, qui peuvent inclure des commandes pour résoudre le problème lorsqu’il est identifiable ou des conseils pour des diagnostics supplémentaires lorsque le problème n’est pas identifiable. Les bloqueurs d'aspiration agressifs sont signalés lorsque leur âge dépasse le seuil d'[autoaspiration adaptatif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) de 500 millions de transactions fixé par RDS. IDs
**Quel est l’âge de l’ID de transaction ?**
La `age()` fonction de transaction IDs calcule le nombre de transactions survenues depuis le plus ancien identifiant de transaction dégelé pour une base de données (`pg_database.datfrozenxid`) ou une table (`pg_class.relfrozenxid`). Cette valeur indique l’activité de la base de données depuis la dernière opération de vacuum agressif et met en évidence la charge de travail probable pour les prochains processus VACUUM.
**Qu’est-ce qu’un vacuum agressif ?**
Une opération VACUUM agressive effectue une numérisation complète de toutes les pages d'un tableau, y compris celles qui sont généralement ignorées en mode normal VACUUMs. Cette analyse approfondie vise à « geler » les transactions IDs qui approchent de leur âge maximum, évitant ainsi une situation connue sous le nom d'[encapsulation des identifiants de transaction](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND).
Pour que `postgres_get_av_diag()` signale un bloqueur, celui-ci doit dater d’au moins 500 millions de transactions.
**Topics**
+ [
# Installation d’outils de surveillance et de diagnostic d’autovacuum dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md)
+ [
# Fonctions de postgres\$1get\$1av\$1diag() dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md)
+ [
# Résolution des bloqueurs de vacuum identifiables dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md)
+ [
# Résolution des bloqueurs de vacuum non identifiables dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md)
+ [
# Résolution des problèmes de performance de vacuum dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md)
+ [
# Explication des messages NOTICE dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
# Installation d’outils de surveillance et de diagnostic d’autovacuum dans RDS pour PostgreSQL
La fonction `postgres_get_av_diag()` est actuellement disponible dans les versions RDS pour PostgreSQL suivantes :
+ 17.2 et versions 17 ultérieures
+ 16.7 et versions 16 ultérieures
+ 15.11 et versions 15 ultérieures
+ 14.16 et versions 14 ultérieures
+ 13.19 et versions 13 ultérieures
Pour pouvoir utiliser `postgres_get_av_diag()`, créez l’extension `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools ;
CREATE EXTENSION
```
Vérifiez que l’extension est installée.
```
postgres=> \dx rds_tools
List of installed extensions
Name | Version | Schema | Description
----------+---------+-----------+----------------------------------------------------------
rds_tools | 1.8 | rds_tools | miscellaneous administrative functions for RDS PostgreSQL
1 row
```
Vérifiez que la fonction est créée.
```
postgres=> SELECT
proname function_name,
pronamespace::regnamespace function_schema,
proowner::regrole function_owner
FROM
pg_proc
WHERE
proname = 'postgres_get_av_diag';
function_name | function_schema | function_owner
----------------------+-----------------+----------------
postgres_get_av_diag | rds_tools | rds_superuser
(1 row)
```
# Fonctions de postgres\$1get\$1av\$1diag() dans RDS pour PostgreSQL
La fonction `postgres_get_av_diag()` récupère des informations de diagnostic sur les processus autovacuum qui bloquent ou sont en retard dans une base de données RDS pour PostgreSQL. Pour obtenir des résultats précis, la requête doit être exécutée dans la base de données dont l’ID de transaction est le plus ancien. Pour plus d’informations sur l’utilisation de la base de données ayant l’ID de transaction le plus ancien, consultez [Non connecté à la base de données dont l’ID de transaction est le plus ancien](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md).
```
SELECT
blocker,
DATABASE,
blocker_identifier,
wait_event,
TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
suggestion,
suggested_action
FROM (
SELECT
*
FROM
rds_tools.postgres_get_av_diag ()
ORDER BY
autovacuum_lagging_by DESC) q;
```
La fonction `postgres_get_av_diag()` retourne un tableau avec les informations suivantes :
**blocker**
Spécifie la catégorie d’activité de base de données qui bloque le vacuum.
+ [Instruction active](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [État Idle in transaction (Transaction inactive)](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Transaction préparée](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Emplacement de réplication logique](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Réplica en lecture avec emplacement de réplication physique](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Réplica en lecture avec réplication de streaming](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Tables temporaires](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
**database**
Spécifie le nom de la base de données, le cas échéant. Il s’agit de la base de données dans laquelle l’activité est en cours et bloque ou bloquera l’autovacuum. Il s’agit de la base de données à laquelle vous devez vous connecter et sur laquelle vous devez agir.
**blocker\$1identifier**
Spécifie l’identifiant de l’activité qui bloque ou bloquera l’autovacuum. Il peut s’agir d’un ID de processus accompagné d’une instruction SQL, d’une transaction préparée, de l’adresse IP d’un réplica en lecture et du nom de l’emplacement de réplication, logique ou physique.
**wait\$1event**
Spécifie l’[événement d’attente](PostgreSQL.Tuning.md) de la session de blocage et s’applique aux bloqueurs suivants :
+ Instruction active
+ État Idle in transaction (Transaction inactive)
**autovacum\$1lagging\$1by**
Spécifie le nombre de transactions pour lesquelles l’autovacuum a pris du retard dans le traitement des éléments en attente par catégorie.
**suggestion**
Spécifie des suggestions pour résoudre le bloqueur. Ces instructions incluent le nom de la base de données dans laquelle l’activité existe, le cas échéant, l’ID de processus (PID) de la session, le cas échéant, et les actions à effectuer.
**suggested\$1action**
Suggère l’action à effectuer pour résoudre le bloqueur.
# Résolution des bloqueurs de vacuum identifiables dans RDS pour PostgreSQL
L’autovacuum effectue des opérations vacuum agressives et abaisse l’âge des ID de transaction en dessous du seuil spécifié par le paramètre `autovacuum_freeze_max_age` de votre instance RDS. Vous pouvez suivre cet âge à l’aide de la métrique `MaximumUsedTransactionIDs` d’Amazon CloudWatch.
Pour trouver le paramètre `autovacuum_freeze_max_age` (dont la valeur par défaut est de 200 millions d’ID de transaction) pour votre instance Amazon RDS, vous pouvez utiliser la requête suivante :
```
SELECT
TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
pg_settings
WHERE
name = 'autovacuum_freeze_max_age';
```
Notez que `postgres_get_av_diag()` recherche uniquement les bloqueurs de vacuum agressifs quand l’âge dépasse le seuil de 500 millions d’ID de transaction pour l’[autovacuum adaptatif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) d’Amazon RDS. Pour que `postgres_get_av_diag()` détecte un bloqueur, celui-ci doit dater d’au moins 500 millions de transactions.
La fonction `postgres_get_av_diag()` identifie les types de bloqueurs suivants :
**Topics**
+ [
## Instruction active
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [
## État Idle in transaction (Transaction inactive)
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [
## Transaction préparée
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [
## Emplacement de réplication logique
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [
## Réplicas en lecture
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [
## Tables temporaires
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
## Instruction active
Dans PostgreSQL, une instruction active est une instruction SQL qui est exécutée par la base de données. Cela inclut les requêtes, les transactions ou les opérations en cours. Lors de la surveillance via `pg_stat_activity`, la colonne d’état indique que le processus avec le PID correspondant est actif.
La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle identifie une instruction active.
```
blocker | Active statement
database | my_database
blocker_identifier | SELECT pg_sleep(20000);
wait_event | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (29621);"}
```
**Action suggérée**
En suivant les instructions de la colonne `suggestion`, l’utilisateur peut se connecter à la base de données dans laquelle l’instruction active se trouve et, comme indiqué dans la colonne `suggested_action`, il est conseillé de vérifier attentivement l’option permettant de mettre fin à la session. Si la résiliation est sûre, vous pouvez utiliser la fonction `pg_terminate_backend()` pour résilier la session. Cette action peut être effectuée par un administrateur (tel que le compte principal RDS) ou par un utilisateur disposant du privilège `pg_terminate_backend()` requis.
**Avertissement**
Une session résiliée annule (`ROLLBACK`) les modifications apportées. En fonction de vos besoins, vous souhaiterez peut-être réexécuter l’instruction. Cependant, il est recommandé de ne le faire qu’une fois que le processus d’autovacuum a terminé son opération de vacuum agressif.
## État Idle in transaction (Transaction inactive)
Une instruction idle in transaction fait référence à toute session qui a ouvert une transaction explicite (par exemple en émettant une instruction `BEGIN`), qui a effectué un certain travail et qui attend maintenant que le client transmettre plus de travail ou signale la fin de la transaction en émettant une instruction `COMMIT`, `ROLLBACK`, ou `END` (ce qui se traduirait par un `COMMIT` implicite).
La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle identifie une instruction `idle in transaction` comme un bloqueur.
```
blocker | idle in transaction
database | my_database
blocker_identifier | INSERT INTO tt SELECT * FROM tt;
wait_event | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (28438);"}
```
**Action suggérée**
Comme indiqué dans la colonne `suggestion`, vous pouvez vous connecter à la base de données dans laquelle la session idle in transaction est présente et mettre fin à la session à l’aide de la fonction `pg_terminate_backend()`. L’utilisateur peut être votre administrateur (compte principal RDS) ou un utilisateur disposant du privilège `pg_terminate_backend()`.
**Avertissement**
Une session résiliée annule (`ROLLBACK`) les modifications apportées. En fonction de vos besoins, vous souhaiterez peut-être réexécuter l’instruction. Cependant, il est recommandé de ne le faire qu’une fois que le processus d’autovacuum a terminé son opération de vacuum agressif.
## Transaction préparée
PostgreSQL autorise les transactions qui font partie d’une stratégie de validation en deux phases appelée [transactions préparées](https://www.postgresql.org/docs/current/sql-prepare-transaction.html). Elles sont activées en définissant une valeur différente de zéro pour le paramètre `max_prepared_transactions`. Les transactions préparées sont conçues pour garantir qu’une transaction est durable et reste disponible même après une panne de base de données, un redémarrage ou une déconnexion du client. Comme les transactions régulières, elles reçoivent un ID de transaction et peuvent affecter l’autovacuum. Si elles restent à l’état préparé, l’autovacuum ne peut pas les geler et cela peut entraîner un bouclage de l’ID de transaction.
Lorsque les transactions restent à l’état préparé indéfiniment sans être résolues par un gestionnaire de transactions, elles deviennent des transactions préparées orphelines. La seule façon de résoudre ce problème est de valider ou d’annuler la transaction à l’aide des commandes `COMMIT PREPARED` ou `ROLLBACK PREPARED`, respectivement.
**Note**
Sachez qu’une sauvegarde effectuée lors d’une transaction préparée contiendra toujours cette transaction après restauration. Reportez-vous aux informations suivantes pour savoir comment localiser et clôturer de telles transactions.
La fonction `postgres_get_av_diag()` affiche le résultat suivant lorsqu’elle identifie un bloqueur qui est une transaction préparée.
```
blocker | Prepared transaction
database | my_database
blocker_identifier | myptx
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}
```
**Action suggérée**
Comme indiqué dans la colonne de suggestions, connectez-vous à la base de données où se trouve la transaction préparée. Sur la base de la colonne `suggested_action`, examinez attentivement s’il faut exécuter `COMMIT` ou `ROLLBACK`, et quelle est l’action appropriée.
Pour surveiller les transactions préparées en général, PostgreSQL propose une vue de catalogue appelée `pg_prepared_xacts`. Vous pouvez utiliser la requête suivante pour rechercher les transactions préparées.
```
SELECT
gid,
prepared,
owner,
database,
transaction AS oldest_xmin
FROM
pg_prepared_xacts
ORDER BY
age(transaction) DESC;
```
## Emplacement de réplication logique
L’objectif d’un emplacement de réplication est de conserver les modifications non consommées jusqu’à ce qu’elles soient répliquées sur un serveur cible. Pour plus d’informations, consultez [Réplication logique](https://www.postgresql.org/docs/current/logical-replication.html) de PostgreSQL.
Il existe deux types d’emplacement de réplication logique.
**Emplacements de réplication logique inactifs**
Lorsque la réplication est interrompue, les journaux de transactions non consommés ne peuvent pas être supprimés et l’emplacement de réplication devient inactif. Même si un emplacement de réplication logique inactif n’est pas utilisé par un abonné, il reste sur le serveur, ce qui entraîne la conservation des fichiers WAL et empêche la suppression des anciens journaux de transactions. Cela peut augmenter l’utilisation du disque et empêcher spécifiquement l’autovacuum de nettoyer les tables de catalogue internes, car le système doit empêcher le remplacement des informations LSN. Si rien n’est fait, cela peut entraîner un gonflement du catalogue, une dégradation des performances et un risque accru de vacuum de bouclage, ce qui peut entraîner une durée d’indisponibilité des transactions.
**Emplacements de réplication logique actifs mais lents**
Parfois, la suppression des tuples inactifs du catalogue est retardée en raison de la dégradation des performances de la réplication logique. Ce retard de réplication ralentit la mise à jour de `catalog_xmin` et peut entraîner un gonflement du catalogue et un vacuum de bouclage.
La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle trouve un emplacement de réplication logique en tant que bloqueur.
```
blocker | Logical replication slot
database | my_database
blocker_identifier | slot1
wait_event | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}
```
**Action suggérée**
Pour résoudre ce problème, vérifiez la configuration de réplication afin de détecter tout problème lié au schéma cible ou aux données susceptibles de mettre fin au processus d’application. Voici les raisons les plus courantes de ce problème :
+ Colonnes manquantes
+ Types de données incompatibles
+ Non-correspondance des données
+ Table manquante
Si le problème est lié à des problèmes d’infrastructure :
+ Problèmes de réseau : [comment résoudre les problèmes liés à une base de données Amazon RDS dans un état réseau incompatible](https://repost.aws/knowledge-center/rds-incompatible-network).
+ La base de données ou l’instance de base de données n’est pas disponible pour les raisons suivantes :
+ L’instance de réplica n’a plus d’espace de stockage : consultez [Instances de base de données Amazon RDS à court de stockage](https://repost.aws/knowledge-center/rds-out-of-storage) pour en savoir plus sur l’ajout d’espace de stockage.
+ Paramètres incompatibles : consultez [Comment puis-je réparer une instance de base de données Amazon RDS bloquée avec le statut de paramètres incompatibles ?](https://repost.aws/knowledge-center/rds-incompatible-parameters) pour plus d’informations sur la façon dont vous pouvez résoudre le problème.
Si votre instance se trouve en dehors du réseau AWS ou sur AWS EC2, demandez à votre administrateur comment résoudre les problèmes liés à la disponibilité ou à l’infrastructure.
**Suppression de l’emplacement inactif**
**Avertissement**
Attention : avant de supprimer un emplacement de réplication, assurez-vous qu’il n’est pas en cours de réplication, qu’il est inactif et qu’il est dans un état irrécupérable. La suppression prématurée d’un emplacement peut perturber la réplication ou entraîner une perte de données.
Après avoir confirmé que l’emplacement de réplication n’est plus nécessaire, supprimez-le pour permettre à l’autovacuum de continuer. La condition `active = 'f'` garantit que seul un emplacement inactif est supprimé.
```
SELECT pg_drop_replication_slot('slot1') WHERE active ='f'
```
## Réplicas en lecture
Lorsque le paramètre `hot_standby_feedback` est activé pour les [réplicas en lecture Amazon RDS](USER_PostgreSQL.Replication.ReadReplicas.md), il empêche l’autovacuum sur la base de données principale de supprimer les lignes inactives qui pourraient encore être nécessaires aux requêtes exécutées sur le réplica en lecture. Cela concerne tous les types de réplicas en lecture physiques, y compris ceux gérés avec ou sans emplacements de réplication. Ce comportement est nécessaire, car les requêtes exécutées sur le réplica de secours nécessitent que ces lignes restent disponibles sur le réplica principal pour éviter les [conflits de requêtes](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT) et les annulations.
**Réplica en lecture avec emplacement de réplication physique**
Les réplicas en lecture avec des emplacements de réplication physiques améliorent considérablement la fiabilité et la stabilité de la réplication dans RDS pour PostgreSQL. Ces emplacements garantissent que la base de données principale conserve les fichiers journaux d’écriture anticipée essentiels jusqu’à ce que le réplica les traite, préservant ainsi la cohérence des données même en cas de perturbation du réseau.
À partir de RDS pour PostgreSQL version 14, tous les réplicas utilisent des emplacements de réplication. Dans les versions antérieures, seuls les réplicas entre régions utilisaient des emplacements de réplication.
La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle trouve un réplica en lecture avec un emplacement de réplication logique en tant que bloqueur.
```
blocker | Read replica with physical replication slot
database |
blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx
wait_event | Not applicable
autovacuum_lagging_by | 554,080,689
suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query:
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + |
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Réplica en lecture avec réplication de streaming**
Amazon RDS permet de configurer des réplicas en lecture sans emplacement de réplication physique dans les anciennes versions, jusqu’à la version 13. Cette approche réduit la surcharge en permettant au système principal de recycler les fichiers WAL de manière plus agressive, ce qui est avantageux dans les environnements où l’espace disque est limité et peut tolérer des retards de réplica occasionnels. Cependant, sans emplacement, le réplica de secours doit rester synchronisé pour éviter de manquer des fichiers WAL. Amazon RDS utilise des fichiers WAL archivés pour aider le réplica à rattraper son retard, mais ce processus nécessite une surveillance attentive et peut être lent.
La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle trouve un réplica en lecture de diffusion avec un emplacement de réplication logique en tant que bloqueur.
```
blocker | Read replica with streaming replication slot
database | Not applicable
blocker_identifier | xx.x.x.xxx/xx
wait_event | Not applicable
autovacuum_lagging_by | 610,146,760
suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: +
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; +
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. +
|
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Action suggérée**
Comme recommandé dans la colonne `suggested_action`, examinez attentivement ces options pour débloquer l’autovacuum.
+ **Résilier la requête** : en suivant les instructions de la colonne de suggestions, vous pouvez vous connecter au réplica en lecture, comme indiqué dans la colonne suggested\$1action. Il est conseillé de vérifier attentivement l’option permettant de résilier la session. Si la résiliation est considérée comme sûre, vous pouvez utiliser la fonction `pg_terminate_backend()` pour résilier la session. Cette action peut être effectuée par un administrateur (tel que le compte principal RDS) ou par un utilisateur disposant du privilège pg\$1terminate\$1backend() requis.
Vous pouvez exécuter la commande SQL suivante sur le réplica en lecture pour résilier la requête qui empêche le vacuum sur la base de données principale de nettoyer les anciennes lignes. La valeur de `backend_xmin` est indiquée dans la sortie de la fonction :
```
SELECT
pg_terminate_backend(pid)
FROM
pg_catalog.pg_stat_activity
WHERE
backend_xmin::text::bigint = backend_xmin;
```
+ **Désactiver les commentaires de veille permanente** : pensez à désactiver le paramètre `hot_standby_feedback` s’il entraîne des retards de vacuum importants.
Le paramètre `hot_standby_feedback` permet à un réplica en lecture d’informer la base de données principale de son activité de requête, empêchant ainsi la base de données principale d’effectuer une opération de vacuum sur les tables ou les lignes utilisées sur le réplica de secours. Bien que cela garantisse la stabilité des requêtes sur le réplica de secours, cela peut retarder considérablement l’opération de vacuum sur la base de données principale. La désactivation de cette fonction permet à la base de données principale d’effectuer l’opération de vacuum sans attendre que le réplica de secours rattrape le retard. Toutefois, cela peut entraîner des annulations de requêtes ou des échecs sur le réplica de secours s’il tente d’accéder à des lignes qui ont été supprimées par la base de données principale.
+ **Supprimer les réplicas en lecture s’ils ne sont pas nécessaires** : si le réplica en lecture n’est plus nécessaire, vous pouvez le supprimer. Cela supprime la surcharge de réplication associée et permet au système principal de recycler les journaux de transactions sans être freiné par le réplica.
## Tables temporaires
Les [tables temporaires](https://www.postgresql.org/docs/current/sql-createtable.html), créées à l’aide du mot-clé `TEMPORARY`, résident dans le schéma temporaire, par exemple pg\$1temp\$1xxx, et ne sont accessibles qu’à la session qui les a créées. Les tables temporaires sont supprimées à la fin de la session. Cependant, ces tables sont invisibles pour le processus autovacuum de PostgreSQL et doivent être nettoyées manuellement par la session qui les a créées. Essayer d’effectuer un vacuum sur la table temporaire d’une autre session n’a aucun effet.
Dans des circonstances exceptionnelles, une table temporaire peut exister sans qu’elle appartienne à une session active. Si la session liée à une table temporaire se termine de façon inattendue en raison d’un incident fatal, d’un problème réseau ou d’un événement similaire, il est possible que cette table ne soit pas nettoyée et qu’elle devienne ainsi une table « orpheline ». Lorsque le processus autovacuum de PostgreSQL détecte une table temporaire orpheline, il consigne le message suivant :
```
LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"
```
La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle identifie une table temporaire comme un bloqueur. Pour que cette fonction affiche correctement la sortie relative aux tables temporaires, elle doit être exécutée dans la base de données dans laquelle se trouvent ces tables.
```
blocker | Temporary table
database | my_database
blocker_identifier | pg_temp_14.ttemp
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"DROP TABLE ttemp;"}
```
**Action suggérée**
Suivez les instructions fournies dans la colonne `suggestion` de sortie pour identifier et supprimer la table temporaire qui empêche l’exécution de l’autovacuum. Utilisez la commande suivante pour supprimer la table temporaire signalée par `postgres_get_av_diag()`. Remplacez le nom de la table en fonction de la sortie fournie par la fonction `postgres_get_av_diag()`.
```
DROP TABLE my_temp_schema.my_temp_table;
```
La requête suivante peut être utilisée pour identifier les tables temporaires :
```
SELECT
oid,
relname,
relnamespace::regnamespace,
age(relfrozenxid)
FROM
pg_class
WHERE
relpersistence = 't'
ORDER BY
age(relfrozenxid) DESC;
```
# Résolution des bloqueurs de vacuum non identifiables dans RDS pour PostgreSQL
Cette section explore d’autres raisons qui peuvent empêcher l’opération de vacuum de progresser. Ces problèmes ne sont actuellement pas directement identifiables par la fonction `postgres_get_av_diag()`.
**Topics**
+ [
## Pages non valides
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages)
+ [
## Incohérence de l’index
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency)
+ [
## Taux de transaction exceptionnellement élevé
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate)
## Pages non valides
Une erreur de page non valide se produit lorsque PostgreSQL détecte une incompatibilité dans le total de contrôle d’une page lors de l’accès à cette page. Le contenu est illisible, ce qui empêche l’autovacuum de geler les tuples. Cela arrête efficacement le processus de nettoyage. L’erreur suivante est écrite dans le journal de PostgreSQL :
```
WARNING: page verification failed, calculated checksum YYYYY but expected XXXX
ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT: automatic vacuum of table myschema.mytable
```
**Détermination du type d’objet**
```
ERROR: invalid page in block 4305910 of relation base/16403/186752608
WARNING: page verification failed, calculated checksum 50065 but expected 60033
```
À partir du message d’erreur, le chemin `base/16403/186752608` fournit les informations suivantes :
+ « base » est le nom du répertoire situé sous le répertoire de données PostgreSQL.
+ « 16403 » est l’OID de la base de données, que vous pouvez consulter dans le catalogue système `pg_database`.
+ « 186752608 » est le `relfilenode`, que vous pouvez utiliser pour rechercher le schéma et le nom de l’objet dans le catalogue système `pg_class`.
En vérifiant le résultat de la requête suivante dans la base de données concernée, vous pouvez déterminer le type d’objet. La requête suivante récupère les informations d’objet pour l’oid 186752608. Remplacez l’OID par celui correspondant à l’erreur que vous avez rencontrée.
```
SELECT
relname AS object_name,
relkind AS object_type,
nspname AS schema_name
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.oid = 186752608;
```
Pour plus d’informations, consultez la documentation de PostgreSQL [https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html) pour connaître tous les types d’objets pris en charge, indiqués par la colonne `relkind` dans `pg_class`.
**Conseils**
La solution la plus efficace à ce problème dépend de la configuration de votre instance Amazon RDS spécifique et du type de données concerné par la page incohérente.
**Si le type d’objet est un index :**
Il est recommandé de reconstruire l’index.
+ **Utilisation de l’option `CONCURRENTLY`** : avant PostgreSQL version 12, la reconstruction d’un index nécessitait un verrou de table exclusif, limitant ainsi l’accès à la table. Avec PostgreSQL versions 12 et ultérieures, l’option `CONCURRENTLY` permet le verrouillage au niveau des lignes, ce qui améliore considérablement la disponibilité de la table. Voici la commande :
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Bien que l’option `CONCURRENTLY` soit moins perturbatrice, elle peut être plus lente sur les tables très occupées. Envisagez de générer l’index pendant les périodes de faible trafic si possible.
Pour plus d’informations, consultez la documentation de PostgreSQL sur [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html).
+ **Utilisation de l’option `INDEX_CLEANUP FALSE`** : si les index sont volumineux et que le temps estimé pour les finaliser est significatif, vous pouvez débloquer l’autovacuum en exécutant une opération `VACUUM FREEZE` manuelle tout en excluant les index. Cette fonctionnalité est disponible dans PostgreSQL versions 12 et ultérieures.
Ignorer les index vous permet d’éviter le processus de vacuum de l’index incohérent et d’atténuer le problème de bouclage. Toutefois, cela ne résout pas le problème sous-jacent de page non valide. Pour résoudre complètement le problème de page non valide, vous devrez tout de même reconstruire l’index.
**Si le type d’objet est une vue matérialisée :**
Si une erreur de page non valide se produit sur une vue matérialisée, connectez-vous à la base de données concernée et actualisez-la pour corriger la page non valide :
Actualisez la vue matérialisée :
```
REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;
```
Si l’actualisation échoue, essayez de recréer la vue :
```
DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;
```
L’actualisation ou la recréation de la vue matérialisée permet de la restaurer sans affecter les données de la table sous-jacente.
**Pour tous les autres types d’objets :**
Pour tous les autres types d’objets, contactez l’assistance AWS.
## Incohérence de l’index
Un index dont la logique est incohérente peut empêcher l’autovacuum de progresser. Les erreurs suivantes ou des erreurs similaires sont journalisées pendant la phase de vacuum de l’index ou lorsque des instructions SQL accèdent à l’index.
```
ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
```
```
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT: while vacuuming index index_name of relation schema.table
```
**Conseils**
Reconstruisez l’index ou ignorez les index en utilisant `INDEX_CLEANUP` lors d’une opération `VACUUM FREEZE` manuelle. Pour plus d’informations sur la façon de reconstruire l’index, consultez [Si le type d’objet est un index](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages).
+ **Utilisation de l’option CONCURRENTLY** : avant PostgreSQL version 12, la reconstruction d’un index nécessitait un verrou de table exclusif, limitant ainsi l’accès à la table. Avec PostgreSQL versions 12 et ultérieures, l’option CONCURRENTLY permet le verrouillage au niveau des lignes, ce qui améliore considérablement la disponibilité de la table. Voici la commande :
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Bien que l’option CONCURRENTLY soit moins perturbatrice, elle peut être plus lente sur les tables très occupées. Envisagez de générer l’index pendant les périodes de faible trafic si possible. Pour plus d’informations, consultez [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html) dans la documentation de *PostgreSQL*.
+ **Utilisation de l’option INDEX\$1CLEANUP FALSE** : si les index sont volumineux et que le temps estimé pour les finaliser est significatif, vous pouvez débloquer l’autovacuum en exécutant une opération VACUUM FREEZE manuelle tout en excluant les index. Cette fonctionnalité est disponible dans PostgreSQL versions 12 et ultérieures.
Ignorer les index vous permet d’éviter le processus de vacuum de l’index incohérent et d’atténuer le problème de bouclage. Toutefois, cela ne résout pas le problème sous-jacent de page non valide. Pour résoudre complètement le problème de page non valide, vous devrez tout de même reconstruire l’index.
## Taux de transaction exceptionnellement élevé
Dans PostgreSQL, les taux de transactions élevés peuvent avoir un impact significatif sur les performances de l’autovacuum, ce qui ralentit le nettoyage des tuples inactifs et augmente le risque de bouclage des ID de transaction. Vous pouvez surveiller le taux de transaction en mesurant la différence de `max(age(datfrozenxid))` entre deux périodes, généralement par seconde. En outre, vous pouvez utiliser les métriques de compteur suivantes de RDS Performance Insights pour mesurer le taux de transaction (somme de xact\$1commit et xact\$1rollback), qui est le nombre total de transactions.
| Compteur | Type | Unité | Métrique |
| --- | --- | --- | --- |
| xact\$1commit | Transactions | Validations par seconde | db.Transactions.xact\$1commit |
| xact\$1rollback | Transactions | Restaurations par seconde | db.Transactions.xact\$1rollback |
Une augmentation rapide indique une charge de transactions élevée, qui peut surcharger l’autovacuum, provoquant un gonflement, des conflits de verrouillage et des problèmes de performances potentiels. Cela peut avoir un impact négatif sur le processus d’autovacuum de plusieurs manières :
+ **Activité liée à la table :** la table en question peut faire l’objet d’un volume élevé de transactions, ce qui peut entraîner des retards.
+ **Ressources système :** l’ensemble du système est peut-être surchargé, ce qui rend difficile pour l’autovacuum d’accéder aux ressources nécessaires pour fonctionner efficacement.
Envisagez les stratégies suivantes pour permettre à l’autovacuum de fonctionner plus efficacement et de mener à bien ses tâches dans le délai imparti :
1. Réduisez le taux de transaction si possible. Envisagez de traiter par lots ou de regrouper les transactions similaires dans la mesure du possible.
1. Ciblez les tables fréquemment mises à jour avec une opération `VACUUM FREEZE` manuelle tous les soirs, toutes les semaines ou toutes les deux semaines pendant les heures creuses.
1. Envisagez d’augmenter verticalement votre classe d’instance pour allouer davantage de ressources système afin de gérer le volume élevé de transactions et l’autovacuum.
# Résolution des problèmes de performance de vacuum dans RDS pour PostgreSQL
Cette section décrit les facteurs qui contribuent souvent au ralentissement des performances de vacuum et explique comment résoudre ces problèmes.
**Topics**
+ [
## Vacuum des index de grande taille
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Large_indexes)
+ [
## Trop de tables ou de bases de données pour le vacuum
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Multiple_tables)
+ [
## Un vacuum agressif (pour éviter tout bouclage) est en cours d’exécution
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
## Vacuum des index de grande taille
VACUUM fonctionne selon des phases séquentielles : initialisation, analyse des tas, vacuum des index et des tas, nettoyage des index, troncature des tas et nettoyage final. Pendant l’analyse des tas, le processus élague les pages, les défragmente et les gèle. Une fois l’analyse des tas terminée, VACUUM nettoie les index, renvoie les pages vides au système d’exploitation et effectue les dernières tâches de nettoyage, telles que le vacuum de la carte de l’espace libre et la mise à jour des statistiques.
L’opération de vacuum de l’index peut nécessiter plusieurs passages lorsque la capacité `maintenance_work_mem` (ou `autovacuum_work_mem`) est insuffisante pour traiter l’index. Dans PostgreSQL 16 et versions antérieures, une limite de mémoire de 1 Go pour le stockage des ID de tuple inactifs imposait souvent plusieurs passages sur les index volumineux. PostgreSQL 17 introduit `TidStore`, qui alloue de la mémoire de manière dynamique au lieu d’utiliser un tableau à allocation unique. Cela permet de supprimer la contrainte de 1 Go, d’utiliser la mémoire de manière plus efficace et d’éviter d’avoir à analyser plusieurs fois chaque index.
Les index de grande taille peuvent toujours nécessiter plusieurs passages dans PostgreSQL 17 si la mémoire disponible ne peut pas prendre en charge l’intégralité du traitement des index en une seule fois. Généralement, les index de grande taille contiennent davantage de tuples inactifs qui nécessitent plusieurs passages.
**Détection des opérations de vacuum lentes**
La fonction `postgres_get_av_diag()` peut détecter les opérations de vacuum qui sont lentes en raison d’une mémoire insuffisante. Pour plus d’informations sur cette fonction, consultez [Installation d’outils de surveillance et de diagnostic d’autovacuum dans RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md).
La fonction `postgres_get_av_diag()` émet les notifications suivantes lorsque la mémoire disponible n’est pas suffisante pour terminer l’opération de vacuum de l’index en un seul passage.
**`rds_tools` 1.8**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory.
Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).
```
**`rds_tools` 1.9**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more
memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual
vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see
[Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
.
```
**Note**
La fonction `postgres_get_av_diag()` repose sur `pg_stat_all_tables.n_dead_tup` pour l’estimation de la quantité de mémoire requise pour l’opération de vacuum de l’index.
Lorsque la fonction `postgres_get_av_diag()` identifie une opération de vacuum lente qui nécessite plusieurs analyses d’index en raison d’une capacité `autovacuum_work_mem` insuffisante, elle génère le message suivant :
```
NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming.
For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
```
**Conseils**
Vous pouvez appliquer les solutions de contournement suivantes à l’aide d’une opération `VACUUM FREEZE` manuelle pour accélérer le gel de la table.
**Augmentation de la mémoire pour l’opération de vacuum**
Comme suggéré par la fonction `postgres_get_av_diag()`, il est conseillé d’augmenter le paramètre `autovacuum_work_mem` pour faire face aux contraintes de mémoire potentielles au niveau de l’instance. Même si `autovacuum_work_mem` est un paramètre dynamique, il est important de noter que pour que le nouveau paramètre de mémoire prenne effet, le démon autovacuum doit redémarrer ses applications de travail. Pour ce faire :
1. Vérifiez que le nouveau paramètre est en place.
1. Arrêtez les processus qui exécutent une opération d’autovacuum.
Cette approche garantit que l’allocation de mémoire ajustée est appliquée aux nouvelles opérations d’autovacuum.
Pour des résultats plus immédiats, pensez à effectuer une opération `VACUUM FREEZE` manuelle avec un paramètre `maintenance_work_mem` augmenté au cours de votre session :
```
SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;
```
Si vous utilisez Amazon RDS et que vous constatez que vous avez besoin de mémoire supplémentaire pour prendre en charge des valeurs plus élevées pour `maintenance_work_mem` ou `autovacuum_work_mem`, envisagez de passer à une classe d’instance avec plus de mémoire. Cela peut fournir les ressources nécessaires pour améliorer les opérations de vacuum manuelles et automatiques, ce qui se traduit par une amélioration des performances globales du vacuum et des bases de données.
**Désactivation d’INDEX\$1CLEANUP**
L’opération `VACUUM` manuelle de PostgreSQL 12 et versions ultérieures permet d’ignorer la phase de nettoyage de l’index, tandis que l’autovacuum d’urgence dans PostgreSQL 14 et versions ultérieures le fait automatiquement en fonction du paramètre [https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE).
**Avertissement**
Ignorer le nettoyage de l’index peut entraîner un gonflement de l’index et avoir un impact négatif sur les performances des requêtes. Pour pallier ce problème, pensez à réindexer les index concernés ou à en effectuer le vacuum pendant une période de maintenance.
Pour obtenir des conseils supplémentaires sur la gestion des index de grande taille, reportez-vous à la documentation sur [Gestion de la fonction autovacuum avec de grands index](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md).
**Opérations de vacuum d’index en parallèle**
À partir de PostgreSQL 13, les index peuvent faire l’objet d’un vacuum et d’un nettoyage en parallèle par défaut avec une opération `VACUUM` manuelle. Un processus de travail de vacuum est alors assigné à chaque index. Cependant, pour que PostgreSQL puisse déterminer si une opération de vacuum peut être exécutée en parallèle, des critères spécifiques doivent être remplis :
+ Il doit y avoir au moins deux index.
+ Le paramètre `max_parallel_maintenance_workers` doit être défini sur au moins 2.
+ La taille de l’index doit dépasser la limite de `min_parallel_index_scan_size`, qui est par défaut de 512 Ko.
Vous pouvez ajuster le paramètre `max_parallel_maintenance_workers` en fonction du nombre de processeurs virtuels disponibles sur votre instance Amazon RDS et du nombre d’index sur la table afin d’optimiser le délai d’exécution de l’opération de vacuum.
Pour plus d’informations, consultez [Opérations de vacuum en parallèle dans Amazon RDS pour PostgreSQL et Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/parallel-vacuuming-in-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/).
## Trop de tables ou de bases de données pour le vacuum
Comme indiqué dans la documentation [The Autovacuum Daemon](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM') de PostgreSQL, le démon autovacuum fonctionne par le biais de plusieurs processus. Cela inclut un lanceur d’autovacuum permanent chargé de démarrer les processus de travail d’autovacuum pour chaque base de données du système. Le lanceur programme ces applications de travail pour qu’elles soient lancées environ toutes les `autovacuum_naptime` secondes par base de données.
Avec « N » bases de données, une nouvelle application de travail commence environ toutes les [`autovacuum_naptime`/N secondes]. Cependant, le nombre total d’applications de travail simultanés est limité par le paramètre `autovacuum_max_workers`. Si le nombre de bases de données ou de tables qui nécessitent un vacuum dépasse cette limite, la base de données ou table suivante est traitée dès qu’une application de travail est disponible.
Lorsque de nombreuses tables ou bases de données volumineuses nécessitent un vacuum simultané, toutes les applications de travail d’autovacuum disponibles peuvent être occupées pendant une période prolongée, ce qui retarde la maintenance des autres tables et bases de données. Dans les environnements où les taux de transactions sont élevés, ce goulot d’étranglement peut rapidement s’aggraver et potentiellement entraîner des problèmes de vacuum de bouclage au sein de votre instance Amazon RDS.
Lorsque `postgres_get_av_diag()` détecte un nombre élevé de tables ou de bases de données, il fournit la recommandation suivante :
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.
```
**Conseils**
**Augmentation d’autovacuum\$1max\$1workers**
Pour accélérer l’opération de vacuum, nous vous recommandons de régler le paramètre `autovacuum_max_workers` afin d’autoriser un plus grand nombre d’applications de travail d’autovacuum simultanées. Si les problèmes de performances persistent, envisagez d’augmenter verticalement votre instance Amazon RDS vers une classe comportant davantage de processeurs virtuels, ce qui peut améliorer encore les capacités de traitement parallèle.
## Un vacuum agressif (pour éviter tout bouclage) est en cours d’exécution
L’âge de la base de données (MaximumUsedTransactionIDs) dans PostgreSQL ne diminue que lorsqu’un vacuum agressif (pour empêcher tout bouclage) s’est terminé avec succès. Jusqu’à ce que ce vacuum se termine, l’âge continue d’augmenter en fonction du taux de transaction.
La fonction `postgres_get_av_diag()` génère le message `NOTICE` suivant lorsqu’elle détecte un vacuum agressif. Cependant, elle ne déclenche cette sortie qu’après que le vacuum a été actif pendant au moins deux minutes.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Pour plus d’informations sur le vacuum agressif, consultez [Lorsqu’un vacuum agressif est déjà en cours d’exécution](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md).
Vous pouvez vérifier si un vacuum agressif est en cours à l’aide de la requête suivante :
```
SELECT
a.xact_start AS start_time,
v.datname "database",
a.query,
a.wait_event,
v.pid,
v.phase,
v.relid::regclass,
pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
(
SELECT
string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS index_sizes,
trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
v.index_vacuum_count || '/' || (
SELECT
count(*)
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS step2_vacuum_indexes,
trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
pg_stat_activity a
INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;
```
Vous pouvez déterminer s’il s’agit d’un vacuum agressif (pour éviter tout bouclage) en vérifiant la colonne de requête dans la sortie. L’expression « pour éviter tout bouclage » indique qu’il s’agit d’un vacuum agressif.
```
query | autovacuum: VACUUM public.t3 (to prevent wraparound)
```
Supposons, par exemple, que vous disposiez d’un bloqueur à l’âge d’un milliard de transactions et d’une table nécessitant un vacuum agressif pour éviter tout bouclage au même âge de transaction. De plus, il existe un autre bloqueur à l’âge de 750 millions de transactions. Après avoir éliminé le bloqueur à l’âge d’un milliard de transactions, l’âge des transactions ne tombera pas immédiatement à 750 millions. Il restera élevé jusqu’à ce que la table nécessitant un vacuum agressif ou toute transaction dont l’âge est supérieur à 750 millions soit finalisée. Au cours de cette période, l’âge des transactions de votre cluster PostgreSQL continuera d’augmenter. Une fois le processus de vacuum terminé, l’âge des transactions tombe à 750 millions, mais recommence à augmenter jusqu’à ce que l’opération de vacuum soit terminée. Ce cycle se poursuit tant que ces conditions persistent, jusqu’à ce que l’âge des transactions atteigne finalement le niveau configuré pour votre instance Amazon RDS, spécifié par `autovacuum_freeze_max_age`.
# Explication des messages NOTICE dans RDS pour PostgreSQL
La fonction `postgres_get_av_diag()` fournit les messages NOTICE suivants :
**Lorsque l’âge n’a pas encore atteint le seuil de surveillance**
Le seuil de surveillance `postgres_get_av_diag()` pour identifier les bloqueurs est de 500 millions de transactions par défaut. Si `postgres_get_av_diag()` génère le message NOTICE suivant, l’âge de la transaction n’a pas encore atteint ce seuil.
```
NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.
```
**Non connecté à la base de données dont l’ID de transaction est le plus ancien**
La fonction `postgres_get_av_diag()` fournit le résultat le plus précis lorsqu’elle est connectée à la base de données dont l’ID de transaction est le plus ancien. La base de données dont l’âge de l’ID de transaction est le plus ancien indiqué par `postgres_get_av_diag()` sera différente de « my\$1database » dans votre cas. Si vous n’êtes pas connecté à la bonne base de données, le message NOTICE suivant est généré :
```
NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.
```
Il est important de se connecter à la base de données dont l’âge de la transaction est le plus ancien pour les raisons suivantes :
+ **Identification des bloqueurs de tables temporaires :** les métadonnées des tables temporaires étant spécifiques à chaque base de données, elles se trouvent généralement dans la base de données dans laquelle elles ont été créées. Toutefois, si une table temporaire se trouve être le principal bloqueur et qu’elle se trouve dans la base de données contenant la transaction la plus ancienne, cela peut prêter à confusion. La connexion à la base de données appropriée garantit l’identification précise du bloqueur de table temporaire.
+ **Diagnostic des vacuums lents :** les métadonnées d’index et les informations relatives au nombre de tables sont spécifiques à chaque base de données et sont nécessaires pour diagnostiquer les problèmes de lenteur du vacuum.
**La base de données dont l’âge de la transaction est le plus ancien se trouve sur une base de données rdsadmin ou template0**
Dans certains cas, les bases de données `rdsadmin` ou `template0` peuvent être identifiées comme étant celles dont l’ID de transaction est le plus ancien. Dans ce cas, `postgres_get_av_diag()` émet le message NOTICE suivant :
```
NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.
```
Vérifiez que le bloqueur répertorié ne provient d’aucune de ces deux bases de données. Si la présence du bloqueur est signalée dans `rdsadmin` ou `template0`, contactez le support, car ces bases de données ne sont pas accessibles aux utilisateurs et nécessitent une intervention.
Il est très peu probable que la base de données `rdsadmin` ou `template0` contienne un bloqueur principal.
**Lorsqu’un vacuum agressif est déjà en cours d’exécution**
La fonction `postgres_get_av_diag()` est conçue pour signaler lorsqu’un processus de vacuum agressif est en cours d’exécution, mais elle ne déclenche cette sortie que lorsque le vacuum est actif depuis au moins 1 minute. Ce délai intentionnel contribue à réduire les risques de faux positifs. En attendant, la fonction garantit que seuls les vacuums efficaces et significatifs sont signalés, ce qui permet une surveillance plus précise et plus fiable de l’activité du vacuum.
La fonction `postgres_get_av_diag()` génère le message NOTICE suivant lorsqu’elle détecte un ou plusieurs vacuums agressifs en cours.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Comme indiqué dans le message NOTICE, continuez à surveiller les performances du vacuum. Pour plus d’informations sur le vacuum agressif, consultez [Un vacuum agressif (pour éviter tout bouclage) est en cours d’exécution](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
**Lorsque l’autovacuum est désactivé**
La fonction `postgres_get_av_diag()` génère le message NOTICE suivant si l’autovacuum est désactivé sur votre instance de base de données :
```
NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.
```
L’autovacuum est une fonctionnalité essentielle de votre instance de base de données RDS pour PostgreSQL. Elle garantit le bon fonctionnement de la base de données. Elle supprime automatiquement les anciennes versions de lignes, récupère de l’espace de stockage et évite le gonflement des tables, ce qui contribue à garantir l’efficacité des tables et des index pour des performances optimales. En outre, elle protège contre le bouclage des ID de transaction, qui peut interrompre les transactions sur votre instance Amazon RDS. La désactivation de l’autovacuum peut entraîner une baisse à long terme des performances et de la stabilité de la base de données. Nous vous conseillons de laisser cette fonctionnalité activée en permanence. Pour plus d’informations, consultez [Présentation d’autovacuum dans les environnements RDS pour PostgreSQL](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/).
La désactivation de l’autovacuum n’arrête pas les vacuums agressifs. Ils se produiront toujours une fois que vos tables auront atteint le seuil `autovacuum_freeze_max_age`.
**Le nombre de transactions restantes est extrêmement faible**
La fonction `postgres_get_av_diag()` génère le message NOTICE suivant lorsqu’un vacuum de bouclage est imminent. Ce message NOTICE est émis lorsque votre instance Amazon RDS est à 100 millions de transactions avant que de nouvelles transactions ne soient potentiellement rejetées.
```
WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.
```
Une action immédiate est nécessaire pour éviter toute durée d’indisponibilité de la base de données. Vous devez surveiller de près vos opérations de vacuum et envisager de lancer manuellement une opération `VACUUM FREEZE` sur la base de données concernée afin d’éviter les échecs de transaction.
# Gestion d'un nombre élevé d'objets dans Amazon RDS pour PostgreSQL Amazon Aurora
Bien que les limites de PostgreSQL soient théoriques, le nombre d'objets extrêmement élevé dans une base de données peut avoir un impact notable sur les performances de diverses opérations. Cette documentation couvre plusieurs types d'objets courants qui, lorsqu'ils ont un nombre total élevé, peuvent avoir plusieurs impacts possibles.
Le tableau suivant fournit un résumé des types d'objets et de leurs impacts potentiels :
**Types d'objets et impacts potentiels**
| Type d'objet | Aspirateur automatique | Réplication logique | Mise à niveau de la version majeure | pg\$1dumpg/pg\$1restore | Performance générale | Redémarrage de l'instance |
| --- | --- | --- | --- | --- | --- | --- |
| [Relations](#PostgreSQL.HighObjectCount.Relations) | x | | h/24, j/7 | h/24, j/7 | x | |
| [Tables temporaires](#PostgreSQL.HighObjectCount.TempTables) | x | | | | x | |
| [Tables non enregistrées](#PostgreSQL.HighObjectCount.UnloggedTables) | | x | | | | x |
| [Partitions](#PostgreSQL.HighObjectCount.Partitions) | | | | | x | |
| [Fichiers temporaires](#PostgreSQL.HighObjectCount.TempFiles) | | | | | x | |
| [Séquences](#PostgreSQL.HighObjectCount.Sequences) | | x | | | | |
| [Objets de grande taille](#PostgreSQL.HighObjectCount.LargeObjects) | | x | x | | | |
## Relations
Il n'existe pas de limite stricte spécifique concernant le nombre de tables dans une base de données PostgreSQL. La limite théorique est extrêmement élevée, mais d'autres limites pratiques doivent être prises en compte lors de la conception de la base de données.
**Conséquence : Autovacuum prend du retard**
Autovacuum peut avoir du mal à faire face à la croissance des numéros de transaction ou à la surcharge de travail en raison du manque de personnel par rapport à la quantité de travail.
**Action recommandée :** Plusieurs facteurs permettent de régler l'autovacuum afin de s'adapter correctement à un nombre donné de tables et à une charge de travail donnée. Consultez [Meilleures pratiques d'utilisation de l'aspirateur automatique PostgreSQL Meilleures pratiques d'utilisation de l'aspirateur automatique PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) d'aspirateur automatique appropriés. Utilisez l'[utilitaire ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.html) pour surveiller les problèmes liés à la croissance des identifiants de transaction.
**Conséquence : mise à niveau de la version majeure /pg\$1dump et restauration**
Amazon RDS utilise l'option « --link » lors de l'exécution de pg\$1upgrade pour éviter d'avoir à faire des copies des fichiers de données. Les métadonnées du schéma doivent toujours être restaurées dans la nouvelle version de la base de données. Même avec parallel pg\$1restore, s'il existe un nombre important de relations, cela augmentera le temps d'arrêt.
**Conséquence : dégradation générale des performances**
Dégradation générale des performances due à la taille du catalogue. Chaque table et ses colonnes associées s'ajouteront `pg_class` aux `pg_attribute` `pg_depend` tables fréquemment utilisées dans les opérations de base de données normales. Aucun événement d'attente spécifique ne sera visible, mais l'efficacité de la mémoire tampon partagée sera affectée.
**Action recommandée :** Vérifiez régulièrement la saturation des tables pour ces tables spécifiques et effectuez occasionnellement une opération `VACUUM FULL` sur ces tables spécifiques. Sachez que les tables `VACUUM FULL` du catalogue nécessitent un `ACCESS EXCLUSIVE` verrou, ce qui signifie qu'aucune autre requête ne pourra y accéder tant que l'opération ne sera pas terminée.
**Conséquence : épuisement du descripteur de fichier**
Erreur : « Descripteurs de fichiers insuffisants : trop de fichiers ouverts dans le système ; relâchez-les et réessayez ». Le `max_files_per_process` paramètre PostgreSQL détermine le nombre de fichiers que chaque processus peut ouvrir. Si un grand nombre de connexions rejoignent un grand nombre de tables, il est possible d'atteindre cette limite.
**Action recommandée :**
+ La réduction de la valeur du paramètre `max_files_per_process` peut contribuer à atténuer cette erreur. Chaque processus et sous-processus (par exemple, une requête parallèle) peut ouvrir ce nombre de fichiers, et si les requêtes joignent plusieurs tables, cette limite peut être dépassée.
+ Réduisez le nombre total de connexions et utilisez un pool de connexions tel qu'[Amazon RDS Proxy, Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) ou d'autres solutions telles que. PgBouncer Pour en savoir plus, consultez le [PgBouncer site Web](https://www.pgbouncer.org/).
**Impact : épuisement des inodes**
Erreur : « Il ne reste plus d'espace sur l'appareil ». Si cela se produit alors qu'il y a suffisamment d'espace libre de stockage, cela est dû au manque d'inodes. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) fournit une visibilité sur les inodes utilisés et sur le nombre maximum d'inodes disponibles pour votre hôte.
**Seuil approximatif :** [millions](#PostgreSQL.HighObjectCount.Note)
## Tables temporaires
L'utilisation de tables temporaires est utile pour les données de test ou les résultats intermédiaires et constitue un modèle courant observé dans de nombreux moteurs de base de données. Les implications d'une utilisation intensive dans PostgreSQL doivent être comprises pour éviter certains écueils. Chaque table temporaire créée et supprimée ajoute des lignes aux tables du catalogue du système, ce qui, lorsqu'elles deviennent trop volumineuses, entraîne des problèmes de performances généraux.
**Conséquence : Autovacuum prend du retard**
Les tables temporaires ne sont pas aspirées par autovacuum, mais elles conserveront les transactions IDs pendant leur existence et peuvent être enveloppées si elles ne sont pas retirées.
**Action recommandée :** Les tables temporaires seront conservées pendant toute la durée de la session qui les a créées ou peuvent être supprimées manuellement. Une bonne pratique consistant à éviter les transactions de longue durée avec des tables temporaires empêchera ces tables de contribuer à la croissance maximale des identifiants de transaction utilisés.
**Conséquence : dégradation générale des performances**
Dégradation générale des performances due à la taille du catalogue. Lorsque les sessions créent et suppriment continuellement des tables temporaires, elles s'ajoutent à celles `pg_attribute` qui sont fréquemment utilisées dans le cadre des opérations normales de base de données. `pg_class` `pg_depend` Aucun événement d'attente spécifique ne sera visible, mais l'efficacité de la mémoire tampon partagée sera affectée.
**Action recommandée :**
+ Vérifiez régulièrement l'excès de volume des tables pour ces tables spécifiques et effectuez de temps en temps une `VACUUM FULL` sur ces tables spécifiques. Sachez que les tables `VACUUM FULL` du catalogue nécessitent un `ACCESS EXCLUSIVE` verrou, ce qui signifie qu'aucune autre requête ne pourra y accéder tant que l'opération ne sera pas terminée.
+ Si les tables temporaires sont très utilisées, il est vivement recommandé d'utiliser l'une `VACUUM FULL` de ces tables de catalogue spécifiques avant une mise à niveau majeure de version afin de réduire les temps d'arrêt.
**Bonnes pratiques générales :**
+ Réduisez l'utilisation de tables temporaires en utilisant des expressions de table communes pour produire des résultats intermédiaires. Cela peut parfois compliquer les requêtes nécessaires, mais éliminera les impacts énumérés ci-dessus.
+ Réutilisez les tables temporaires en utilisant la `TRUNCATE` commande pour effacer le contenu au lieu de suivre des drop/create étapes. Cela éliminera également le problème de croissance des identifiants de transaction causé par les tables temporaires.
**Seuil approximatif :** [dizaines de milliers](#PostgreSQL.HighObjectCount.Note)
## Tables non enregistrées
Les tables non enregistrées peuvent offrir des gains de performance car elles ne génèrent aucune information WAL. Ils doivent être utilisés avec précaution car ils n'offrent aucune durabilité lors de la restauration d'une base de données suite à un crash, car ils seront tronqués. Il s'agit d'une opération coûteuse dans PostgreSQL car chaque table délogée est tronquée en série. Bien que cette opération soit rapide pour un petit nombre de tables non enregistrées, lorsqu'elles se comptent par milliers, elle peut commencer à retarder considérablement le démarrage.
**Conséquence : réplication logique**
Les tables non enregistrées ne sont généralement pas incluses dans la réplication logique, y compris les déploiements [bleu/vert Les déploiements](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) .
**Conséquence : temps d'arrêt prolongé pendant la restauration**
Quel que soit l'état d'une base de données impliquant une restauration après incident, tel que le redémarrage multi-AZ avec basculement, la point-in-time restauration Amazon RDS et la mise à niveau de la version majeure d'Amazon RDS, l'opération sérialisée de troncation des tables non enregistrées se produit. Cela peut entraîner des temps d'arrêt bien plus élevés que prévu.
**Action recommandée :**
+ Limitez l'utilisation de tables non enregistrées uniquement aux données susceptibles d'être perdues lors des opérations de restauration après incident de base de données.
+ Réduisez l'utilisation de tables non enregistrées, car le comportement actuel de troncature en série peut entraîner un temps considérable de démarrage d'une base de données.
**Bonnes pratiques générales :**
+ Les tables non enregistrées ne sont pas protégées contre les pannes. Le lancement d'une point-in-time restauration, qui implique une restauration après incident, prend beaucoup de temps dans PostgreSQL car il s'agit d'un processus en série qui tronque chaque table.
**Seuil approximatif :** en [milliers](#PostgreSQL.HighObjectCount.Note)
## Partitions
Le partitionnement peut améliorer les performances des requêtes et fournir une organisation logique des données. Dans les scénarios idéaux, le partitionnement est organisé de telle sorte que l'élagage des partitions puisse être utilisé lors de la planification et de l'exécution des requêtes. L'utilisation d'un trop grand nombre de partitions peut avoir un impact négatif sur les performances des requêtes et la maintenance de la base de données. Le choix du mode de partitionnement d'une table doit être fait avec soin, car les performances de planification et d'exécution des requêtes peuvent être affectées négativement par une mauvaise conception. Consultez la documentation de [PostgreSQL](https://www.postgresql.org/docs/current/ddl-partitioning.html) pour plus de détails sur le partitionnement.
**Conséquence : dégradation générale des performances**
Parfois, le temps de planification augmente et il devient plus difficile d'expliquer les plans pour vos requêtes, ce qui rend difficile l'identification des opportunités de réglage. Pour les versions de PostgreSQL antérieures à 18, de nombreuses partitions présentant une charge de travail élevée peuvent entraîner des temps d'attente. `LWLock:LockManager`
**Action recommandée :** déterminez un nombre minimum de partitions qui vous permettront d'organiser vos données tout en garantissant une exécution performante des requêtes.
**Impact : complexité de la maintenance**
Un nombre très élevé de partitions entraînera des difficultés de maintenance, telles que la pré-création et la suppression. Autovacuum traitera les cloisons comme des relations normales et devra effectuer un nettoyage régulier, ce qui nécessitera un nombre suffisant de travailleurs pour effectuer la tâche.
**Action recommandée :**
+ Assurez-vous de précréer des partitions afin que la charge de travail ne soit pas bloquée lorsqu'une nouvelle partition est nécessaire (par exemple, des partitions mensuelles) et que les anciennes partitions sont supprimées.
+ Assurez-vous de disposer d'un nombre suffisant d'aspirateurs automatiques pour effectuer l'entretien normal de nettoyage de toutes les cloisons.
**Seuil approximatif :** [centaines](#PostgreSQL.HighObjectCount.Note)
## Fichiers temporaires
Contrairement aux tables temporaires mentionnées ci-dessus, les fichiers temporaires sont créés par PostgreSQL lorsqu'une requête complexe peut effectuer plusieurs opérations de tri ou de hachage en même temps, chaque opération utilisant la mémoire d'instance pour stocker les résultats jusqu'à la valeur spécifiée dans le paramètre. `work_mem` Lorsque la mémoire de l’instance n’est pas suffisante, des fichiers temporaires sont créés pour stocker les résultats. Voir [Gestion des fichiers temporaires](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ManagingTempFiles.html) pour plus de détails sur les fichiers temporaires. Si votre charge de travail génère un grand nombre de ces fichiers, cela peut avoir plusieurs conséquences.
**Conséquence : épuisement du descripteur de fichier**
Erreur : « Descripteurs de fichiers insuffisants : trop de fichiers ouverts dans le système ; relâchez-les et réessayez ». Le `max_files_per_process` paramètre PostgreSQL détermine le nombre de fichiers que chaque processus peut ouvrir. Si un grand nombre de connexions rejoignent un grand nombre de tables, il est possible d'atteindre cette limite.
**Action recommandée :**
+ La réduction de la valeur du paramètre `max_files_per_process` peut contribuer à atténuer cette erreur. Chaque processus et sous-processus (par exemple, une requête parallèle) peut ouvrir ce nombre de fichiers, et si les requêtes joignent plusieurs tables, cette limite peut être dépassée.
+ Réduisez le nombre total de connexions et utilisez un pool de connexions tel qu'[Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) ou d'autres solutions telles que. PgBouncer Pour en savoir plus, consultez le [PgBouncer site Web](https://www.pgbouncer.org/).
**Impact : épuisement des inodes**
Erreur : « Il ne reste plus d'espace sur l'appareil ». Si cela se produit alors qu'il y a suffisamment d'espace libre de stockage, cela est dû au manque d'inodes. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) fournit une visibilité sur les inodes utilisés et sur le nombre maximum d'inodes disponibles pour votre hôte.
**Bonnes pratiques générales :**
+ Surveillez l'utilisation de vos fichiers temporaires avec [Performance Insights ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
+ Réglez les requêtes qui génèrent des fichiers temporaires importants pour voir s'il est possible de réduire le nombre total de fichiers temporaires.
**Seuil approximatif :** en [milliers](#PostgreSQL.HighObjectCount.Note)
## Séquences
Les séquences sont l'objet sous-jacent utilisé pour l'auto-incrémentation des colonnes dans PostgreSQL. Elles fournissent l'unicité et une clé pour les données. Ils peuvent être utilisés sur des tables individuelles sans aucune conséquence lors des opérations normales, à l'exception de la réplication logique.
Dans PostgreSQL, la réplication logique ne réplique actuellement la valeur actuelle d'une séquence vers aucun abonné. Pour en savoir plus, consultez la [page Restrictions de la documentation de PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html).
**Conséquence : délai de transition prolongé**
Si vous envisagez d'utiliser [les Blue/Green déploiements d'Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) pour tout type de modification ou de mise à niveau de configuration, il est important de comprendre l'impact d'un grand nombre de séquences sur le passage au numérique. L'une des dernières phases d'une commutation synchronisera la valeur actuelle des séquences, et s'il y en a plusieurs milliers, cela augmentera le temps global de commutation.
**Action recommandée :** Si la charge de travail de votre base de données autorisait l'utilisation d'un UUID partagé au lieu d'une sequence-per-table approche, cela réduirait l'étape de synchronisation lors d'un basculement.
**Seuil approximatif :** en [milliers](#PostgreSQL.HighObjectCount.Note)
## Objets volumineux
Les objets de grande taille sont stockés dans une seule table système nommée pg\$1largeobject. Chaque objet de grande taille possède également une entrée dans la table système pg\$1largeobject\$1metadata. Ces objets sont créés, modifiés et nettoyés de manière très différente des relations standard. Les objets volumineux ne sont pas manipulés par autovacuum et doivent être nettoyés périodiquement via un processus distinct appelé vacuumlo. Voir gestion d'objets volumineux avec le module lo pour des exemples de gestion d'objets de grande taille.
**Conséquence : réplication logique**
Les objets volumineux ne sont actuellement pas répliqués dans PostgreSQL lors de la réplication logique. Pour en savoir plus, consultez la [page Restrictions de la documentation de PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). Dans une configuration [bleu/vert](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) , cela signifie que les objets volumineux de l'environnement bleu ne sont pas répliqués dans l'environnement vert.
**Conséquence : mise à niveau de la version majeure**
Une mise à niveau peut manquer de mémoire et échouer s'il existe des millions d'objets volumineux et que l'instance ne peut pas les gérer pendant une mise à niveau. Le processus de mise à niveau de la version majeure de PostgreSQL comprend deux grandes phases : le vidage du schéma via pg\$1dump et sa restauration via pg\$1restore. Si votre base de données contient des millions d'objets volumineux, vous devez vous assurer que votre instance dispose de suffisamment de mémoire pour gérer les fichiers pg\$1dump et pg\$1restore lors d'une mise à niveau et pour les adapter à un type d'instance plus important.
**Bonnes pratiques générales :**
+ Utilisez régulièrement l'utilitaire vacuumlo pour retirer tous les gros objets orphelins que vous pourriez avoir.
+ Envisagez d'utiliser le type de données BYTEA pour stocker vos objets volumineux dans la base de données.
**Seuil approximatif :** [millions](#PostgreSQL.HighObjectCount.Note)
## Seuils approximatifs
Les seuils approximatifs mentionnés dans cette rubrique ne sont utilisés que pour fournir une estimation de la mesure dans laquelle une ressource donnée peut évoluer. Ils représentent la plage générale dans laquelle les impacts décrits sont les plus probables, mais le comportement réel dépend de votre charge de travail, de la taille de l'instance et de la configuration spécifiques. Bien qu'il soit possible de dépasser ces estimations, le soin et l'entretien doivent être respectés afin d'éviter les impacts énumérés.
#
TOAST (The Oversized-Attribute Storage Technique) est une fonctionnalité de PostgreSQL conçue pour gérer de grandes valeurs de données dépassant la taille de bloc de base de données habituelle de 8 Ko. PostgreSQL n'autorise pas les lignes physiques à s'étendre sur plusieurs blocs. La taille du bloc agit comme une limite supérieure de la taille des lignes. TOAST surmonte cette restriction en divisant les grandes valeurs de champs en plus petits morceaux. Il les stocke séparément dans une table TOAST dédiée liée à la table principale. Pour plus d'informations, consultez le [mécanisme de stockage TOAST de PostgreSQL](https://www.postgresql.org/docs/current/storage-toast.html) et la documentation d'implémentation.
**Topics**
+ [
## Comprendre les opérations de TOAST
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.HowWorks)
+ [
## Identifier les défis en matière de performance
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.PerformanceChallenges)
+ [
## Recommandations
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Recommendations)
+ [
## Contrôle
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Monitoring)
## Comprendre les opérations de TOAST
TOAST effectue la compression et stocke de grandes valeurs de champ hors ligne. TOAST attribue un OID (identifiant d'objet) unique à chaque bloc de données surdimensionné stocké dans la table TOAST. La table principale stocke l'ID de valeur TOAST et l'ID de relation sur la page pour référencer la ligne correspondante dans la table TOAST. Cela permet à PostgreSQL de localiser et de gérer efficacement ces fragments TOAST. Cependant, au fur et à mesure que la table TOAST s'allonge, le système risque d'épuiser le stock disponible OIDs, ce qui entraîne à la fois une dégradation des performances et des temps d'arrêt potentiels dus à l'épuisement de l'OID.
### Identifiants d'objets dans TOAST
Un identifiant d'objet (OID) est un identifiant unique à l'échelle du système utilisé par PostgreSQL pour référencer des objets de base de données tels que des tables, des index et des fonctions. Ces identifiants jouent un rôle essentiel dans les opérations internes de PostgreSQL, car ils permettent à la base de données de localiser et de gérer efficacement les objets.
Pour les tables contenant des ensembles de données éligibles au toasting, PostgreSQL OIDs attribue une identification unique à chaque bloc de données surdimensionné stocké dans la table TOAST associée. Le système associe chaque fragment à un`chunk_id`, ce qui permet à PostgreSQL d'organiser et de localiser efficacement ces fragments dans la table TOAST.
## Identifier les défis en matière de performance
La gestion des OID de PostgreSQL repose sur un compteur global de 32 bits, de sorte qu'il fonctionne après avoir généré 4 milliards de valeurs uniques. Bien que le cluster de base de données partage ce compteur, l'allocation d'OID implique deux étapes lors des opérations TOAST :
+ **Compteur global pour l'allocation** : le compteur global attribue un nouvel OID à l'ensemble du cluster.
+ **Recherche locale de conflits** — La table TOAST garantit que le nouvel OID n'entre pas en conflit avec l'OID OIDs déjà utilisé dans cette table spécifique.
Une dégradation des performances peut se produire lorsque :
+ La table TOAST présente une fragmentation élevée ou une utilisation dense des OID, ce qui entraîne des retards dans l'attribution de l'OID.
+ Le système alloue et réutilise fréquemment des données OIDs dans des environnements présentant un taux de perte de données élevé ou de larges tables utilisant largement TOAST.
Pour plus d'informations, consultez la documentation relative aux [limites de taille des tables TOAST de PostgreSQL et](https://wiki.postgresql.org/wiki/TOAST#Total_table_size_limit) à l'allocation d'OID :
Un compteur global génère des valeurs OIDs et les englobe tous les 4 milliards, de sorte que le système génère à nouveau de temps en temps une valeur déjà utilisée. PostgreSQL le détecte et réessaie avec l'OID suivant. Un INSERT lent peut se produire s'il y a une très longue série de valeurs OID utilisées sans interruption dans la table TOAST. Ces difficultés s'accentuent à mesure que l'espace OID se remplit, ce qui ralentit les insertions et les mises à jour.
### Identifier le problème
+ `INSERT`Les instructions simples prennent beaucoup plus de temps que d'habitude de manière incohérente et aléatoire.
+ Les retards se produisent uniquement pour `INSERT` les `UPDATE` déclarations impliquant des opérations TOAST.
+ Les entrées de journal suivantes apparaissent dans les journaux PostgreSQL lorsque le système peine à les trouver dans les tables TOAST OIDs :
```
LOG: still searching for an unused OID in relation "pg_toast_20815"
DETAIL: OID candidates have been checked 1000000 times, but no unused OID has been found yet.
```
+ Performance Insights indique un nombre élevé de sessions actives (AAS) moyennes associées à des événements `LWLock:buffer_io` et à des événements `LWLock:OidGenLock` d'attente.
Vous pouvez exécuter la requête SQL suivante pour identifier les transactions INSERT de longue durée associées à des événements d'attente :
```
SELECT
datname AS database_name,
usename AS database_user,
pid,
now() - pg_stat_activity.xact_start AS transaction_duration,
concat(wait_event_type, ':', wait_event) AS wait_event,
substr(query, 1, 30) AS TRANSACTION,
state
FROM
pg_stat_activity
WHERE (now() - pg_stat_activity.xact_start) > INTERVAL '60 seconds'
AND state IN ('active', 'idle in transaction', 'idle in transaction (aborted)', 'fastpath function call', 'disabled')
AND pid <> pg_backend_pid()
AND lower(query) LIKE '%insert%'
ORDER BY
transaction_duration DESC;
```
Exemples de résultats de requête affichant des opérations INSERT avec des temps d'attente prolongés :
```
database_name | database_user | pid | transaction_duration | wait_event | transaction | state
---------------+-----------------+-------+----------------------+---------------------+--------------------------------+--------
postgres | db_admin_user| 70965 | 00:10:19.484061 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 69878 | 00:06:14.976037 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 68937 | 00:05:13.942847 | : | INSERT INTO "products" (......... | active
```
### Isoler le problème
+ **Test small insert** — Insérez un enregistrement inférieur au `toast_tuple_target` seuil. N'oubliez pas que la compression est appliquée avant le stockage de TOAST. Si cela fonctionne sans problèmes de performances, le problème est lié aux opérations TOAST.
+ **Tester une nouvelle table** — Créez une nouvelle table avec la même structure et insérez un enregistrement supérieur à`toast_tuple_target`. Si cela fonctionne sans problème, le problème est localisé dans l'allocation OID de la table d'origine.
## Recommandations
Les approches suivantes peuvent aider à résoudre les problèmes de contention des OID TOAST.
+ **Nettoyage et archivage des données** : passez en revue et supprimez toutes les données obsolètes ou inutiles afin de OIDs les libérer pour une utilisation future, ou archivez-les. Prenez en compte les restrictions suivantes :
+ Évolutivité limitée, car le nettoyage futur ne sera peut-être pas toujours possible.
+ Possibilité d'une opération VACUUM de longue durée pour éliminer les tuples morts qui en résultent.
+ **Écrire dans une nouvelle table** : créez une nouvelle table pour les futures insertions et utilisez une `UNION ALL` vue pour combiner les anciennes et les nouvelles données pour les requêtes. Cette vue présente les données combinées des anciennes et des nouvelles tables, ce qui permet aux requêtes d'y accéder sous la forme d'une seule table. Prenez en compte les restrictions suivantes :
+ Les mises à jour de l'ancienne table risquent tout de même d'entraîner l'épuisement de l'OID.
+ **Partition ou partition** : partitionnez les données de la table ou de la partition pour améliorer l'évolutivité et les performances. Prenez en compte les restrictions suivantes :
+ Complexité accrue de la logique des requêtes et de la maintenance, nécessité potentielle de modifier les applications pour gérer correctement les données partitionnées.
## Contrôle
### Utilisation des tables du système
Vous pouvez utiliser les tables système de PostgreSQL pour surveiller l'augmentation de l'utilisation des OID.
**Avertissement**
Selon le nombre de personnes figurant OIDs dans le tableau TOAST, le processus peut prendre un certain temps. Nous vous recommandons de planifier la surveillance en dehors des heures de bureau afin de minimiser l'impact.
Le bloc anonyme suivant compte le nombre de caractères distincts OIDs utilisés dans chaque table TOAST et affiche les informations de la table parent :
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the number of distinct used OIDs (chunk IDs) from the TOAST table
EXECUTE 'SELECT COUNT(DISTINCT chunk_id) FROM ' || r.toast_table INTO o;
-- If there are used OIDs, find the associated parent table and its schema
IF o <> 0 THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Number of used OIDs: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Exemple de sortie affichant les statistiques d'utilisation des OID par table TOAST :
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Number of used OIDs: 45,623,317
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Number of used OIDs: 10,000
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Number of used OIDs: 1,000,000
DO
```
Le bloc anonyme suivant récupère l'OID maximal attribué pour chaque table TOAST non vide :
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the max(chunk_id) from the TOAST table
EXECUTE 'SELECT max(chunk_id) FROM ' || r.toast_table INTO o;
-- If there's at least one TOASTed chunk, find the associated parent table and its schema
IF o IS NOT NULL THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Max chunk_id: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Exemple de sortie affichant la partie maximale IDs pour les tables TOAST :
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Max chunk_id: 45,639,907
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Max chunk_id: 45,649,929
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Max chunk_id: 46,649,935
DO
```
### Utilisation de l'Analyse des performances
Les événements `LWLock:buffer_io` d'attente `LWLock:OidGenLock` apparaissent dans Performance Insights lors d'opérations nécessitant l'attribution de nouveaux identifiants d'objet ()OIDs. Les sessions actives à moyenne élevée (AAS) associées à ces événements indiquent généralement des conflits lors de l'attribution des OID et de la gestion des ressources. Cela est particulièrement courant dans les environnements caractérisés par une perte de données élevée, une utilisation importante de données ou une création d'objets fréquente.
#### LWLock:buffer\$1io
`LWLock:buffer_io`est un événement d'attente qui se produit lorsqu'une session PostgreSQL attend la fin I/O des opérations sur une mémoire tampon partagée. Cela se produit généralement lorsque la base de données lit les données du disque dans la mémoire ou écrit des pages modifiées de la mémoire sur le disque. L'événement `BufferIO` d'attente garantit la cohérence en empêchant plusieurs processus d'accéder à la même mémoire tampon ou de la modifier pendant que les I/O opérations sont en cours. La fréquence élevée de cet événement d'attente peut indiquer un engorgement du disque ou une I/O activité excessive de la charge de travail de la base de données.
Pendant les opérations TOAST :
+ PostgreSQL OIDs alloue des fonds aux objets volumineux et garantit leur unicité en analysant l'index de la table TOAST.
+ Les grands index TOAST peuvent nécessiter l'accès à plusieurs pages pour vérifier l'unicité de l'OID. Cela entraîne une augmentation des E/S sur le disque, en particulier lorsque le pool de mémoire tampon ne peut pas mettre en cache toutes les pages requises.
La taille de l'index influe directement sur le nombre de pages tampon auxquelles il est nécessaire d'accéder au cours de ces opérations. Même si l'indice n'est pas gonflé, sa taille même peut augmenter les E/S de la mémoire tampon, en particulier dans les environnements à forte concurrence ou à taux de désabonnement élevé. Pour plus d'informations, consultez : Guide de résolution des problèmes liés aux [événements d'LWLockattente](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.lwlockbufferio.html) BufferIO.
#### LWLock:OidGenLock
`OidGenLock`est un événement d'attente qui se produit lorsqu'une session PostgreSQL attend d'allouer un nouvel identifiant d'objet (OID). Ce verrou garantit qu' OIDs ils sont générés de manière séquentielle et sûre, en ne permettant de générer qu'un seul processus OIDs à la fois.
Pendant les opérations TOAST :
+ **Allocation d'OID pour les segments dans les tables TOAST** : PostgreSQL les OIDs affecte aux segments des tables TOAST lors de la gestion d'enregistrements de données volumineux. Chaque OID doit être unique pour éviter les conflits dans le catalogue système.
+ **Haute simultanéité** : l'accès au générateur d'OID étant séquentiel, des conflits peuvent survenir lorsque plusieurs sessions créent simultanément des objets qui en ont besoin OIDs. `OidGenLock` Cela augmente la probabilité que les sessions attendent la fin de l'allocation des OID.
+ **Dépendance à l'égard de l'accès au catalogue du système** : l'allocation OIDs nécessite des mises à jour des tables de catalogue système partagées, telles que `pg_class` et`pg_type`. Si ces tables sont soumises à une activité intense (en raison de fréquentes opérations DDL), cela peut augmenter le nombre de conflits de verrouillage pour. `OidGenLock`
+ **Demande d'allocation d'OID élevée** — Les charges de travail lourdes de TOAST associées à des enregistrements de données volumineux nécessitent une allocation d'OID constante, ce qui augmente les contentions.
Facteurs supplémentaires qui augmentent la contention des OID :
+ **Création fréquente d'objets** : les charges de travail qui créent et suppriment fréquemment des objets, tels que des tables temporaires, amplifient la contention sur le compteur d'OID global.
+ **Verrouillage global du compteur** : le compteur OID global est accessible en série pour garantir l'unicité, créant ainsi un point de conflit unique dans les environnements à forte simultanéité.
## Utilisation de mécanismes de journalisation pris en charge par RDS pour PostgreSQL
Il existe plusieurs paramètres, extensions et autres éléments configurables que vous pouvez définir pour journaliser les activités qui se produisent sur votre instance de base de données PostgreSQL. Cela inclut les éléments suivants :
+ Le paramètre`log_statement` peut être utilisé pour consigner l'activité utilisateur dans votre base de données PostgreSQL. Pour en savoir plus sur la journalisation RDS pour PostgreSQL et sur la façon de surveiller les journaux, consultez [Fichiers journaux de base de données RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md).
+ Le paramètre `rds.force_admin_logging_level` journalise les actions effectuées par l'utilisateur interne Amazon RDS (rdsadmin) dans les bases de données sur l'instance de base de données. Il écrit la sortie dans le journal d'erreurs PostgreSQL. Les valeurs autorisées sont `disabled`, `debug5`, `debug4`, `debug3`, `debug2`, `debug1`, `info`, `notice`, `warning`, `error`, journal,`fatal` et `panic`. La valeur par défaut est `disabled`.
+ Le paramètre `rds.force_autovacuum_logging_level` peut être configuré pour capturer diverses opérations d'autovacuum dans le journal des erreurs PostgreSQL. Pour de plus amples informations, veuillez consulter [Enregistrement des activités d'autovacuum et de vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md).
+ L'extension PostgreSQL Audit (pgAudit) peut être installée et configurée pour capturer des activités au niveau de la session ou au niveau de l'objet. Pour de plus amples informations, veuillez consulter [Utilisation de pgAudit pour journaliser l'activité de la base de données](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ L'extension `log_fdw` vous permet d'accéder au journal du moteur de base de données à l'aide de SQL. Pour de plus amples informations, veuillez consulter [Utilisation de l'extension log\$1fdw pour accéder au journal de base de données à l'aide de SQL](CHAP_PostgreSQL.Extensions.log_fdw.md).
+ La bibliothèque `pg_stat_statements` est spécifiée par défaut pour le paramètre `shared_preload_libraries` dans RDS pour PostgreSQL 10 et versions ultérieures. C'est cette bibliothèque que vous pouvez utiliser pour analyser les requêtes en cours d'exécution. Assurez-vous que `pg_stat_statements` est défini dans votre groupe de paramètres de base de données. Pour plus d’informations sur la surveillance de votre instance de base de données RDS pour PostgreSQL à l’aide des informations fournies par cette bibliothèque, consultez [Statistiques SQL pour RDS PostgreSQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.md).
+ Le paramètre `log_hostname` capture dans le journal le nom d'hôte de chaque connexion client. Pour RDS pour PostgreSQL versions 12 et ultérieures, ce paramètre est défini sur `off` par défaut. Si vous l'activez, veillez à surveiller les temps de connexion des sessions. Lorsqu'il est activé, le service utilise la demande de recherche inversée DNS pour obtenir le nom d'hôte du client qui établit la connexion et pour l'ajouter au journal PostgreSQL. Cela a un impact notable au cours de la connexion à la session. Nous vous recommandons d'activer ce paramètre à des fins de dépannage uniquement.
D'une manière générale, le but de la journalisation est de permettre au DBA de surveiller, d'ajuster les performances et de résoudre les problèmes. La plupart des journaux sont chargés automatiquement sur Amazon CloudWatch ou Performance Insights. Ici, ils sont triés et regroupés pour fournir des métriques complètes pour votre instance de base de données. Pour en savoir plus sur la surveillance et les métriques d’Amazon RDS, consultez [Surveillance des métriques dans une instance Amazon RDS](CHAP_Monitoring.md).
# Gestion des fichiers temporaires avec PostgreSQL
Dans PostgreSQL, une requête complexe peut exécuter simultanément plusieurs opérations de tri ou de hachage, chacune utilisant la mémoire de l’instance pour stocker les résultats jusqu’à la valeur spécifiée par le paramètre [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Lorsque la mémoire de l’instance n’est pas suffisante, des fichiers temporaires sont créés pour stocker les résultats. Ils sont écrits sur le disque pour terminer l’exécution de la requête. Par la suite, ces fichiers sont automatiquement supprimés une fois la requête terminée. Dans RDS pour PostgreSQL, ces fichiers sont stockés dans Amazon EBS sur le volume de données. Pour plus d’informations, consultez [Stockage d’instance de base de données Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html). Vous pouvez surveiller la `FreeStorageSpace` métrique publiée dans CloudWatch pour vous assurer que votre instance de base de données dispose de suffisamment d'espace de stockage disponible. Pour plus d’informations, consultez [https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm](https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm).
Nous recommandons d’utiliser des instances Lectures optimisées pour Amazon RDS pour les charges de travail impliquant plusieurs requêtes simultanées qui augmentent l’utilisation de fichiers temporaires. Ces d'instances utilisent un stockage local au niveau des blocs basé sur un disque SSD (Non-Volatile Memory Express) pour placer les fichiers temporaires. NVMe Pour de plus amples informations, veuillez consulter [Amélioration des performances des requêtes pour RDS pour PostgreSQL avec Lectures optimisées pour Amazon RDS](USER_PostgreSQL.optimizedreads.md).
Vous pouvez utiliser les paramètres et fonctions suivants pour gérer les fichiers temporaires dans votre instance.
+ **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** : ce paramètre annule toute requête dépassant la taille des fichiers temp\$1files en Ko. Cette limite empêche toute requête de s’exécuter indéfiniment et de consommer de l’espace disque avec des fichiers temporaires. Vous pouvez estimer la valeur à l’aide des résultats du paramètre `log_temp_files`. Nous vous recommandons d’examiner le comportement de la charge de travail et de définir la limite en fonction de l’estimation. L’exemple suivant présente la manière dont une requête est annulée lorsqu’elle dépasse la limite.
```
postgres=>select * from pgbench_accounts, pg_class, big_table;
```
```
ERROR: temporary file size exceeds temp_file_limit (64kB)
```
+ **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** : ce paramètre envoie des messages au fichier postgresql.log lorsque les fichiers temporaires d’une session sont supprimés. Ce paramètre produit des journaux lorsqu’une requête est terminée avec succès. Par conséquent, cela peut ne pas aider à résoudre les requêtes actives et de longue durée.
L’exemple suivant montre que lorsque la requête aboutit, les entrées sont journalisées dans le fichier postgresql.log pendant que les fichiers temporaires sont nettoyés.
```
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
```
+ **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** : cette fonction disponible auprès de RDS pour PostgreSQL versions 13 et ultérieures offre une visibilité sur l’utilisation actuelle des fichiers temporaires. La requête terminée n’apparaît pas dans les résultats de la fonction. Dans l’exemple suivant, vous pouvez visualiser les résultats de cette fonction.
```
postgres=>select * from pg_ls_tmpdir();
```
```
name | size | modification
-----------------+------------+------------------------
pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00
pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00
pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00
pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00
pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00
(7 rows)
```
```
postgres=>select query from pg_stat_activity where pid = 8355;
query
----------------------------------------------------------------------------------------
select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid
(1 row)
```
Le nom du fichier inclut l’ID de traitement (PID) de la session qui a généré le fichier temporaire. Une requête plus avancée, comme dans l’exemple suivant, effectue la somme des fichiers temporaires pour chaque PID.
```
postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid;
```
```
pid | count | sum
------+-------------------
8355 | 2 | 2144501760
8351 | 2 | 2090770432
8327 | 1 | 1072250880
8328 | 2 | 2144501760
(4 rows)
```
+ **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** : si vous activez le paramètre pg\$1stat\$1statements, vous pouvez consulter l’utilisation moyenne des fichiers temporaires par appel. Vous pouvez identifier le query\$1id de la requête et l’utiliser pour examiner l’utilisation des fichiers temporaires, comme indiqué dans l’exemple suivant.
```
postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%';
```
```
queryid
----------------------
-7170349228837045701
(1 row)
```
```
postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701;
```
```
queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call
----------------------+---------------------------+-------+-------------------------+----------------------------
-7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678
(1 row)
```
+ **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`** : dans le tableau de bord Performance Insights, vous pouvez consulter l’utilisation des fichiers temporaires en activant les métriques **temp\$1bytes** et **temp\$1files**. Vous pouvez ensuite voir la moyenne de ces deux métriques et voir comment elles correspondent à la charge de travail des requêtes. La vue de Performance Insights n’affiche pas spécifiquement les requêtes qui génèrent les fichiers temporaires. Toutefois, lorsque vous associez Performance Insights à la requête indiquée pour `pg_ls_tmpdir`, vous pouvez dépanner, analyser et déterminer les modifications apportées à la charge de travail de vos requêtes.
Pour plus d’informations sur l’analyse des métriques et des requêtes à l’aide de Performance Insights, consultez [Analyse des métriques à l’aide du tableau de bord de Performance Insights](USER_PerfInsights.UsingDashboard.md).
Pour consulter un exemple d’utilisation des fichiers temporaires avec Performance Insights, consultez [Affichage de l’utilisation des fichiers temporaires avec Performance Insights](PostgreSQL.ManagingTempFiles.Example.md)
# Affichage de l’utilisation des fichiers temporaires avec Performance Insights
Vous pouvez consulter utiliser Performance Insights pour afficher l’utilisation des fichiers temporaires en activant les métriques **temp\$1bytes** et **temp\$1files**. La vue indiquée dans Performance Insights ne montre pas les requêtes spécifiques qui génèrent des fichiers temporaires. Toutefois, lorsque vous associez Performance Insights à la requête affichée pour `pg_ls_tmpdir`, vous pouvez dépanner, analyser et déterminer les modifications apportées à la charge de travail de vos requêtes.
1. Dans le tableau de bord de Performance Insights, choisissez **Gérer les métriques**.
1. Choisissez **Métriques de base de données** et sélectionnez les métriques **temp\$1bytes** et **temp\$1files** comme indiqué dans l’image suivante.
![\[Métriques affichées dans le graphique.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_metrics.png)
1. Dans l’onglet **SQL maximum**, cliquez sur l’icône **Préférences**.
1. Dans la fenêtre **Préférences**, activez les statistiques suivantes pour qu’elles apparaissent dans l’onglet **SQL maximum** et choisissez **Continuer**.
+ Nombre d’écritures temporaires/seconde
+ Nombre de lectures temporaires/seconde
+ Écritures/appels en bloc temporaires
+ Lectures/appels en bloc temporaires
1. Le fichier temporaire est décomposé lorsqu’il est associé à la requête affichée pour `pg_ls_tmpdir`, comme le montre l’exemple suivant.
![\[Requête qui affiche l’utilisation du fichier temporaire.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_query.png)
Les événements `IO:BufFileRead` et `IO:BufFileWrite` se produisent lorsque les requêtes les plus importantes de votre charge de travail créent souvent des fichiers temporaires. Vous pouvez utiliser l’analyse des performances pour identifier les requêtes les plus importantes en attente sur `IO:BufFileRead` et `IO:BufFileWrite` en passant en revue Sessions actives en moyenne (AAS) dans les sections Charge de base de données et Principaux éléments SQL.
![\[IO : BufFileRead et IO : BufFileWrite dans le graphique.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/perfinsights_IOBufFile.png)
Pour plus d’informations sur la façon d’analyser les requêtes les plus importantes et la charge par événement d’attente à l’aide de l’analyse des performances, consultez [Présentation de l'onglet Top SQL (Principaux éléments SQL)](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Vous devez identifier et ajuster les requêtes qui entraînent une augmentation de l’utilisation des fichiers temporaires et des événements d’attente associés. Pour plus d'informations sur ces événements d'attente et les mesures correctives, voir [IO : BufFileRead et IO : BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.iobuffile.html) .
**Note**
Le paramètre [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) contrôle le moment où la mémoire de l’opération de tri est insuffisante et les résultats sont écrits dans des fichiers temporaires. Nous vous recommandons de ne pas modifier la valeur de ce paramètre au-delà de la valeur par défaut, car cela permettrait à chaque session de base de données de consommer davantage de mémoire. En outre, une session unique qui effectue des jointures et des tris complexes peut effectuer des opérations parallèles au cours desquelles chaque opération consomme de la mémoire.
Il est recommandé de définir ce paramètre au niveau de la session à l’aide de la commande `SET work_mem` lorsque vous disposez d’un rapport volumineux comportant plusieurs jointures et tris. La modification n’est alors appliquée qu’à la session en cours et ne modifie pas la valeur de manière globale.
## Utilisation de pgBadger pour l'analyse de journal serveur avec PostgreSQL
Vous pouvez utiliser un analyseur de journaux tel que [pgBadger](http://dalibo.github.io/pgbadger/) pour analyser les journaux PostgreSQL. La documentation pgBadger indique que le motif %l (ligne de journal pour la session ou le processus) doit faire partie du préfixe. Cependant, si vous fournissez le `log_line_prefix` RDS actuel en tant que paramètre à pgBadger, il devrait quand même produire un rapport.
Par exemple, la commande suivante formate correctement un fichier journal Amazon RDS pour PostgreSQL daté du 04/02/2014 à l’aide de pgBadger.
```
./pgbadger -f stderr -p '%t:%r:%u@%d:[%p]:' postgresql.log.2014-02-04-00
```
## Utilisation PGSnapper pour la surveillance de PostgreSQL
Vous pouvez l'utiliser PGSnapper pour faciliter la collecte périodique de statistiques et de mesures relatives aux performances d'Amazon RDS for PostgreSQL. Pour plus d'informations, consultez [Surveiller les performances d'Amazon RDS for PostgreSQL à l'aide de](https://aws.amazon.com/blogs/database/monitor-amazon-rds-for-postgresql-and-amazon-aurora-postgresql-performance-using-pgsnapper/). PGSnapper
#
**Le casting de type** dans PostgreSQL est le processus de conversion d'une valeur d'un type de données à un autre. PostgreSQL fournit des conversions intégrées pour de nombreuses conversions courantes, mais vous pouvez également créer des conversions personnalisées pour définir le comportement de conversions de type spécifique.
Un cast indique comment effectuer une conversion d'un type de données à un autre. Par exemple, convertir du texte `'123'` en entier `123` ou un nombre numérique `45.67` en texte`'45.67'`.
Pour obtenir des informations complètes sur les concepts et la syntaxe de PostgreSQL Cast, consultez la documentation [PostgreSQL](https://www.postgresql.org/docs/current/sql-createcast.html) CREATE CAST.
À partir des , vous pouvez utiliser l'extension rds\$1casts pour installer des conversions supplémentaires pour les types intégrés, tout en étant en mesure de créer vos propres conversions pour les types personnalisés.
**Topics**
+ [
## Installation et utilisation de l'extension rds\$1casts
](#PostgreSQL.CustomCasts.Installing)
+ [
## Castings pris en charge
](#PostgreSQL.CustomCasts.Supported)
+ [
## Création ou suppression de moulages
](#PostgreSQL.CustomCasts.Creating)
+ [
## Création de moulages personnalisés avec une stratégie contextuelle appropriée
](#PostgreSQL.CustomCasts.BestPractices)
## Installation et utilisation de l'extension rds\$1casts
Pour créer l'`rds_casts`extension, connectez-vous à (votre instance de base de données RDS pour PostgreSQL en tant que telle) et exécutez la commande suivante : `rds_superuser`
```
CREATE EXTENSION IF NOT EXISTS rds_casts;
```
## Castings pris en charge
Créez l'extension dans chaque base de données dans laquelle vous souhaitez utiliser des moulages personnalisés. Après avoir créé l'extension, utilisez la commande suivante pour afficher tous les casts disponibles :
```
SELECT * FROM rds_casts.list_supported_casts();
```
Cette fonction répertorie les combinaisons de diffusion disponibles (type de source, type de cible, contexte de coercition et fonction de diffusion). Par exemple, si vous souhaitez le `text` créer en `numeric` tant que `implicit` casting. Vous pouvez utiliser la requête suivante pour savoir si le casting est disponible pour être créé :
```
SELECT * FROM rds_casts.list_supported_casts()
WHERE source_type = 'text' AND target_type = 'numeric';
id | source_type | target_type | qualified_function | coercion_context
----+-------------+-------------+--------------------------------------+------------------
10 | text | numeric | rds_casts.rds_text_to_numeric_custom | implicit
11 | text | numeric | rds_casts.rds_text_to_numeric_custom | assignment
13 | text | numeric | rds_casts.rds_text_to_numeric_custom | explicit
20 | text | numeric | rds_casts.rds_text_to_numeric_inout | implicit
21 | text | numeric | rds_casts.rds_text_to_numeric_inout | assignment
23 | text | numeric | rds_casts.rds_text_to_numeric_inout | explicit
```
L'extension rds\$1casts fournit deux types de fonctions de conversion pour chaque cast :
+ *Fonctions \$1inout* - Utilisez le mécanisme de I/O conversion standard de PostgreSQL, en se comportant de la même manière que les conversions créées avec la méthode INOUT
+ *\$1custom functions* - Fournissez une logique de conversion améliorée qui gère les cas extrêmes, tels que la conversion de chaînes vides en valeurs NULL pour éviter les erreurs de conversion
Les `inout` fonctions reproduisent le comportement de casting natif de PostgreSQL, tandis que les `custom` fonctions étendent cette fonctionnalité en gérant des scénarios que les conversions INOUT standard ne peuvent pas prendre en charge, tels que la conversion de chaînes vides en entiers.
## Création ou suppression de moulages
Vous pouvez créer et supprimer des diffusions prises en charge à l'aide de deux méthodes :
### Création du casting
**Méthode 1 : utilisation de la commande native CREATE CAST**
```
CREATE CAST (text AS numeric)
WITH FUNCTION rds_casts.rds_text_to_numeric_custom
AS IMPLICIT;
```
**Méthode 2 : utilisation de la fonction rds\$1casts.create\$1cast**
```
SELECT rds_casts.create_cast(10);
```
La `create_cast` fonction prend l'identifiant de la `list_supported_casts()` sortie. Cette méthode est plus simple et garantit que vous utilisez la bonne combinaison de fonction et de contexte. Il est garanti que cet identifiant restera le même dans les différentes versions de Postgres.
Pour vérifier que le cast a bien été créé, interrogez le catalogue du système pg\$1cast :
```
SELECT oid, castsource::regtype, casttarget::regtype, castfunc::regproc, castcontext, castmethod
FROM pg_cast
WHERE castsource = 'text'::regtype AND casttarget = 'numeric'::regtype;
oid | castsource | casttarget | castfunc | castcontext | castmethod
--------+------------+------------+--------------------------------------+-------------+------------
356372 | text | numeric | rds_casts.rds_text_to_numeric_custom | i | f
```
La `castcontext` colonne indique : `e` pour EXPLICIT, `a` pour ASSIGNMENT ou `i` pour IMPLICIT.
### Lancer des moulages
**Méthode 1 : utilisation de la commande DROP CAST**
```
DROP CAST IF EXISTS (text AS numeric);
```
**Méthode 2 : utilisation de la fonction rds\$1casts.drop\$1cast**
```
SELECT rds_casts.drop_cast(10);
```
La `drop_cast` fonction utilise le même identifiant que celui utilisé lors de la création du casting. Cette méthode garantit que vous supprimez le casting exact créé avec l'ID correspondant.
## Création de moulages personnalisés avec une stratégie contextuelle appropriée
Lors de la création de plusieurs conversions pour des types entiers, des erreurs d'ambiguïté d'opérateur peuvent se produire si toutes les conversions sont créées en tant que valeur IMPLICITE. L'exemple suivant illustre ce problème en créant deux conversions implicites à partir du texte en différentes largeurs de nombres entiers :
```
-- Creating multiple IMPLICIT casts causes ambiguity
postgres=> CREATE CAST (text AS int4) WITH FUNCTION rds_casts.rds_text_to_int4_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE CAST (text AS int8) WITH FUNCTION rds_casts.rds_text_to_int8_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE TABLE test_cast(col int);
CREATE TABLE
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
ERROR: operator is not unique: integer = text
LINE 1: SELECT * FROM test_cast WHERE col='123'::text;
^
HINT: Could not choose a best candidate operator. You might need to add explicit type casts.
```
L'erreur se produit parce que PostgreSQL ne peut pas déterminer la conversion implicite à utiliser lors de la comparaison d'une colonne entière avec une valeur de texte. Les conversions implicites int4 et int8 sont des candidats valides, ce qui crée une ambiguïté.
Pour éviter cette ambiguïté d'opérateur, utilisez le contexte ASSIGNMENT pour les largeurs entières plus petites et le contexte IMPLICITE pour les largeurs entières plus grandes :
```
-- Use ASSIGNMENT for smaller integer widths
CREATE CAST (text AS int2)
WITH FUNCTION rds_casts.rds_text_to_int2_custom(text)
AS ASSIGNMENT;
CREATE CAST (text AS int4)
WITH FUNCTION rds_casts.rds_text_to_int4_custom(text)
AS ASSIGNMENT;
-- Use IMPLICIT for larger integer widths
CREATE CAST (text AS int8)
WITH FUNCTION rds_casts.rds_text_to_int8_custom(text)
AS IMPLICIT;
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
col
-----
123
(1 row)
```
Avec cette stratégie, seul le cast int8 est implicite, de sorte que PostgreSQL peut déterminer sans ambiguïté le cast à utiliser.
# Meilleures pratiques pour les requêtes parallèles dans pour PostgreSQL
L'exécution parallèle de requêtes est une fonctionnalité de PostgreSQL qui permet de diviser une seule requête SQL en tâches plus petites traitées simultanément par plusieurs processus de travail en arrière-plan. Au lieu d'exécuter une requête entièrement dans un seul processus principal, PostgreSQL peut répartir certaines parties de la requête, telles que les scans, les jointures, les agrégations ou le tri, sur plusieurs cœurs de processeur. Le *processus leader* coordonne cette exécution et recueille les résultats auprès des *travailleurs parallèles*.
Toutefois, pour la plupart des charges de travail de production, en particulier les systèmes OLTP à haute simultanéité, nous recommandons de désactiver l'exécution automatique des requêtes en parallèle. Bien que le parallélisme puisse accélérer les requêtes sur de grands ensembles de données dans le cadre des charges de travail d'analyse ou de reporting, il présente des risques importants qui l'emportent souvent sur les avantages dans les environnements de production chargés.
L'exécution parallèle entraîne également une surcharge importante. Chaque parallel worker est un processus principal de PostgreSQL complet, qui nécessite une bifurcation des processus (copie des structures de mémoire et initialisation de l'état du processus) et une authentification (consommation d'emplacements de connexion supérieurs à votre limite). `max_connections` Chaque travailleur consomme également sa propre mémoire, notamment `work_mem` pour les opérations de tri et de hachage, avec plusieurs travailleurs par requête, l'utilisation de la mémoire se multiplie rapidement (par exemple, 4 travailleurs × 64 Mo `work_mem` = 256 Mo par requête). Par conséquent, les requêtes parallèles peuvent consommer beaucoup plus de ressources système que les requêtes à processus unique. S'ils ne sont pas correctement réglés, ils peuvent entraîner une saturation du processeur (plusieurs travailleurs surchargent la capacité de traitement disponible), une augmentation du changement de contexte (le système d'exploitation passe fréquemment d'un processus de travail à un autre, augmente la charge de travail et réduit le débit) ou un épuisement des connexions (chaque travailleur parallèle occupe un emplacement de connexion, une requête avec 4 travailleurs au total, ce qui peut rapidement épuiser votre pool de connexions en cas de forte simultanéité, empêchant de nouvelles connexions clients et provoquant des défaillances d'applications). Ces problèmes sont particulièrement graves dans le cas de charges de travail hautement simultanées où plusieurs requêtes peuvent tenter une exécution parallèle simultanément.
PostgreSQL décide d'utiliser ou non le parallélisme en fonction des estimations de coûts. Dans certains cas, le planificateur peut automatiquement passer à un plan parallèle s'il semble moins cher, même si ce n'est pas l'idéal dans la pratique. Cela peut se produire si les statistiques d'index ne sont plus à jour ou si le surcroît de données rend les scans séquentiels plus attrayants que les recherches d'index. En raison de ce comportement, les plans parallèles automatiques peuvent parfois entraîner des régressions au niveau des performances des requêtes ou de la stabilité du système.
Pour tirer le meilleur parti des requêtes parallèles dans , il est important de les tester et de les ajuster en fonction de votre charge de travail, de surveiller l'impact sur le système et de désactiver la sélection automatique des plans parallèles au profit du contrôle au niveau des requêtes.
## Paramètres de configuration
PostgreSQL utilise plusieurs paramètres pour contrôler le comportement et la disponibilité des requêtes parallèles. Il est essentiel de les comprendre et de les ajuster pour obtenir des performances prévisibles :
| Paramètre | Description | Par défaut |
| --- | --- | --- |
| max\$1parallel\$1workers | Nombre maximum de processus de travail en arrière-plan pouvant être exécutés au total | MEILLEUR (\$1 DBInstance VCPU/2,8) |
| max\$1parallel\$1workers\$1per\$1gather | Nombre maximum de travailleurs par nœud du plan de requête (par exemple, parGather) | 2 |
| parallel\$1setup\$1cost | Coût du planificateur ajouté pour le lancement d'une infrastructure de requêtes parallèles | 1 000 |
| parallel\$1tuple\$1cost | Coût par tuple traité en mode parallèle (influence la décision du planificateur) | 0.1 |
| force\$1parallel\$1mode | Force le planificateur à tester des plans parallèles (off,on,regress) | off |
### Considérations clés
+ `max_parallel_workers`contrôle le pool total de travailleurs parallèles. Si cette valeur est trop faible, certaines requêtes peuvent revenir à l'exécution en série.
+ `max_parallel_workers_per_gather`affecte le nombre de travailleurs qu'une seule requête peut utiliser. Une valeur plus élevée augmente la simultanéité, mais également l'utilisation des ressources.
+ `parallel_setup_cost`et `parallel_tuple_cost` affectent le modèle de coûts du planificateur. En les abaissant, les plans parallèles sont plus susceptibles d'être choisis.
+ `force_parallel_mode`est utile pour les tests mais ne doit pas être utilisé en production sauf si cela est nécessaire.
**Note**
La valeur par défaut du `max_parallel_workers` paramètre est calculée dynamiquement en fonction de la taille de l'instance à l'aide de la formule`GREATEST($DBInstanceVCPU/2, 8)`. Cela signifie que lorsque vous adaptez votre à une taille de calcul plus grande avec plus de vCPUs, le nombre maximum de travailleurs parallèles disponibles augmente automatiquement. Par conséquent, les requêtes précédemment exécutées en série ou avec un parallélisme limité peuvent soudainement utiliser davantage de travailleurs parallèles après une opération de mise à l'échelle, ce qui peut entraîner une augmentation inattendue de l'utilisation des connexions, de l'utilisation du processeur et de la consommation de mémoire. Il est important de surveiller le comportement des requêtes parallèles après tout événement de dimensionnement du calcul et de les ajuster `max_parallel_workers_per_gather` si nécessaire pour garantir une utilisation prévisible des ressources.
## Identifier l'utilisation des requêtes parallèles
Les requêtes peuvent passer à des plans parallèles en fonction de la distribution des données ou des statistiques. Par exemple :
```
SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';
```
Cette requête peut utiliser un index pour les données récentes, mais passer à un scan séquentiel parallèle pour les données historiques.
Vous pouvez enregistrer les plans d'exécution des requêtes en chargeant le `auto_explain` module. Pour en savoir plus, consultez la section [Enregistrement des plans d'exécution des requêtes](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) dans le centre de AWS connaissances.
Vous pouvez surveiller [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Database-Instance-Dashboard.html) pour détecter les événements d'attente liés aux requêtes parallèles. Pour en savoir plus sur les événements d'attente liés à Parallel Query, consultez [IPC:Parallel](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-ipc-parallel.html) wait events
À partir de la version 18 de PostgreSQL, vous pouvez surveiller l'activité des travailleurs parallèles à l'aide de nouvelles colonnes dans et : [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW)
+ `parallel_workers_to_launch`: Nombre de travailleurs parallèles dont le lancement est prévu
+ `parallel_workers_launched`: Nombre de travailleurs parallèles réellement lancés
Ces mesures permettent d'identifier les écarts entre le parallélisme prévu et le parallélisme réel, ce qui peut indiquer des contraintes de ressources ou des problèmes de configuration. Utilisez les requêtes suivantes pour surveiller l'exécution parallèle :
Pour les métriques de travail parallèle au niveau de la base de données :
```
SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();
```
Pour les métriques de travail parallèle au niveau de la requête
```
SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;
```
## Comment contrôler le parallélisme
Il existe plusieurs méthodes pour contrôler le parallélisme des requêtes, chacune étant conçue pour différents scénarios et exigences.
Pour désactiver le parallélisme automatique de manière globale, [de paramètres pour définir](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.Modifying.html) :
```
max_parallel_workers_per_gather = 0;
```
Pour les paramètres persistants spécifiques à l'utilisateur, la commande ALTER ROLE permet de définir des paramètres qui s'appliqueront à toutes les futures sessions d'un utilisateur en particulier.
Par exemple :
`ALTER ROLE username SET max_parallel_workers_per_gather = 4;`garantit que chaque fois que cet utilisateur se connecte à la base de données, ses sessions utilisent ce paramètre de travail parallèle lorsque cela est nécessaire.
Le contrôle au niveau de la session peut être réalisé à l'aide de la commande SET, qui modifie les paramètres pendant la durée de la session de base de données en cours. Cela est particulièrement utile lorsque vous devez ajuster temporairement les paramètres sans affecter les autres utilisateurs ou les sessions futures. Une fois définis, ces paramètres restent actifs jusqu'à ce qu'ils soient explicitement réinitialisés ou jusqu'à la fin de la session. Les commandes sont simples :
```
SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;
```
Pour un contrôle encore plus précis, SET LOCAL vous permet de modifier les paramètres d'une seule transaction. C'est idéal lorsque vous devez ajuster les paramètres d'un ensemble spécifique de requêtes au sein d'une transaction, après quoi les paramètres reviennent automatiquement à leurs valeurs précédentes. Cette approche permet d'éviter des effets indésirables sur les autres opérations au cours de la même session.
## Diagnostic du comportement des requêtes parallèles
`EXPLAIN (ANALYZE, VERBOSE)`À utiliser pour vérifier si une requête a utilisé l'exécution parallèle :
+ Recherchez des nœuds tels que `Gather``Gather Merge`, ou`Parallel Seq Scan`.
+ Comparez les forfaits avec et sans parallélisme.
Pour désactiver temporairement le parallélisme à des fins de comparaison :
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
RESET max_parallel_workers_per_gather;
```
# Utilisation de paramètres sur votre instance de base de données RDS pour PostgreSQL
Dans certains cas, vous pouvez créer une instance de base de données RDS pour PostgreSQL sans spécifier de groupe de paramètres personnalisé. Si tel est le cas, votre instance de base de données est créée à l'aide du groupe de paramètres par défaut de la version de PostgreSQL que vous choisissez. Par exemple, supposons que vous créez une instance de base de données RDS pour PostgreSQL à l’aide de PostgreSQL 13.3. Dans ce cas, l'instance de base de données est créée à l'aide des valeurs du groupe de paramètres pour les versions PostgreSQL 13, `default.postgres13`.
Vous pouvez créer votre propre groupe de paramètres de base de données avec des paramètres personnalisés. Vous devez le faire si vous souhaitez modifier les paramètres de l’instance de base de données RDS pour PostgreSQL à partir de leurs valeurs par défaut. Pour savoir comment procéder, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Vous pouvez suivre les paramètres de votre instance de base de données RDS pour PostgreSQL de plusieurs manières différentes. Vous pouvez utiliser l'API AWS Management Console, la AWS CLI, ou l'API Amazon RDS. Vous pouvez également interroger les valeurs à partir de la table `pg_settings` PostgreSQL de votre instance, comme illustré ci-dessous.
```
SELECT name, setting, boot_val, reset_val, unit
FROM pg_settings
ORDER BY name;
```
Pour plus d’informations sur les valeurs renvoyées par cette requête, consultez [https://www.postgresql.org/docs/current/view-pg-settings.html](https://www.postgresql.org/docs/current/view-pg-settings.html) dans la documentation PostgreSQL.
Soyez particulièrement prudent lorsque vous modifiez les paramètres de `max_connections` et `shared_buffers` sur votre instance de base de données RDS pour PostgreSQL. Par exemple, supposons que vous modifiiez les paramètres de `max_connections` ou `shared_buffers` et vous utilisez des valeurs trop élevées pour votre charge de travail réelle. Dans ce cas, votre instance de base de données RDS pour PostgreSQL ne démarrera pas. Si cela se produit, une erreur telle que la suivante s'affiche dans le `postgres.log`.
```
2018-09-18 21:13:15 UTC::@:[8097]:FATAL: could not map anonymous shared memory: Cannot allocate memory
2018-09-18 21:13:15 UTC::@:[8097]:HINT: This error usually means that PostgreSQL's request for a shared memory segment
exceeded available memory or swap space. To reduce the request size (currently 3514134274048 bytes), reduce
PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
```
Toutefois, notez que vous ne pouvez modifier aucune valeur des paramètres contenus dans les groupes de paramètres RDS pour PostgreSQL DB par défaut. Pour modifier n'importe quel paramètre, créez d'abord un groupe de paramètres de base de données personnalisé. Modifiez ensuite les paramètres de ce groupe personnalisé, puis appliquez le groupe de paramètres personnalisé à votre instance de base de données RDS pour PostgreSQL. Pour en savoir plus, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Il existe deux types de paramètres dans RDS pour PostgreSQL.
+ **Paramètres statiques** : les paramètres statiques exigent que l’instance de base de données RDS pour PostgreSQL soit réinitialisée après une modification afin que la nouvelle valeur puisse prendre effet.
+ **Paramètres dynamiques** : les paramètres dynamiques ne nécessitent pas de réinitialisation après avoir modifié leurs paramètres.
**Note**
Si votre instance de base de données RDS pour PostgreSQL utilise votre propre groupe de paramètres de base de données personnalisé, vous pouvez modifier les valeurs des paramètres dynamiques sur l’instance en cours d’exécution. Pour ce faire AWS Management Console, vous pouvez utiliser l'API AWS CLI, ou l'API Amazon RDS.
Vous pouvez également modifier des valeurs de paramètres, si vous disposez des privilèges nécessaires, en utilisant les commandes `ALTER DATABASE`, `ALTER ROLE` et `SET`.
## Liste de paramètres d’instance de base de données RDS pour PostgreSQL
Le tableau suivant répertorie certains (mais pas tous) des paramètres disponibles (mais pas tous) dans une instance de base de données RDS pour PostgreSQL. Pour afficher tous les paramètres disponibles, utilisez la [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) AWS CLI commande. Par exemple, pour obtenir la liste de tous les paramètres disponibles dans le groupe de paramètres par défaut pour RDS pour PostgreSQL version 13, procédez comme suit.
```
aws rds describe-db-parameters --db-parameter-group-name default.postgres13
```
Vous pouvez également utiliser la console. Choisissez **Parameter groups** (Groupes de paramètres) dans le menu Amazon RDS, puis choisissez le groupe de paramètres parmi ceux disponibles dans votre Région AWS.
| Nom du paramètre | Type d'application | Description |
| --- | --- | --- |
| `application_name` | Répartition dynamique | Définit le nom de l'application à indiquer dans les statistiques et les journaux. |
| `archive_command` | Répartition dynamique | Définit la commande shell qui sera appelée pour archiver un fichier WAL. |
| `array_nulls` | Répartition dynamique | Autorise l'entrée d'éléments NULL dans les tableaux. |
| `authentication_timeout` | Répartition dynamique | Définit le délai maximum autorisé pour procéder à l'authentification du client. |
| `autovacuum` | Répartition dynamique | Démarre le sous-processus autovacuum. |
| `autovacuum_analyze_scale_factor` | Répartition dynamique | Nombre de tuples insérés, mis à jour ou supprimés avant analyse en tant que partie de reltuples. |
| `autovacuum_analyze_threshold` | Répartition dynamique | Nombre minimum de tuples insérés, mis à jour ou supprimés avant analyse. |
| `autovacuum_freeze_max_age` | Statique | Âge auquel lancer le processus autovacuum sur une table pour empêcher le bouclage de l’ID de transaction. |
| `autovacuum_naptime` | Répartition dynamique | Temps de repos entre les exécutions autovacuum. |
| `autovacuum_max_workers` | Statique | Définit le nombre maximum de processus autovacuum qui peuvent être exécutés simultanément. |
| `autovacuum_vacuum_cost_delay` | Répartition dynamique | Valeur du coût de retard du processus vacuum en millisecondes, pour le processus autovacuum. |
| `autovacuum_vacuum_cost_limit` | Répartition dynamique | Coût cumulé qui provoque l'endormissement du processus vacuum, pour le processus autovacuum. |
| `autovacuum_vacuum_scale_factor` | Répartition dynamique | Nombre de tuples mis à jour ou supprimés avant le processus vacuum en tant que partie de reltuples. |
| `autovacuum_vacuum_threshold` | Répartition dynamique | Nombre de tuples mis à jour ou supprimés avant le processus vacuum. |
| `backslash_quote` | Répartition dynamique | Définit si une barre oblique inverse (\$1) peut être utilisée dans les littéraux de chaîne. |
| `bgwriter_delay` | Répartition dynamique | Délai d'inactivité entre les tours d'activité du processus d'écriture en arrière-plan. |
| `bgwriter_lru_maxpages` | Répartition dynamique | Nombre maximum de pages récemment utilisées qui peuvent être vidées à chaque tour par le processus d'écriture en tâche de fond. |
| `bgwriter_lru_multiplier` | Répartition dynamique | Multiple de l'utilisation moyenne de tampons à libérer par tour. |
| `bytea_output` | Répartition dynamique | Configure le format de sortie pour les valeurs de type octets. |
| `check_function_bodies` | Répartition dynamique | Vérifie les corps des fonctions pendant la fonction CREATE FUNCTION. |
| `checkpoint_completion_target` | Répartition dynamique | Temps nécessaire pour vider les tampons sales au moment de la vérification, sous la forme d'une fraction de temps entre deux points de vérification. |
| `checkpoint_segments` | Répartition dynamique | Définit la distance maximale dans les segments de journaux entre deux points de vérification automatique de journal WAL. |
| `checkpoint_timeout` | Répartition dynamique | Définit le temps maximum entre deux points de vérification automatique des WAL. |
| `checkpoint_warning` | Répartition dynamique | Active les avertissements si des segments de points de vérification sont remplis à une fréquence supérieure à ce paramètre. |
| `client_connection_check_interval` | Répartition dynamique | Définit l’intervalle de temps entre les vérifications de déconnexion lors de l’exécution des requêtes. |
| `client_encoding` | Répartition dynamique | Définit l'encodage du jeu de caractères du client. |
| `client_min_messages` | Répartition dynamique | Définit les niveaux des messages envoyés au client. |
| `commit_delay` | Répartition dynamique | Définit la durée, en micro-secondes, entre le déclenchement de la sonde transaction-commit et le vidage de WAL vers le disque. |
| `commit_siblings` | Répartition dynamique | Définit le nombre minimum de transactions ouvertes simultanément avant d'atteindre le délai commit\$1delay. |
| `constraint_exclusion` | Répartition dynamique | Autorise le planificateur à utiliser des contraintes pour optimiser les requêtes. |
| `cpu_index_tuple_cost` | Répartition dynamique | Définit l'estimation faite par le planificateur du coût de traitement de chaque entrée d'index pendant la vérification d'un index. |
| `cpu_operator_cost` | Répartition dynamique | Définit l'estimation faite par le planificateur du coût de traitement de chaque opérateur ou appel de fonction. |
| `cpu_tuple_cost` | Répartition dynamique | Définit l'estimation faite par le planificateur du coût de traitement de chaque ligne. |
| `cursor_tuple_fraction` | Répartition dynamique | Définit l'estimation faite par le planificateur de la fraction des lignes d'un curseur qui sera récupérée. |
| `datestyle` | Répartition dynamique | Définit le format d'affichage des valeurs de type date et heure. |
| `deadlock_timeout` | Répartition dynamique | Définit le délai d'attente au niveau d'un verrou avant blocage. |
| `debug_pretty_print` | Répartition dynamique | Indente les affichages des arborescence d'analyse et de planification. |
| `debug_print_parse` | Répartition dynamique | Enregistre l'arborescence d'analyse de chaque requête. |
| `debug_print_plan` | Répartition dynamique | Enregistre le plan d'exécution de chaque requête. |
| `debug_print_rewritten` | Répartition dynamique | Enregistre l'arbre d'interprétation réécrit de chaque requête. |
| `default_statistics_target` | Répartition dynamique | Définit la cible des statistiques par défaut. |
| `default_tablespace` | Répartition dynamique | Définit l'espace de table par défaut dans lequel créer des tables et des index. |
| `default_transaction_deferrable` | Répartition dynamique | Définit le statut reportable des nouvelles transactions. |
| `default_transaction_isolation` | Répartition dynamique | Définit le niveau d’isolement de transaction de chaque nouvelle transaction. |
| `default_transaction_read_only` | Répartition dynamique | Définit le statut en lecture seule des nouvelles transactions. |
| `default_with_oids` | Répartition dynamique | Crée de nouvelles tables avec object IDs (OIDs) par défaut. |
| `effective_cache_size` | Répartition dynamique | Définit l'estimation faite par le planificateur de la taille du cache du disque. |
| `effective_io_concurrency` | Répartition dynamique | Nombre de demandes simultanées pouvant être traitées de manière efficace par le sous-système du disque. |
| `enable_bitmapscan` | Répartition dynamique | Autorise l'utilisation de plans de parcours de bitmap par le planificateur. |
| `enable_hashagg` | Répartition dynamique | Autorise l'utilisation de plans d'agrégation hachée par le planificateur. |
| `enable_hashjoin` | Répartition dynamique | Autorise l'utilisation de plans de jointures de hachage par le planificateur. |
| `enable_indexscan` | Répartition dynamique | Autorise l'utilisation de plans de parcours d'index par le planificateur. |
| `enable_material` | Répartition dynamique | Autorise l'utilisation de la matérialisation par le planificateur. |
| `enable_mergejoin` | Répartition dynamique | Autorise l'utilisation de plans de jointures de fusion par le planificateur. |
| `enable_nestloop` | Répartition dynamique | Autorise l'utilisation de plans de jointures de boucles imbriquées par le planificateur. |
| `enable_seqscan` | Répartition dynamique | Autorise l'utilisation de plans de parcours séquentiels par le planificateur. |
| `enable_sort` | Répartition dynamique | Autorise l'utilisation des étapes de tri explicite par le planificateur. |
| `enable_tidscan` | Répartition dynamique | Autorise l'utilisation de plans de parcours de TID par le planificateur. |
| `escape_string_warning` | Répartition dynamique | Avertit sur l'utilisation des barres obliques inverses (\$1) dans des littéraux de chaîne ordinaires. |
| `extra_float_digits` | Répartition dynamique | Définit le nombre de chiffres affichés pour les valeurs à virgule flottante. |
| `from_collapse_limit` | Répartition dynamique | Définit la taille FROM-list au-delà de laquelle les sous-requêtes ne sont pas regroupées. |
| `fsync` | Répartition dynamique | Force la synchronisation des mises à jour sur le disque. |
| `full_page_writes` | Répartition dynamique | Ecrit les pages complètes dans les WAL lors de la première modification après un point de vérification. |
| `geqo` | Répartition dynamique | Active l'optimisation génétique des requêtes. |
| `geqo_effort` | Répartition dynamique | geqo\$1effort est utilisé pour définir la valeur par défaut pour les autres paramètres GEQO. |
| `geqo_generations` | Répartition dynamique | GEQO : nombre d'itérations de l'algorithme. |
| `geqo_pool_size` | Répartition dynamique | GEQO : nombre d'individus au sein d'une population. |
| `geqo_seed` | Répartition dynamique | GEQO : valeur initiale pour la sélection des chemins au hasard. |
| `geqo_selection_bias` | Répartition dynamique | GEQO : pression de sélectivité au sein de la population. |
| `geqo_threshold` | Répartition dynamique | Définit le seuil d'éléments FROM au-delà duquel GEQO est utilisé. |
| `gin_fuzzy_search_limit` | Répartition dynamique | Définit le résultat maximum autorisé pour la recherche exacte par GIN. |
| `hot_standby_feedback` | Répartition dynamique | Détermine si une instance de secours envoie des messages de commentaire aux instances principales ou de veille en amont. |
| `intervalstyle` | Répartition dynamique | Définit le format d'affichage des valeurs de type intervalle. |
| `join_collapse_limit` | Répartition dynamique | Définit la taille FROM-list au-delà de laquelle les constructions JOIN ne sont pas mises à plat. |
| `lc_messages` | Répartition dynamique | Définit la langue d'affichage des messages. |
| `lc_monetary` | Répartition dynamique | Définit la locale à utiliser pour le formatage des montants monétaires. |
| `lc_numeric` | Répartition dynamique | Définit la locale à utiliser pour le formatage des nombres. |
| `lc_time` | Répartition dynamique | Définit la locale à utiliser pour le formatage des valeurs de date et d'heure. |
| `log_autovacuum_min_duration` | Répartition dynamique | Définit la durée minimum d'exécution au-delà de laquelle les actions autovacuum seront enregistrées. |
| `log_checkpoints` | Répartition dynamique | Enregistre chaque point de vérification. |
| `log_connections` | Répartition dynamique | Enregistre toutes les connexions réussies. |
| `log_disconnections` | Répartition dynamique | Enregistre la fin d'une session, y compris sa durée. |
| `log_duration` | Répartition dynamique | Enregistre la durée de chaque instruction SQL terminée. |
| `log_error_verbosity` | Répartition dynamique | Définit la quantité de détails dans les messages enregistrés. |
| `log_executor_stats` | Répartition dynamique | Ecrit les statistiques de performance de l'exécuteur dans le journal du serveur. |
| `log_filename` | Répartition dynamique | Définit le modèle de nom de fichier pour les fichiers journaux. |
| `log_file_mode` | Répartition dynamique | Définit les autorisations de fichier pour les fichiers journaux. La valeur par défaut est 0644. |
| `log_hostname` | Répartition dynamique | Enregistre le nom de l'hôte dans les journaux de connexion. À partir de PostgreSQL 12 et des versions ultérieures, ce paramètre est « désactivé » par défaut. Lorsqu'il est activé, la connexion utilise la recherche inversée DNS pour obtenir le nom d'hôte qui est capturé dans les journaux de connexion. Si vous activez ce paramètre, vous devez surveiller son impact sur le temps nécessaire à l'établissement des connexions. |
| `log_line_prefix ` | Répartition dynamique | Contrôle les informations préfixées à chaque ligne de journal. |
| `log_lock_waits` | Répartition dynamique | Enregistre les longs temps d'attente pour l'acquisition d'un verrou. |
| `log_min_duration_statement` | Répartition dynamique | Définit la durée minimum d'exécution au-delà de laquelle les instructions seront enregistrées. |
| `log_min_error_statement` | Répartition dynamique | Déclenche l'enregistrement de toutes les instructions générant une erreur à ce niveau ou à un niveau supérieur. |
| `log_min_messages` | Répartition dynamique | Définit les niveaux des messages qui sont enregistrés. |
| `log_parser_stats` | Répartition dynamique | Ecrit les statistiques de performance de l'analyseur dans le journal du serveur. |
| `log_planner_stats` | Répartition dynamique | Ecrit les statistiques de performance du planificateur dans le journal du serveur. |
| `log_rotation_age` | Répartition dynamique | Déclenchement de la rotation de fichier journal automatique au-delà d'un délai de N minutes. |
| `log_rotation_size` | Répartition dynamique | Déclenchement de la rotation de fichier journal automatique au-delà de N kilo-octets. |
| `log_statement` | Répartition dynamique | Définit le type d'instructions enregistrées. |
| `log_statement_stats` | Répartition dynamique | Ecrit les statistiques de performance cumulées dans le journal du serveur. |
| `log_temp_files` | Répartition dynamique | Enregistre l'utilisation des fichiers temporaires dont la taille est supérieure à cette taille en kilo-octets. |
| `log_timezone` | Répartition dynamique | Définit le fuseau horaire à utiliser dans les messages de journaux. |
| `log_truncate_on_rotation` | Répartition dynamique | Tronquez les fichiers journaux existants du même nom pendant la rotation des journaux. |
| `logging_collector` | Statique | Démarrez un sous-processus pour capturer les fichiers and/or CSV de sortie stderr dans des fichiers journaux. |
| `maintenance_work_mem` | Répartition dynamique | Définit la quantité maximum de mémoire que peuvent utiliser les opérations de maintenance. |
| `max_connections` | Statique | Définit le nombre maximum de connexions simultanées. |
| `max_files_per_process` | Statique | Définit le nombre maximum de fichiers ouverts simultanément pour chaque processus serveur. |
| `max_locks_per_transaction` | Statique | Définit le nombre maximum de verrous par transaction. |
| `max_pred_locks_per_transaction` | Statique | Définit le nombre maximum de verrous de prédicat par transaction. |
| `max_prepared_transactions` | Statique | Définit le nombre maximum de transactions préparées simultanément. |
| `max_stack_depth` | Répartition dynamique | Définit la profondeur maximum de la pile, en kilo-octets. |
| `max_standby_archive_delay` | Répartition dynamique | Définit le délai maximum avant l'annulation des requêtes lorsqu'un serveur hot standby traite des données WAL archivées. |
| `max_standby_streaming_delay` | Répartition dynamique | Définit le délai maximum avant l'annulation des requêtes lorsqu'un serveur hot standby traite des données WAL diffusées. |
| max\$1wal\$1size | Répartition dynamique | Définit la taille (en Mo) de journal WAL qui déclenche un point de vérification. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html) Utilisez la commande suivante sur votre instance de base de données Amazon RDS pour PostgreSQL pour voir sa valeur actuelle :
SHOW max_wal_size;
|
| min\$1wal\$1size | Répartition dynamique | Définit la taille minimale à laquelle réduire le journal WAL. Pour PostgreSQL version 9.6 ou antérieure, la taille min\$1wal\$1size est exprimée en unités de 16 Mo. Pour PostgreSQL version 10 ou supérieure, la taille min\$1wal\$1size est exprimée en unités de 1 Mo. |
| `quote_all_identifiers` | Répartition dynamique | Ajoute des guillemets (") à tous les identifiants lors de la génération de fragments SQL. |
| `random_page_cost` | Répartition dynamique | Définit l'estimation faite par le planificateur du coût d'une page de disque extraite de façon non séquentielle. Ce paramètre n'a aucune valeur sauf si la gestion du plan de requête (QPM) est activée. Lorsque QPM est activée, la valeur par défaut de ce paramètre est 4. |
| rds.adaptive\$1autovacuum | Répartition dynamique | Règle automatiquement les paramètres d'autovacuum chaque fois que les seuils d'ID de transaction sont dépassés. |
| rds.force\$1ssl | Répartition dynamique | Nécessite l'utilisation de connexions SSL. La valeur par défaut est définie sur 1 (activé) pour RDS pour PostgreSQL version 15. Toutes les autres versions majeures 14 et antérieures de RDS pour PostgreSQL ont la valeur par défaut définie sur 0 (désactivé). |
| `rds.local_volume_spill_enabled` | Statique | Permet d’écrire des fichiers de déversement logiques sur le volume local. |
| `rds.log_retention_period` | Répartition dynamique | Définit la rétention des journaux de telle manière qu'Amazon RDS supprime les journaux PostgreSQL antérieurs à n minutes. |
| rds.rds\$1superuser\$1reserved\$1connections | Statique | Définit le nombre d’emplacements de connexion réservés pour rds\$1superusers. Ce paramètre est uniquement disponible dans les versions 15 et antérieures. Pour plus d’informations, consultez la documentation de PostgreSQL sur [reserved\$1connections](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-RESERVED-CONNECTIONS). |
| `rds.replica_identity_full` | Répartition dynamique | Lorsque vous définissez ce paramètre sur `on`, il remplace le paramètre d’identité de réplique sur `FULL` pour toutes les tables de base de données. Cela signifie que toutes les valeurs des colonnes sont écrites dans le journal d’écriture anticipée (WAL), quels que soient vos paramètres `REPLICA IDENTITY FULL`. L’activation de ce paramètre peut augmenter les IOPS de votre instance de base de données en raison de la journalisation WAL supplémentaire. |
| rds.restrict\$1password\$1commands | Statique | Limite la gestion des mots de passe aux utilisateurs auxquels le rôle rds\$1password a été affecté. Pour la restriction par mot de passe, définissez ce paramètre sur 1. La valeur par défaut est 0. |
| `search_path` | Répartition dynamique | Définit l'ordre de recherche des schémas pour les noms pour lesquels le schéma n'est pas précisé. |
| `seq_page_cost` | Répartition dynamique | Définit l'estimation faite par le planificateur du coût d'une page de disque extraite de façon séquentielle. |
| `session_replication_role` | Répartition dynamique | Définit le comportement des sessions concernant les déclencheurs et les règles de réécriture. |
| `shared_buffers` | Statique | Définit le nombre de tampons de mémoire partagée utilisés par le serveur. |
| `shared_preload_libraries ` | Statique | Répertorie les bibliothèques partagées à précharger dans l’instance de base de données RDS pour PostgreSQL. Les valeurs prises en charge incluent auto\$1explain, orafce, pgaudit, pglogical, pg\$1bigm, pg\$1cron, pg\$1hint\$1plan, pg\$1prewarm, pg\$1similarity, pg\$1stat\$1statements, pg\$1tle, pg\$1transport, plprofiler et plrust. |
| `ssl` | Répartition dynamique | Active les connexions SSL. |
| `sql_inheritance` | Répartition dynamique | Entraîne l'ajout par défaut de sous-tables dans plusieurs commandes. |
| `ssl_renegotiation_limit` | Répartition dynamique | Définit la quantité de trafic à envoyer et recevoir avant de renégocier les clés de chiffrement. |
| `standard_conforming_strings` | Répartition dynamique | Entraîne les chaînes ... à traiter littéralement les barres obliques inverses. |
| `statement_timeout` | Répartition dynamique | Définit la durée maximum de toute instruction. |
| `synchronize_seqscans` | Répartition dynamique | Active les analyses séquentielles synchronisées. |
| `synchronous_commit` | Répartition dynamique | Définit le niveau de synchronisation des transactions actuelles. |
| `tcp_keepalives_count` | Répartition dynamique | Nombre maximum de paquets TCP keepalive. |
| `tcp_keepalives_idle` | Répartition dynamique | Délai entre les émissions de paquets TCP keepalive. |
| `tcp_keepalives_interval` | Répartition dynamique | Délai entre les envois de paquets TCP keepalive. |
| `temp_buffers` | Répartition dynamique | Définit le nombre maximum de tampons temporaires utilisés par chaque session. |
| temp\$1file\$1limit | Répartition dynamique | Définit la taille maximale en Ko que peuvent atteindre les fichiers temporaires. |
| `temp_tablespaces` | Répartition dynamique | Définit l'espace de table à utiliser pour les tables et fichiers de tri temporaires. |
| `timezone` | Répartition dynamique | Définit le fuseau horaire pour l'affichage et l'interprétation de la date et de l'heure. L'Internet Assigned Numbers Authority (IANA) publie de nouveaux fuseaux horaires sur [https://www.iana.org/time-zones](https://www.iana.org/time-zones) plusieurs fois par an. Chaque fois que RDS publie une nouvelle version de maintenance mineure de PostgreSQL, elle est livrée avec les dernières données de fuseau horaire au moment de la publication. Lorsque vous utilisez les dernières versions de RDS pour PostgreSQL, vous disposez de données de fuseau horaire récentes provenant de RDS. Pour vous assurer que votre instance de base de données dispose de données de fuseau horaire récentes, nous vous recommandons de passer à une version supérieure du moteur de base de données. Vous ne pouvez pas modifier les tables de fuseau horaire des instances de base de données PostgreSQL manuellement. RDS ne modifie ni ne réinitialise les données de fuseau horaire des instances de base de données en cours d'exécution. Les nouvelles données de fuseau horaire ne sont installées que lorsque vous effectuez une mise à niveau de la version du moteur de base de données. |
| `track_activities` | Répartition dynamique | Collecte des informations sur les commandes en cours d'exécution. |
| `track_activity_query_size` | Statique | Définit la taille réservée pour pg\$1stat\$1activity.current\$1query, en octets. |
| `track_counts` | Répartition dynamique | Active la collecte de statistiques sur l'activité de la base de données. |
| `track_functions` | Répartition dynamique | Active la collecte de statistiques au niveau de la fonction sur l'activité de la base de données. |
| `track_io_timing` | Répartition dynamique | Collecte des statistiques temporelles sur l' I/O activité de la base de données. |
| `transaction_deferrable` | Répartition dynamique | Indique si une transaction sérialisable en lecture seule doit être différée jusqu'à ce qu'elle puisse être démarrée sans échec de sérialisation possible. |
| `transaction_isolation` | Répartition dynamique | Définit le niveau d’isolement des transactions actuelles. |
| `transaction_read_only` | Répartition dynamique | Définit le statut en lecture seule des transactions actuelles. |
| `transform_null_equals` | Répartition dynamique | Traite l'expression =NULL en tant que IS NULL. |
| `update_process_title` | Répartition dynamique | Met à jour le titre du processus pour indiquer la commande SQL active. |
| `vacuum_cost_delay` | Répartition dynamique | Valeur du coût de délai du processus vacuum en millisecondes. |
| `vacuum_cost_limit` | Répartition dynamique | Coût cumulé qui provoque l'endormissement du processus vacuum. |
| `vacuum_cost_page_dirty` | Répartition dynamique | Coût du processus vacuum pour une page salie par le processus vacuum. |
| `vacuum_cost_page_hit` | Répartition dynamique | Coût du processus vacuum pour une page trouvée dans le cache des tampons. |
| `vacuum_cost_page_miss` | Répartition dynamique | Coût du processus vacuum pour une page non trouvée dans le cache des tampons. |
| `vacuum_defer_cleanup_age` | Répartition dynamique | Nombre de transactions pendant lesquelles le processus vacuum et le nettoyage hot seront reportés à plus tard, le cas échéant. |
| `vacuum_freeze_min_age` | Répartition dynamique | Âge limite auquel le processus vacuum doit figer une ligne de tableau. |
| `vacuum_freeze_table_age` | Répartition dynamique | Âge auquel le processus vacuum effectue une analyse complète de la table pour figer des lignes. |
| `wal_buffers` | Statique | Définit le nombre de tampons de page de disque dans la mémoire partagée pour les WAL. |
| `wal_writer_delay` | Répartition dynamique | Délai d'inactivité de l'enregistreur des WAL entre les actions de vidage WAL. |
| `work_mem` | Répartition dynamique | Définit la quantité maximum de mémoire que peuvent utiliser les espaces de travail des requêtes. |
| `xmlbinary` | Répartition dynamique | Définit la façon dont les valeurs binaires doivent être codées en XML. |
| `xmloption` | Répartition dynamique | Définit si des données XML dans des opérations d'analyse ou de sérialisation implicites doivent être considérées comme des documents ou des fragments de contenu. |
Amazon RDS utilise les unités PostgreSQL par défaut pour tous les paramètres. Le tableau suivant présente l'unité par défaut PostgreSQL pour chaque paramètre.
| Nom du paramètre | Unit |
| --- | --- |
| `archive_timeout` | s |
| `authentication_timeout` | s |
| `autovacuum_naptime` | s |
| `autovacuum_vacuum_cost_delay` | ms |
| `bgwriter_delay` | ms |
| `checkpoint_timeout` | s |
| `checkpoint_warning` | s |
| `deadlock_timeout` | ms |
| `effective_cache_size` | 8 Ko |
| `lock_timeout` | ms |
| `log_autovacuum_min_duration` | ms |
| `log_min_duration_statement` | ms |
| `log_rotation_age` | minutes |
| `log_rotation_size` | Ko |
| `log_temp_files` | Ko |
| `maintenance_work_mem` | Ko |
| `max_stack_depth` | Ko |
| `max_standby_archive_delay` | ms |
| `max_standby_streaming_delay` | ms |
| `post_auth_delay` | s |
| `pre_auth_delay` | s |
| `segment_size` | 8 Ko |
| `shared_buffers` | 8 Ko |
| `statement_timeout` | ms |
| `ssl_renegotiation_limit` | Ko |
| `tcp_keepalives_idle` | s |
| `tcp_keepalives_interval` | s |
| `temp_file_limit` | Ko |
| `work_mem` | Ko |
| `temp_buffers` | 8 Ko |
| `vacuum_cost_delay` | ms |
| `wal_buffers` | 8 Ko |
| `wal_receiver_timeout` | ms |
| `wal_segment_size` | B |
| `wal_sender_timeout` | ms |
| `wal_writer_delay` | ms |
| `wal_receiver_status_interval` | s |
# Réglage avec les événements d'attente pour RDS for PostgreSQL
Les événements d'attente constituent un outil de réglage important pour RDS for PostgreSQL. Lorsque vous parvenez à déterminer pourquoi les sessions sont en attente de ressources et ce qu’elles font, vous êtes mieux à même de réduire les goulets d’étranglement. Vous pouvez utiliser les informations de cette section pour déterminer les causes possibles et les actions correctives à mettre en œuvre. Cette section décrit également les concepts de base du réglage de PostgreSQL.
Les événements d'attente présentés dans cette section sont spécifiques à RDS for PostgreSQL.
**Topics**
+ [
# Concepts essentiels à connaître pour le réglage de RDS for PostgreSQL
](PostgreSQL.Tuning.concepts.md)
+ [
# Événements d'attente RDS for PostgreSQL
](PostgreSQL.Tuning.concepts.summary.md)
+ [
# Cliente : ClientRead
](wait-event.clientread.md)
+ [
# Cliente : ClientWrite
](wait-event.clientwrite.md)
+ [
# CPU
](wait-event.cpu.md)
+ [
# IO : BufFileRead et IO : BufFileWrite
](wait-event.iobuffile.md)
+ [
# IO : DataFileRead
](wait-event.iodatafileread.md)
+ [
# IO:WALWrite
](wait-event.iowalwrite.md)
+ [
# IPC:parallel wait events
](rpg-ipc-parallel.md)
+ [
# IPC : ProcArrayGroupUpdate
](apg-rpg-ipcprocarraygroup.md)
+ [
# Lock:advisory
](wait-event.lockadvisory.md)
+ [
# Lock:extend
](wait-event.lockextend.md)
+ [
# Lock:Relation
](wait-event.lockrelation.md)
+ [
# Lock:transactionid
](wait-event.locktransactionid.md)
+ [
# Lock:tuple
](wait-event.locktuple.md)
+ [
# LWLock: BufferMapping (:buffer\$1mapping) LWLock
](wait-event.lwl-buffer-mapping.md)
+ [
# LWLock:BufferIO (IPC:BufferIO)
](wait-event.lwlockbufferio.md)
+ [
# LWLock:buffer\$1content (BufferContent)
](wait-event.lwlockbuffercontent.md)
+ [
# LWLock:lock\$1manager (:lockmanager) LWLock
](wait-event.lw-lock-manager.md)
+ [
# LWLock:pg\$1stat\$1statements
](apg-rpg-lwlockpgstat.md)
+ [
# LWLock:SubTransSLRU (:) LWLock SubtransControlLock
](wait-event.lwlocksubtransslru.md)
+ [
# Timeout:PgSleep
](wait-event.timeoutpgsleep.md)
+ [
# Timeout:VacuumDelay
](wait-event.timeoutvacuumdelay.md)
# Concepts essentiels à connaître pour le réglage de RDS for PostgreSQL
Avant de procéder au réglage de votre base de données RDS for PostgreSQL, découvrez ce que sont les événements d'attente et pourquoi ils se produisent. Examinez également l'architecture de base de RDS for PostgreSQL en termes de mémoire et de disque. Un diagramme d'architecture très utile est disponible dans le wikibook [PostgreSQL](https://en.wikibooks.org/wiki/PostgreSQL/Architecture).
**Topics**
+ [
# Événements d'attente RDS for PostgreSQL
](PostgreSQL.Tuning.concepts.waits.md)
+ [
# Mémoire RDS pour PostgreSQL
](PostgreSQL.Tuning.concepts.memory.md)
+ [
# Processus RDS for PostgreSQL
](PostgreSQL.Tuning.concepts.processes.md)
# Événements d'attente RDS for PostgreSQL
Un *événement d'attente* indique que la session est en attente d'une ressource. Par exemple, l'événement d'attente `Client:ClientRead` se produit quand RDS for PostgreSQL attend de recevoir des données du client. Les sessions attendent généralement des ressources telles que les suivantes.
+ Accès monothread à une mémoire tampon, par exemple lorsqu'une session tente de modifier une mémoire tampon
+ Ligne verrouillée par une autre session
+ Lecture d'un fichier de données
+ Écriture de fichier journal
Par exemple, pour répondre à une requête, la session peut effectuer une analyse complète de la table. Si les données ne sont pas déjà en mémoire, la session attend la fin des opérations d'I/O disque. Lorsque les mémoires tampons sont lues en mémoire, la session peut être contrainte d'attendre parce que d'autres sessions accèdent aux mêmes mémoires tampons. La base de données enregistre les attentes à l'aide d'un événement d'attente prédéfini. Ces événements sont regroupés en catégories.
En soi, un événement d'attente individuel n'indique pas un problème de performances. Par exemple, si les données demandées ne sont pas en mémoire, il est nécessaire de les lire sur le disque. Si une session verrouille une ligne pour une mise à jour, une autre session attend que la ligne soit déverrouillée pour pouvoir la mettre à jour. Une validation nécessite d'attendre la fin de l'écriture dans un fichier journal. Les attentes font partie intégrante du fonctionnement normal d'une base de données.
D'un autre côté, un grand nombre d'événements d'attente indiquent généralement un problème de performances. Dans ce cas, vous pouvez utiliser les données des événements d'attente pour déterminer où les sessions passent du temps. Par exemple, si plusieurs heures sont désormais nécessaires à l'exécution d'un rapport qui ne prend habituellement que quelques minutes, vous pouvez identifier les événements d'attente qui contribuent le plus au temps d'attente total. La détermination des causes des principaux événements d'attente peut vous permettre d'apporter des modifications qui auront pour effet d'améliorer les performances. Par exemple, si votre session est en attente sur une ligne qui a été verrouillée par une autre session, vous pouvez mettre fin à la session à l'origine du verrouillage.
# Mémoire RDS pour PostgreSQL
La mémoire RDS pour PostgreSQL se décompose en deux parties : la mémoire partagée et la mémoire locale.
**Topics**
+ [
## Mémoire partagée dans RDS pour PostgreSQL
](#PostgreSQL.Tuning.concepts.shared)
+ [
## Mémoire locale dans RDS pour PostgreSQL
](#PostgreSQL.Tuning.concepts.local)
## Mémoire partagée dans RDS pour PostgreSQL
RDS pour PostgreSQL alloue de la mémoire partagée au démarrage de l’instance. La mémoire partagée se décompose en sous-zones. Les sections suivantes décrivent les principales.
**Topics**
+ [
### Mémoires tampons partagées
](#PostgreSQL.Tuning.concepts.buffer-pool)
+ [
### Mémoires tampons WAL (Write-Ahead Log)
](#PostgreSQL.Tuning.concepts.WAL)
### Mémoires tampons partagées
Le *groupe de mémoires tampons partagées* est une zone de mémoire RDS pour PostgreSQL qui contient toutes les pages actuellement ou précédemment utilisées par les connexions d’applications. Une *page* correspond à la version mémoire d'un bloc de disque. Le groupe de mémoires tampons partagées met en cache les blocs de données lus sur le disque. Le groupe réduit la nécessité de relire les données à partir du disque, ce qui améliore l'efficacité de la base de données.
Chaque table et chaque index est stocké sous la forme d'un tableau de pages de taille fixe. Chaque bloc contient plusieurs tuples, qui correspondent à des lignes. Un tuple peut être stocké sur n'importe quelle page.
Le groupe de mémoires tampons partagées dispose d'une mémoire limitée. Si une nouvelle demande requiert une page qui n’est pas en mémoire, et qu’il n’y a plus de mémoire disponible, RDS pour PostgreSQL expulse une page moins fréquemment utilisée pour répondre à la demande. La politique d'expulsion est implémentée par un algorithme de balayage horaire.
Le paramètre `shared_buffers` détermine la quantité de mémoire que le serveur consacre à la mise en cache des données. La valeur par défaut est définie sur `{DBInstanceClassMemory/32768}` octets, en fonction de la mémoire disponible pour l’instance de base de données.
### Mémoires tampons WAL (Write-Ahead Log)
Une *mémoire tampon WAL (Write-Ahead Log)* contient des données de transaction que RDS pour PostgreSQL écrit ultérieurement sur un stockage permanent. Le mécanisme WAL permet à RDS pour PostgreSQL d’effectuer les opérations suivantes :
+ Récupérer des données après une défaillance
+ Réduisez le disque I/O en évitant les écritures fréquentes sur le disque
Quand un client modifie des données, RDS pour PostgreSQL écrit les modifications dans la mémoire tampon WAL. Lorsque le client émet une commande `COMMIT`, le processus d'écriture WAL écrit les données de transaction dans le fichier WAL.
Le paramètre `wal_level` détermine la quantité d’informations écrites dans la mémoire tampon WAL, les valeurs possibles étant par exemple `minimal`, `replica` et `logical`.
## Mémoire locale dans RDS pour PostgreSQL
Chaque processus dorsal alloue de la mémoire locale pour le traitement des requêtes.
**Topics**
+ [
### Zone de mémoire de travail
](#PostgreSQL.Tuning.concepts.local.work_mem)
+ [
### Zone de mémoire des travaux de maintenance
](#PostgreSQL.Tuning.concepts.local.maintenance_work_mem)
+ [
### Zone de mémoire tampon temporaire
](#PostgreSQL.Tuning.concepts.temp)
### Zone de mémoire de travail
La *zone de mémoire de travail* contient des données temporaires pour les requêtes qui effectuent des opérations de tri et de hachage. Par exemple, une requête contenant une clause `ORDER BY` effectue un tri. Les requêtes utilisent des tables de hachage dans les jointures de hachage et les agrégations.
Le paramètre `work_mem` indique la quantité de mémoire à utiliser par les tables de hachage et les opérations de tri internes avant d’écrire dans des fichiers disque temporaires, mesurée en mégaoctets. La valeur par défaut est de 4 Mo. Plusieurs sessions peuvent s'exécuter simultanément et chacune peut exécuter des opérations de maintenance en parallèle. La mémoire de travail totale utilisée peut donc être un multiple du paramètre `work_mem`.
### Zone de mémoire des travaux de maintenance
La *zone de mémoire des travaux de maintenance* met les données en cache pour les opérations de maintenance. Ces opérations incluent l'opération VACUUM, la création d'un index et l'ajout de clés étrangères.
Le paramètre `maintenance_work_mem` spécifie la quantité maximale de mémoire à utiliser par les opérations de maintenance, mesurée en mégaoctets. La valeur par défaut est de 64 Mo. Une session de base de données ne peut exécuter qu'une seule opération de maintenance à la fois.
### Zone de mémoire tampon temporaire
La *zone de mémoire tampon temporaire* met en cache les tables temporaires pour chaque session de base de données.
Chaque session alloue des mémoires tampons temporaires en fonction des besoins jusqu'à la limite que vous spécifiez. Lorsque la session se termine, le serveur efface le contenu des mémoires tampons.
Le paramètre `temp_buffers` définit le nombre maximal de mémoires tampons temporaires utilisées par chaque session, mesuré en mégaoctets. La valeur par défaut est de 8 Mo. Avant la première utilisation de tables temporaires au sein d'une session, vous pouvez modifier la valeur `temp_buffers`.
# Processus RDS for PostgreSQL
RDS for PostgreSQL utilise plusieurs processus.
**Topics**
+ [
## Processus postmaster
](#PostgreSQL.Tuning.concepts.postmaster)
+ [
## Processus backend
](#PostgreSQL.Tuning.concepts.backend)
+ [
## Processus d'arrière-plan
](#PostgreSQL.Tuning.concepts.vacuum)
## Processus postmaster
Le *processus postmaster* est le premier qui est lancé lorsque vous démarrez RDS for PostgreSQL. Les principales responsabilités du processus postmaster sont les suivantes :
+ Créer et surveiller les processus d'arrière-plan
+ Recevoir les requêtes d'authentification des processus clients, et les authentifier avant d'autoriser la base de données à traiter les requêtes
## Processus backend
Si le processus postmaster authentifie une requête client, il crée un nouveau processus backend, également appelé processus postgres. Un processus client se connecte à un seul processus backend. Le processus client et le processus backend communiquent directement sans intervention du processus postmaster.
## Processus d'arrière-plan
Le processus postmaster crée plusieurs processus qui effectuent différentes tâches backend. Les plus importants sont les suivants :
+ Dispositif d'écriture WAL
RDS for PostgreSQL écrit les données contenues dans la mémoire tampon WAL (Write-Ahead Log) dans les fichiers journaux. Le principe de l'approche WAL est que la base de données ne peut pas écrire les modifications dans les fichiers de données tant que la base de données n'a pas écrit les enregistrements de journal décrivant ces modifications sur le disque. Le mécanisme WAL réduit les E/S disque et permet à RDS for PostgreSQL d'utiliser les journaux pour restaurer la base de données après une défaillance.
+ Dispositif d'écriture d'arrière-plan
Ce processus écrit périodiquement les pages modifiées des mémoires tampons vers les fichiers de données. Une page est considérée comme modifiée lorsqu'un processus backend la modifie en mémoire.
+ Démon autovacuum
Le démon est composé des éléments suivants :
+ Le lanceur autovacuum
+ Les processus employés autovacuum
Lorsque la fonction autovacuum est activée, elle recherche les tables dans lesquelles un grand nombre de tuples ont été insérés, mis à jour ou supprimés. Les responsabilités du démon sont les suivantes :
+ Récupérer ou réutiliser l'espace disque occupé par les lignes mises à jour ou supprimées
+ Mettre à jour les statistiques utilisées par le planificateur
+ Protéger contre la perte d'anciennes données en raison du renvoi à la ligne de l'ID de transaction
La fonction autovacuum automatise l'exécution des commandes `VACUUM` et `ANALYZE`. `VACUUM`présente les variantes suivantes : standard et complet. La variante standard s'exécute parallèlement à d'autres opérations de base de données. `VACUUM FULL` requiert un verrou exclusif sur la table sur laquelle il travaille. Il ne peut donc pas être exécuté en parallèle avec des opérations qui accèdent à la même table. `VACUUM`crée un I/O trafic important, ce qui peut nuire aux performances des autres sessions actives.
# Événements d'attente RDS for PostgreSQL
Le tableau suivant répertorie les événements d'attente liés à RDS for PostgreSQL, qui révèlent souvent des problèmes de performances, et résume leurs causes et les actions correctives les plus courantes.
| Événement d'attente | Définition |
| --- | --- |
| [Cliente : ClientRead](wait-event.clientread.md) | Cet événement se produit quand RDS for PostgreSQL attend de recevoir des données du client. |
| [Cliente : ClientWrite](wait-event.clientwrite.md) | Cet événement se produit quand RDS for PostgreSQL attend d'écrire des données sur le client. |
| [CPU](wait-event.cpu.md) | Cet événement se produit lorsqu'un thread est actif dans l'UC ou qu'il est en attente d'UC. |
| [IO : BufFileRead et IO : BufFileWrite](wait-event.iobuffile.md) | Ces événements se produisent quand RDS for PostgreSQL crée des fichiers temporaires. |
| [IO : DataFileRead](wait-event.iodatafileread.md) | Cet événement se produit lorsqu'une connexion attend qu'un processus backend lise une page requise à partir du stockage parce que la page n'est pas disponible dans la mémoire partagée. |
| [IO:WALWrite](wait-event.iowalwrite.md) | Cet événement indique quand RDS for PostgreSQL est en attente de l'écriture des tampons de journal d'écriture anticipée (WAL) dans un fichier WAL. |
| [Lock:advisory](wait-event.lockadvisory.md) | Cet événement se produit lorsqu'une application PostgreSQL utilise un verrou pour coordonner l'activité sur plusieurs sessions. |
| [Lock:extend](wait-event.lockextend.md) | Cet événement se produit lorsqu'un processus backend attend de verrouiller une relation pour l'étendre alors qu'un autre processus présente un verrou sur cette relation dans le même but. |
| [Lock:Relation](wait-event.lockrelation.md) | Cet événement se produit lorsqu'une requête attend d'acquérir un verrou sur une table ou une vue actuellement verrouillée par une autre transaction. |
| [Lock:transactionid](wait-event.locktransactionid.md) | Cet événement se produit lorsqu'une transaction attend un verrou de niveau ligne. |
| [Lock:tuple](wait-event.locktuple.md) | Cet événement se produit lorsqu'un processus backend attend d'acquérir un verrou sur un tuple. |
| [LWLock: BufferMapping (:buffer\$1mapping) LWLock](wait-event.lwl-buffer-mapping.md) | Cet événement se produit lorsqu'une session attend d'associer un bloc de données à une mémoire tampon dans le groupe de mémoires tampons partagées. |
| [LWLock:BufferIO (IPC:BufferIO)](wait-event.lwlockbufferio.md) | Cet événement se produit lorsque RDS pour PostgreSQL attend que d'autres processus input/output terminent leurs opérations (E/S) lorsqu'ils tentent simultanément d'accéder à une page. |
| [LWLock:buffer\$1content (BufferContent)](wait-event.lwlockbuffercontent.md) | Cet événement se produit lorsqu'une session attend de lire ou d'écrire une page de données en mémoire alors que celle-ci est verrouillée en écriture dans une autre session. |
| [LWLock:lock\$1manager (:lockmanager) LWLock](wait-event.lw-lock-manager.md) | Cet événement se produit lorsque le moteur RDS for PostgreSQL conserve la zone de mémoire du verrou partagé pour allouer, vérifier et libérer un verrou quand il est impossible d'utiliser un verrou à chemin d'accès rapide. |
| [LWLock:SubTransSLRU (:) LWLock SubtransControlLock](wait-event.lwlocksubtransslru.md) | Cet événement se produit lorsqu'un processus attend d'accéder au cache simple le moins récemment utilisé (SLRU) pour une sous-transaction. |
| [Timeout:PgSleep](wait-event.timeoutpgsleep.md) | Cet événement se produit lorsqu'un processus serveur a appelé la fonction `pg_sleep` et attend l'expiration du délai de mise en veille. |
| [Timeout:VacuumDelay](wait-event.timeoutvacuumdelay.md) | Cet événement indique que le processus vacuum est en veille car la limite de coût estimée a été atteinte. |
# Cliente : ClientRead
L’événement `Client:ClientRead` se produit quand RDS pour PostgreSQL attend de recevoir des données du client.
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.clientread.context.supported)
+ [
## Contexte
](#wait-event.clientread.context)
+ [
## Causes probables de l’augmentation du nombre d’événements d’attente
](#wait-event.clientread.causes)
+ [
## Actions
](#wait-event.clientread.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente sont prises en charge pour RDS pour PostgreSQL versions 10 et ultérieures.
## Contexte
Une instance de base de données RDS pour PostgreSQL attend de recevoir des données du client. L’instance de base de données RDS pour PostgreSQL doit recevoir les données du client avant de pouvoir envoyer plus de données au client. La période pendant laquelle l'instance attend avant de recevoir les données du client est un événement `Client:ClientRead`.
## Causes probables de l’augmentation du nombre d’événements d’attente
Les principales causes de l’événement d’attente `Client:ClientRead` sont les suivantes :
**Latence réseau accrue**
La latence réseau peut être accrue entre l’instance de base de données RDS pour PostgreSQL et le client. Une latence réseau plus élevée augmente le temps de réception des données du client par l'instance de base de données.
**Charge accrue sur le client**
Le client peut être soumis à une pression exercée sur l’UC ou à une saturation du réseau. Une augmentation de la charge sur le client peut retarder la transmission des données du client vers l’instance de base de données RDS pour PostgreSQL.
**Nombre excessif d’allers-retours réseau**
Un grand nombre d’allers-retours réseau entre l’instance de base de données RDS pour PostgreSQL et le client peut retarder la transmission des données du client vers l’instance de base de données RDS pour PostgreSQL.
**Opération de copie importante**
Lors d’une opération de copie, les données sont transférées du système de fichiers du client vers l’instance de base de données RDS pour PostgreSQL. L'envoi d'une grande quantité de données à l'instance de base de données peut retarder la transmission des données du client vers l'instance de base de données.
**Connexion client inactive**
Quand un client se connecte à l’instance de base de données RDS pour PostgreSQL alors que son état est `idle in transaction`, l’instance de base de données peut attendre que le client envoie plus de données ou émette une commande. Une connexion dans ces conditions peut entraîner une augmentation des événements `Client:ClientRead`.
**PgBouncer utilisé pour le regroupement de connexions**
PgBouncer possède un paramètre de configuration réseau de bas niveau appelé`pkt_buf`, qui est défini sur 4 096 par défaut. Si la charge de travail envoie des paquets de requêtes de plus de 4 096 octets PgBouncer, nous vous recommandons d'augmenter le `pkt_buf` paramètre à 8 192. Si le nouveau paramètre ne permet pas de réduire le nombre d’événements `Client:ClientRead`, nous vous recommandons d’augmenter le paramètre `pkt_buf` en le définissant sur des valeurs plus élevées, telles que 16 384 ou 32 768. Si le texte de la requête est volumineux, un paramètre plus élevé peut être particulièrement utile.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.
**Topics**
+ [
### Placement des clients dans la même zone de disponibilité et le même sous-réseau VPC que l'instance
](#wait-event.clientread.actions.az-vpc-subnet)
+ [
### Procédez à la mise à l’échelle du client
](#wait-event.clientread.actions.scale-client)
+ [
### Utilisez des instances de la génération actuelle
](#wait-event.clientread.actions.db-instance-class)
+ [
### Augmentez la bande passante réseau
](#wait-event.clientread.actions.increase-network-bandwidth)
+ [
### Surveillez les valeurs maximales des métriques de performances réseau
](#wait-event.clientread.actions.monitor-network-performance)
+ [
### Surveillez les transactions dont l’état est « idle in transaction » (transaction inactive)
](#wait-event.clientread.actions.check-idle-in-transaction)
### Placement des clients dans la même zone de disponibilité et le même sous-réseau VPC que l'instance
Pour réduire la latence réseau et augmenter le débit, placez les clients dans la même zone de disponibilité et le même sous-réseau de cloud privé virtuel (VPC) que l’instance de base de données RDS pour PostgreSQL. Veillez à ce que les clients soient géographiquement aussi proches que possible de l'instance de base de données.
### Procédez à la mise à l’échelle du client
À l'aide d'Amazon CloudWatch ou d'autres indicateurs de l'hôte, déterminez si votre client est actuellement limité par le processeur ou la bande passante du réseau, ou les deux. Si le client est soumis à des contraintes, mettez-le à l’échelle en conséquence.
### Utilisez des instances de la génération actuelle
La classe d’instance de base de données que vous utilisez ne prend peut-être pas en charge les trames jumbo. Si vous exécutez votre application sur Amazon EC2, pensez à utiliser une instance de génération actuelle pour le client. Configurez également l’unité de transmission maximale (MTU) sur le système d’exploitation client. Cette technique peut réduire le nombre d’allers-retours réseau et augmenter le débit du réseau. Pour plus d’informations, consultez [Trames jumbo (MTU de 9001)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances) dans le *Guide de l’utilisateur Amazon EC2*.
Pour plus d’informations sur les classes d’instance de base de données, consultez [Classes d'instances de base de données ](Concepts.DBInstanceClass.md). Pour déterminer quelle classe d’instance de base de données est l’équivalent d’un type d’instance Amazon EC2, placez `db.` avant le nom du type d’instance Amazon EC2. Par exemple, l’instance Amazon EC2 `r5.8xlarge` est l’équivalent de la classe d’instance de base de données `db.r5.8xlarge`.
### Augmentez la bande passante réseau
Utilisez `NetworkReceiveThroughput` les CloudWatch métriques `NetworkTransmitThroughput` Amazon pour surveiller le trafic réseau entrant et sortant sur l'instance de base de données. Ces métriques peuvent vous aider à déterminer si la bande passante réseau est suffisante pour votre charge de travail.
Si la bande passante réseau est insuffisante, augmentez-la. Si le AWS client ou votre instance de base de données atteint les limites de bande passante du réseau, le seul moyen d'augmenter la bande passante est d'augmenter la taille de votre instance de base de données. Pour de plus amples informations, veuillez consulter [Types de classes d’instance de base de données](Concepts.DBInstanceClass.Types.md).
Pour plus d'informations sur CloudWatch les métriques, consultez[CloudWatch Métriques Amazon pour Amazon RDS](rds-metrics.md).
### Surveillez les valeurs maximales des métriques de performances réseau
Si vous utilisez des clients Amazon EC2, Amazon EC2 fournit des valeurs maximales pour les métriques de performances réseau, y compris pour la bande passante réseau entrante et sortante agrégée. Il assure également le suivi des connexions pour garantir un retour optimal des paquets et un accès aux services locaux de liaison pour des services tels que le système de noms de domaine (DNS). Pour surveiller ces valeurs maximales, utilisez un pilote réseau amélioré à jour et surveillez les performances réseau de votre client.
Pour plus d’informations, consultez [ Surveillance des performances réseau de votre instance Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) dans le *Guide de l’utilisateur Amazon EC2* et [Surveillance des performances réseau de votre instance Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/monitoring-network-performance-ena.html) dans le *Guide de l’utilisateur Amazon EC2*.
### Surveillez les transactions dont l’état est « idle in transaction » (transaction inactive)
Déterminez si le nombre de connexions `idle in transaction` est croissant. Pour ce faire, surveillez la colonne `state` de la table `pg_stat_activity`. Vous pouvez identifier la source des connexions en exécutant une requête semblable à la suivante.
```
select client_addr, state, count(1) from pg_stat_activity
where state like 'idle in transaction%'
group by 1,2
order by 3 desc
```
# Cliente : ClientWrite
L’événement `Client:ClientWrite` se produit quand RDS pour PostgreSQL attend d’écrire des données sur le client.
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.clientwrite.context.supported)
+ [
## Contexte
](#wait-event.clientwrite.context)
+ [
## Causes probables de l’augmentation du nombre d’événements d’attente
](#wait-event.clientwrite.causes)
+ [
## Actions
](#wait-event.clientwrite.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente sont prises en charge pour RDS pour PostgreSQL versions 10 et ultérieures.
## Contexte
Un processus client doit lire toutes les données reçues d’un cluster de bases de données RDS pour PostgreSQL avant que ce cluster puisse envoyer plus de données. La période pendant laquelle le cluster attend avant d’envoyer plus de données au client est un événement `Client:ClientWrite`.
Une diminution du débit réseau entre l’instance de base de données RDS pour PostgreSQL et le client peut provoquer cet événement. Cet événement peut également se produire lorsque le client est soumis à une pression exercée sur l’UC ou à une saturation du réseau.. On parle de *pression exercée sur l’UC* lorsque l’UC est entièrement utilisée et que des tâches attendent du temps UC. On parle de *saturation du réseau* lorsque le réseau situé entre la base de données et le client transporte plus de données qu’il ne peut en gérer.
## Causes probables de l’augmentation du nombre d’événements d’attente
Les principales causes de l’événement d’attente `Client:ClientWrite` sont les suivantes :
**Latence réseau accrue**
La latence réseau peut être accrue entre l’instance de base de données RDS pour PostgreSQL et le client. Une latence réseau plus élevée augmente le temps nécessaire au client pour recevoir les données.
**Charge accrue sur le client**
Le client peut être soumis à une pression exercée sur l’UC ou à une saturation du réseau. Une augmentation de la charge sur le client retarde la réception des données de l’instance de base de données RDS pour PostgreSQL.
**Gros volume de données envoyé au client**
L’instance de base de données RDS pour PostgreSQL peut envoyer une grande quantité de données au client. Un client peut ne pas être en mesure de recevoir les données aussi rapidement que le cluster les envoie. Certaines activités comme la copie d’une table volumineuse peuvent entraîner une augmentation des événements `Client:ClientWrite`.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.
**Topics**
+ [
### Placez les clients dans la même zone de disponibilité et le même sous-réseau VPC que le cluster
](#wait-event.clientwrite.actions.az-vpc-subnet)
+ [
### Utilisez des instances de la génération actuelle
](#wait-event.clientwrite.actions.db-instance-class)
+ [
### Réduisez la quantité de données envoyée au client
](#wait-event.clientwrite.actions.reduce-data)
+ [
### Procédez à la mise à l’échelle du client
](#wait-event.clientwrite.actions.scale-client)
### Placez les clients dans la même zone de disponibilité et le même sous-réseau VPC que le cluster
Pour réduire la latence réseau et augmenter le débit, placez les clients dans la même zone de disponibilité et le même sous-réseau de cloud privé virtuel (VPC) que l’instance de base de données RDS pour PostgreSQL.
### Utilisez des instances de la génération actuelle
La classe d’instance de base de données que vous utilisez ne prend peut-être pas en charge les trames jumbo. Si vous exécutez votre application sur Amazon EC2, pensez à utiliser une instance de génération actuelle pour le client. Configurez également l’unité de transmission maximale (MTU) sur le système d’exploitation client. Cette technique peut réduire le nombre d’allers-retours réseau et augmenter le débit du réseau. Pour plus d’informations, consultez [Trames jumbo (MTU de 9001)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances) dans le *Guide de l’utilisateur Amazon EC2*.
Pour plus d’informations sur les classes d’instance de base de données, consultez [Classes d'instances de base de données ](Concepts.DBInstanceClass.md). Pour déterminer quelle classe d’instance de base de données est l’équivalent d’un type d’instance Amazon EC2, placez `db.` avant le nom du type d’instance Amazon EC2. Par exemple, l’instance Amazon EC2 `r5.8xlarge` est l’équivalent de la classe d’instance de base de données `db.r5.8xlarge`.
### Réduisez la quantité de données envoyée au client
Lorsque cela est possible, ajustez votre application pour réduire la quantité de données que l’instance de base de données RDS pour PostgreSQL envoie au client. Ces ajustements permettent d’éviter les conflits liés à l’UC et au réseau sur le client.
### Procédez à la mise à l’échelle du client
À l'aide d'Amazon CloudWatch ou d'autres indicateurs de l'hôte, déterminez si votre client est actuellement limité par le processeur ou la bande passante du réseau, ou les deux. Si le client est soumis à des contraintes, mettez-le à l’échelle en conséquence.
# CPU
Cet événement se produit lorsqu'un thread est actif dans l'UC ou qu'il est en attente d'UC.
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.cpu.context.supported)
+ [
## Contexte
](#wait-event.cpu.context)
+ [
## Causes probables de l'augmentation du nombre d'événements d'attente
](#wait-event.cpu.causes)
+ [
## Actions
](#wait-event.cpu.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d'attente s'appliquent à toutes les versions de RDS for PostgreSQL.
## Contexte
L'*unité centrale (UC)* est le composant d'un ordinateur qui exécute les instructions. Par exemple, les instructions de l'UC effectuent des opérations arithmétiques et échangent des données en mémoire. Si une requête augmente le nombre d'instructions qu'elle exécute par le biais du moteur de base de données, le temps passé à exécuter la requête augmente. La *planification du temps UC* consiste à accorder du temps UC à un processus. La planification est orchestrée par le noyau du système d'exploitation.
**Topics**
+ [
### Comment savoir quand cette attente se produit
](#wait-event.cpu.when-it-occurs)
+ [
### DBLoadMétrique du processeur
](#wait-event.cpu.context.dbloadcpu)
+ [
### Métriques os.cpuUtilization
](#wait-event.cpu.context.osmetrics)
+ [
### Cause probable de la planification du temps UC
](#wait-event.cpu.context.scheduling)
### Comment savoir quand cette attente se produit
Cet événement d'attente `CPU` indique qu'un processus backend est actif dans l'UC ou qu'il est en attente d'UC. Cela se produit lorsqu'une requête contient les informations suivantes :
+ La colonne `pg_stat_activity.state` indique la valeur `active`.
+ Les colonnes `wait_event_type` et `wait_event` de `pg_stat_activity` indiquent toutes les deux `null`.
Pour voir les processus backend qui utilisent l'UC ou sont en attente de celle-ci, exécutez la requête suivante.
```
SELECT *
FROM pg_stat_activity
WHERE state = 'active'
AND wait_event_type IS NULL
AND wait_event IS NULL;
```
### DBLoadMétrique du processeur
La métrique Performance Insights de l'UC est `DBLoadCPU`. La valeur de `DBLoadCPU` peut être différente de celle de la CloudWatch métrique Amazon`CPUUtilization`. Cette dernière métrique est collectée à partir de HyperVisor pour une instance de base de données.
### Métriques os.cpuUtilization
Les métriques du système d'exploitation Performance Insights fournissent des informations détaillées sur l'utilisation de l'UC. Par exemple, vous pouvez afficher les métriques suivantes :
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
Performance Insights présente l'utilisation du processeur par le moteur de base de données sous la forme `os.cpuUtilization.nice.avg`.
### Cause probable de la planification du temps UC
Le noyau du système d'exploitation (SE) gère la planification pour le processeur. Quand le processeur est *actif*, il se peut qu'un processus doive attendre avant d'être planifié. Le processeur est actif pendant qu'il effectue des calculs. Il est également actif lorsqu'il possède un thread inactif qu'il n'exécute pas, c'est-à-dire qu'un thread inactif en attente de mémoire I/O. This type of I/O domine la charge de travail typique d'une base de données.
Les processus sont susceptibles d'attendre d'être planifiés sur une UC lorsque les conditions suivantes sont réunies :
+ La CloudWatch `CPUUtilization` métrique est proche de 100 %.
+ La charge moyenne est supérieure au nombre de vCPUs, ce qui indique une charge lourde. Vous trouverez la métrique `loadAverageMinute` dans la section relative aux métriques du système d'exploitation de Performance Insights.
## Causes probables de l'augmentation du nombre d'événements d'attente
Un événement d'attente UC trop fréquent peut révéler un problème de performances dont les principales causes sont les suivantes.
**Topics**
+ [
### Causes probables des pics soudains
](#wait-event.cpu.causes.spikes)
+ [
### Causes probables d'une fréquence élevée sur le long terme
](#wait-event.cpu.causes.long-term)
+ [
### Cas particuliers
](#wait-event.cpu.causes.corner-cases)
### Causes probables des pics soudains
Les causes les plus probables des pics soudains sont les suivantes :
+ Votre application a ouvert un trop grand nombre de connexions simultanées à la base de données. Ce scénario est connu sous le nom de « connection storm » (tempête de connexions).
+ La charge de travail de votre application a connu l'un des changements suivants :
+ Nouvelles requêtes
+ Augmentation de la taille du jeu de données
+ Maintenance ou création d'index
+ Nouvelles fonctions
+ Nouveaux opérateurs
+ Augmentation des exécutions de requêtes parallèles
+ Vos plans d'exécution des requêtes ont changé. Dans certains cas, un changement peut entraîner une augmentation des mémoires tampons. Par exemple, la requête utilise désormais une analyse séquentielle alors qu'elle utilisait auparavant un index. Dans ce cas, les requêtes ont besoin de plus d'UC pour atteindre le même objectif.
### Causes probables d'une fréquence élevée sur le long terme
Causes les plus probables de la répétition des événements sur une longue période :
+ Un trop grand nombre de processus backend s'exécutent simultanément sur l'UC. Ces processus peuvent être des employés parallèles.
+ Les performances des requêtes ne sont pas optimales car elles nécessitent un grand nombre de mémoires tampons.
### Cas particuliers
Si aucune des causes probables ne s'avère être la bonne, les situations suivantes peuvent se produire :
+ L'UC échange des processus en entrée et en sortie.
+ Le processeur est peut-être en train de gérer les entrées des tables de pages si la fonctionnalité *huge pages* (grandes pages) a été désactivée. Cette fonctionnalité de gestion de la mémoire est activée par défaut pour toutes les classes d'instances de base de données autres que les classes micro, petites et moyennes. Pour de plus amples informations, veuillez consulter [Grandes pages pour RDS pour PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md).
## Actions
Si l'événement d'attente `CPU` domine l'activité de la base de données, cela n'indique pas nécessairement un problème de performance. Ne réagissez à cet événement qu'en cas de dégradation des performances.
**Topics**
+ [
### Vérifiez que la base de données n'est pas à l'origine de l'augmentation du nombre d'événements d'attente UC
](#wait-event.cpu.actions.db-CPU)
+ [
### Déterminez si le nombre de connexions a augmenté
](#wait-event.cpu.actions.connections)
+ [
### Réagissez aux changements de charge de travail
](#wait-event.cpu.actions.workload)
### Vérifiez que la base de données n'est pas à l'origine de l'augmentation du nombre d'événements d'attente UC
Examinez la métrique `os.cpuUtilization.nice.avg` dans Performance Insights. Si cette valeur est bien inférieure à l'utilisation de l'UC, cela signifie que des processus non liés à la base de données contribuent majoritairement aux événements d'attente UC.
### Déterminez si le nombre de connexions a augmenté
Examinez la `DatabaseConnections` métrique sur Amazon CloudWatch. L'action à entreprendre varie selon que ce nombre augmente ou diminue pendant la période d'augmentation des événements d'attente UC.
#### Les connexions ont augmenté
Si le nombre de connexions a augmenté, comparez le nombre de processus principaux consommant du processeur au nombre de v. CPUs Les scénarios suivants sont possibles :
+ Le nombre de processus principaux consommant le processeur est inférieur au nombre de v. CPUs
Dans ce cas, le nombre de connexions n'est pas un problème. Cependant, vous pouvez toujours essayer de réduire l'utilisation de l'UC.
+ Le nombre de processus principaux consommant du processeur est supérieur au nombre de v. CPUs
Dans ce cas, procédez comme suit :
+ Réduisez le nombre de processus backend connectés à votre base de données. Par exemple, implémentez une solution de regroupement des connexions telle que RDS Proxy. Pour en savoir plus, veuillez consulter la section [Proxy Amazon RDS ](rds-proxy.md).
+ Améliorez la taille de votre instance pour obtenir un nombre plus élevé de CPUs v.
+ Redirigez certaines charges de travail en lecture seule vers des nœuds de lecture, le cas échéant.
#### Les connexions n'ont pas augmenté
Examinez les métriques `blks_hit` dans Performance Insights. Recherchez une corrélation entre une augmentation de `blks_hit` et l'utilisation de l'UC. Les scénarios possibles sont les suivants :
+ L'utilisation de l'UC et `blks_hit` sont corrélés.
Dans ce cas, recherchez les principales instructions SQL liées à l'utilisation de l'UC ainsi que les modifications apportées au plan. Vous pouvez utiliser l'une des techniques suivantes :
+ Décrivez les plans manuellement et comparez-les au plan d'exécution attendu.
+ Recherchez une augmentation des accès en bloc par seconde et des accès en bloc locaux par seconde. Dans la section **Top SQL** (Principaux éléments SQL) du tableau de bord Performance Insights, choisissez **Preferences** (Préférences).
+ L'utilisation de l'UC et `blks_hit` ne sont pas corrélés.
Dans ce cas, déterminez si l'une des situations suivantes se produit :
+ L'application se connecte et se déconnecte rapidement de la base de données.
Diagnostiquez ce comportement en activant `log_connections` et `log_disconnections`, puis en analysant les journaux PostgreSQL. Pensez à utiliser l'analyseur de journaux `pgbadger`. Pour de plus amples informations, veuillez consulter [https://github.com/darold/pgbadger](https://github.com/darold/pgbadger).
+ Le système d'exploitation est surchargé.
Dans ce cas, Performance Insights montre que les processus backend utilisent l'UC plus longtemps que d'habitude. Recherchez des preuves dans les `os.cpuUtilization` métriques Performance Insights ou dans la CloudWatch `CPUUtilization` métrique. Si le système d'exploitation est surchargé, consultez les métriques de surveillance améliorée pour approfondir le diagnostic. Plus précisément, examinez la liste des processus et le pourcentage d'UC utilisé par chaque processus.
+ Les principales instructions SQL utilisent trop d'UC.
Examinez les instructions liées à l'utilisation de l'UC pour voir si elles peuvent en utiliser moins. Exécutez une commande `EXPLAIN` et concentrez-vous sur les nœuds du plan qui ont le plus d'impact. Utilisez un visualiseur de plan d'exécution PostgreSQL. Pour essayer cet outil, consultez [http://explain.dalibo.com/](http://explain.dalibo.com/).
### Réagissez aux changements de charge de travail
Si votre charge de travail a changé, recherchez les types de changements suivants :
Nouvelles requêtes
Déterminez si les nouvelles requêtes sont attendues. Si oui, assurez-vous que leur plan d'exécution et le nombre d'exécutions par seconde sont attendus.
Augmentation de la taille du jeu de données
Déterminez si un partitionnement, s'il n'est pas déjà implémenté, peut être utile. Cette stratégie peut réduire le nombre de pages qu'une requête doit récupérer.
Maintenance ou création d'index
Vérifiez si le calendrier de maintenance est attendu. Une bonne pratique consiste à planifier des activités de maintenance en dehors des périodes de pointe.
Nouvelles fonctions
Déterminez si ces fonctions s'exécutent comme prévu lors des tests. Plus précisément, déterminez si le nombre d'exécutions par seconde est attendu.
Nouveaux opérateurs
Déterminez s'ils fonctionnent comme prévu lors des tests.
Augmentation du nombre de requêtes exécutées en parallèle
Déterminez si l'une des situations suivantes s'est produite :
+ Les relations ou index impliqués ont soudainement augmenté en termes de taille, de sorte qu'ils sont considérablement différents de `min_parallel_table_scan_size` ou `min_parallel_index_scan_size`.
+ Des modifications récentes ont été apportées à `parallel_setup_cost` ou `parallel_tuple_cost`.
+ Des modifications récentes ont été apportées à `max_parallel_workers` ou `max_parallel_workers_per_gather`.
# IO : BufFileRead et IO : BufFileWrite
Les événements `IO:BufFileRead` et `IO:BufFileWrite` se produisent quand RDS pour PostgreSQL crée des fichiers temporaires. Lorsque des opérations requièrent plus de mémoire que n'en confèrent les paramètres de mémoire de travail définis, elles écrivent des données temporaires sur un stockage permanent. Cette opération est parfois appelée *déversement sur le disque.* Pour plus d’informations sur les fichiers temporaires et leur utilisation, consultez [Gestion des fichiers temporaires avec PostgreSQL](PostgreSQL.ManagingTempFiles.md).
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.iobuffile.context.supported)
+ [
## Contexte
](#wait-event.iobuffile.context)
+ [
## Causes probables de l'augmentation du nombre d'événements d'attente
](#wait-event.iobuffile.causes)
+ [
## Actions
](#wait-event.iobuffile.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente sont prises en charge pour toutes les versions de RDS pour PostgreSQL.
## Contexte
`IO:BufFileRead` et `IO:BufFileWrite` se rapportent à la zone de mémoire de travail et à la zone de mémoire des travaux de maintenance. Pour plus d'informations sur ces zones de mémoire locale, consultez [Consommation des ressources](https://www.postgresql.org/docs/current/runtime-config-resource.html) dans la documentation PostgreSQL.
La valeur par défaut du paramètre `work_mem` est 4 Mo. Si une session effectue des opérations en parallèle, chaque application de travail gérant le parallélisme utilise 4 Mo de mémoire. Par conséquent, définissez `work_mem` prudemment. Si vous augmentez trop la valeur, une base de données exécutant plusieurs sessions peut utiliser trop de mémoire. Si vous définissez une valeur trop faible, RDS pour PostgreSQL crée des fichiers temporaires dans le stockage local. Le disque I/O contenant ces fichiers temporaires peut réduire les performances.
Si vous observez la séquence d'événements suivante, votre base de données génère peut-être des fichiers temporaires :
1. Diminution soudaine et brutale de la disponibilité
1. Récupération rapide de l'espace libre
Vous pouvez également observer un schéma en dents de scie. Ce schéma peut indiquer que votre base de données crée constamment de petits fichiers.
## Causes probables de l'augmentation du nombre d'événements d'attente
En général, ces événements d'attente sont provoqués par des opérations qui utilisent plus de mémoire que n'en allouent les paramètres `work_mem` ou `maintenance_work_mem`. Pour compenser, les opérations écrivent dans des fichiers temporaires. Les principales causes des événements `IO:BufFileRead` et `IO:BufFileWrite` sont les suivantes :
**Requêtes nécessitant plus de mémoire qu'il n'en existe dans la zone de mémoire de travail**
Les requêtes présentant les caractéristiques suivantes utilisent la zone de mémoire de travail :
+ Jointures par hachage
+ `ORDER BY`Clause
+ `GROUP BY`Clause
+ `DISTINCT`
+ Fonctions de fenêtrage
+ `CREATE TABLE AS SELECT`
+ Actualisation de la vue matérialisée
**Instructions nécessitant plus de mémoire qu'il n'en existe dans la zone de mémoire des travaux de maintenance**
Les instructions suivantes utilisent la zone de mémoire des travaux de maintenance :
+ `CREATE INDEX`
+ `CLUSTER`
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.
**Topics**
+ [
### Identifiez le problème
](#wait-event.iobuffile.actions.problem)
+ [
### Examinez vos requêtes de jointure
](#wait-event.iobuffile.actions.joins)
+ [
### Examinez vos requêtes ORDER BY et GROUP BY
](#wait-event.iobuffile.actions.order-by)
+ [
### Évitez d'utiliser l'opération DISTINCT
](#wait-event.iobuffile.actions.distinct)
+ [
### Envisagez d'utiliser des fonctions de fenêtrage à la place des fonctions GROUP BY
](#wait-event.iobuffile.actions.window)
+ [
### Examinez les vues matérialisées et les instructions CTAS
](#wait-event.iobuffile.actions.mv-refresh)
+ [
### Reconstruction des index à l'aide de pg\$1repack
](#wait-event.iobuffile.actions.pg_repack)
+ [
### Augmentez maintenance\$1work\$1mem lorsque vous mettez des tables en cluster
](#wait-event.iobuffile.actions.cluster)
+ [
### Réglez la mémoire pour empêcher les E/S : BufFileRead et E/S : BufFileWrite
](#wait-event.iobuffile.actions.tuning-memory)
### Identifiez le problème
Vous pouvez consulter l'utilisation des fichiers temporaires directement dans Performance Insights. Pour de plus amples informations, veuillez consulter [Affichage de l’utilisation des fichiers temporaires avec Performance Insights](PostgreSQL.ManagingTempFiles.Example.md). Lorsque Performance Insights est désactivé, vous remarquerez peut-être une augmentation `IO:BufFileRead` des `IO:BufFileWrite` opérations.
Pour identifier la source du problème, vous pouvez définir le paramètre `log_temp_files` de manière à consigner toutes les requêtes qui génèrent un nombre de Ko de fichiers temporaires supérieur au seuil spécifié. Par défaut, `log_temp_files` est défini sur `-1`, ce qui désactive cette fonctionnalité de journalisation. Si vous définissez ce paramètre sur `0`, RDS pour PostgreSQL consigne tous les fichiers temporaires. Si vous définissez la valeur `1024`, RDS pour PostgreSQL consigne toutes les requêtes qui produisent des fichiers temporaires de plus de 1 Mo. Pour en savoir plus sur `log_temp_files`, consultez [Error Reporting and Logging](https://www.postgresql.org/docs/current/runtime-config-logging.html) dans la documentation PostgreSQL.
### Examinez vos requêtes de jointure
Il est probable que votre requête utilise des jointures. Par exemple, la requête suivante joint quatre tables.
```
SELECT *
FROM "order"
INNER JOIN order_item
ON (order.id = order_item.order_id)
INNER JOIN customer
ON (customer.id = order.customer_id)
INNER JOIN customer_address
ON (customer_address.customer_id = customer.id AND
order.customer_address_id = customer_address.id)
WHERE customer.id = 1234567890;
```
Les pics d'utilisation des fichiers temporaires peuvent être dus à un problème dans la requête proprement dite. Par exemple, une clause rompue peut ne pas filtrer correctement les jointures. Prenons la deuxième jointure interne de l'exemple suivant.
```
SELECT *
FROM "order"
INNER JOIN order_item
ON (order.id = order_item.order_id)
INNER JOIN customer
ON (customer.id = customer.id)
INNER JOIN customer_address
ON (customer_address.customer_id = customer.id AND
order.customer_address_id = customer_address.id)
WHERE customer.id = 1234567890;
```
La requête précédente joint par erreur `customer.id` à `customer.id`, générant un produit cartésien entre chaque client et chaque commande. Ce type de jointure accidentelle génère des fichiers temporaires volumineux. Selon la taille des tables, une requête cartésienne peut même saturer le stockage. Votre application peut présenter des jointures cartésiennes lorsque les conditions suivantes sont réunies :
+ Vous observez des baisses importantes et brutales de la disponibilité du stockage, suivies d'une récupération rapide.
+ Aucun index n'est créé.
+ Aucune instruction `CREATE TABLE FROM SELECT` n'est émise.
+ Aucune vue matérialisée n'est actualisée.
Pour savoir si les tables sont jointes à l'aide des clés appropriées, examinez votre requête et les directives de mappage objet-relationnel. Gardez à l'esprit que certaines requêtes de votre application ne sont pas appelées en permanence, et que certaines requêtes sont générées dynamiquement.
### Examinez vos requêtes ORDER BY et GROUP BY
Dans certains cas, une clause `ORDER BY` peut entraîner un nombre excessif de fichiers temporaires. Considérez les directives suivantes :
+ N'incluez des colonnes dans une clause `ORDER BY` que lorsqu'elles doivent être classées. Cette directive est particulièrement importante pour les requêtes qui renvoient des milliers de lignes et spécifient de nombreuses colonnes dans la clause `ORDER BY`.
+ N'hésitez pas à créer des index pour accélérer les clauses `ORDER BY` lorsqu'elles correspondent à des colonnes qui présentent le même ordre croissant ou décroissant. Les index partiels sont préférables car ils sont plus petits. Les index de petite taille sont lus et parcourus plus rapidement.
+ Si vous créez des index pour des colonnes qui peuvent accepter des valeurs nulles, déterminez si vous souhaitez que les valeurs nulles soient stockées à la fin ou au début des index.
Si possible, réduisez le nombre de lignes à classer en filtrant l'ensemble de résultats. Si vous utilisez des instructions ou des sous-requêtes liées à la clause `WITH`, n'oubliez pas qu'une requête interne génère un ensemble de résultats et le transmet à la requête externe. Plus le nombre de lignes qu'une requête peut filtrer est élevé, moins elle a de classement à effectuer.
+ Si vous n'avez pas besoin de l'ensemble de résultats complet, utilisez la clause `LIMIT`. Par exemple, si vous avez uniquement besoin des cinq premières lignes, une requête utilisant la clause `LIMIT` ne continue pas à générer des résultats. La requête a ainsi besoin de moins de mémoire et de moins de fichiers temporaires.
Une requête qui utilise une clause `GROUP BY` peut également avoir besoin de fichiers temporaires. Les requêtes `GROUP BY` résument les valeurs à l'aide de fonctions telles que les suivantes :
+ `COUNT`
+ `AVG`
+ `MIN`
+ `MAX`
+ `SUM`
+ `STDDEV`
Pour régler les requêtes `GROUP BY`, suivez les recommandations relatives aux requêtes `ORDER BY`.
### Évitez d'utiliser l'opération DISTINCT
Dans la mesure du possible, évitez d'utiliser l'opération `DISTINCT` pour supprimer les lignes en double. Plus votre requête renvoie de lignes inutiles et en double, plus l'opération `DISTINCT` devient coûteuse. Si possible, ajoutez des filtres dans la clause `WHERE`, même si vous utilisez les mêmes filtres pour différentes tables. Un filtrage de la requête et une jointure correctes vous permettent d'améliorer les performances et de réduire l'utilisation des ressources. Ils vous permettent également d'éviter les rapports et les résultats incorrects.
Si vous devez utiliser `DISTINCT` pour plusieurs lignes d'une même table, n'hésitez pas à créer un index composite. Le regroupement de plusieurs colonnes dans un index peut améliorer le temps nécessaire à l'évaluation des lignes distinctes. De plus, si vous utilisez RDS pour PostgreSQL version 10 ou ultérieure, vous pouvez corréler les statistiques entre plusieurs colonnes à l’aide de la commande `CREATE STATISTICS`.
### Envisagez d'utiliser des fonctions de fenêtrage à la place des fonctions GROUP BY
Avec `GROUP BY`, vous modifiez l'ensemble de résultats, puis récupérez le résultat agrégé. Avec les fonctions de fenêtrage, vous pouvez agréger les données sans modifier l'ensemble de résultats. Une fonction de fenêtrage utilise la clause `OVER` pour effectuer des calculs sur les ensembles définis par la requête, en corrélant une ligne avec une autre. Les fonctions de fenêtrage vous permettent d'utiliser toutes les fonctions `GROUP BY` ainsi que les fonctions suivantes :
+ `RANK`
+ `ARRAY_AGG`
+ `ROW_NUMBER`
+ `LAG`
+ `LEAD`
Pour réduire le nombre de fichiers temporaires générés par une fonction de fenêtrage, supprimez les doublons d'un même ensemble de résultats lorsque vous avez besoin de deux agrégations distinctes. Considérons la requête suivante :
```
SELECT sum(salary) OVER (PARTITION BY dept ORDER BY salary DESC) as sum_salary
, avg(salary) OVER (PARTITION BY dept ORDER BY salary ASC) as avg_salary
FROM empsalary;
```
Vous pouvez réécrire la requête en utilisant la clause `WINDOW` comme suit.
```
SELECT sum(salary) OVER w as sum_salary
, avg(salary) OVER w as_avg_salary
FROM empsalary
WINDOW w AS (PARTITION BY dept ORDER BY salary DESC);
```
Par défaut, le planificateur d’exécution RDS pour PostgreSQL regroupe les nœuds similaires afin de ne pas dupliquer les opérations. Toutefois, en utilisant une déclaration explicite pour le bloc de fenêtres, vous pouvez gérer la requête plus facilement. Vous pouvez également améliorer les performances en empêchant la duplication.
### Examinez les vues matérialisées et les instructions CTAS
Lorsqu'une vue matérialisée est actualisée, elle exécute une requête. Cette requête peut contenir une opération telle que `GROUP BY`, `ORDER BY` ou `DISTINCT`. Lors d'une actualisation, vous pouvez observer un grand nombre de fichiers temporaires et les événements d'attente `IO:BufFileWrite` et `IO:BufFileRead`. De même, lorsque vous créez une table basée sur une instruction `SELECT`, l'instruction `CREATE TABLE` exécute une requête. Pour réduire le nombre de fichiers temporaires nécessaires, optimisez la requête.
### Reconstruction des index à l'aide de pg\$1repack
Lorsque vous créez un index, le moteur classe l'ensemble de résultats. À mesure que la taille des tables augmente et que les valeurs de la colonne indexée se diversifient, les fichiers temporaires ont besoin de plus d'espace. Dans la plupart des cas, vous ne pouvez pas empêcher la création de fichiers temporaires pour les tables volumineuses sans modifier la zone de mémoire des travaux de maintenance. Pour plus d’informations sur `maintenance_work_mem`, consultez [https://www.postgresql.org/docs/current/runtime-config-resource.html](https://www.postgresql.org/docs/current/runtime-config-resource.html) dans la documentation PostgreSQL.
Une solution de contournement possible lors de la recréation d'un index volumineux consiste à utiliser l'extension pg\$1repack. Pour en savoir plus, consultez [Reorganize tables in PostgreSQL databases with minimal locks](https://reorg.github.io/pg_repack/) dans la documentation pg\$1repack. Pour obtenir des informations sur la configuration de l’extension dans votre instance de base de données RDS pour PostgreSQL, consultez [Réduction du gonflement des tables et des index avec l’extension pg\$1repack](Appendix.PostgreSQL.CommonDBATasks.pg_repack.md).
### Augmentez maintenance\$1work\$1mem lorsque vous mettez des tables en cluster
La commande `CLUSTER` met en cluster la table spécifiée par *table\$1name* à partir d'un index existant spécifié par *index\$1name*. RDS pour PostgreSQL recrée physiquement la table en suivant l’ordre d’un index donné.
Lorsque le stockage magnétique était prédominant, la mise en cluster était courante car le débit de stockage était limité. Maintenant que le stockage SSD est plus répandu, la mise en cluster est moins fréquente. Toutefois, en mettant des tables en cluster, vous pouvez encore bénéficier d'une légère amélioration des performances en fonction de la taille de la table, de l'index, de la requête, etc.
Si vous exécutez la commande `CLUSTER` et observez les événements d'attente `IO:BufFileWrite` et `IO:BufFileRead`, réglez `maintenance_work_mem`. Augmentez la taille de la mémoire en la définissant sur une valeur relativement élevée. Une valeur élevée permettra au moteur d'utiliser davantage de mémoire pour l'opération de mise en cluster.
### Réglez la mémoire pour empêcher les E/S : BufFileRead et E/S : BufFileWrite
Dans certaines situations, vous devez régler la mémoire. Votre objectif est d'équilibrer la mémoire entre les zones de consommation suivantes à l'aide des paramètres appropriés, comme suit.
+ La valeur `work_mem`
+ La mémoire restant après déduction de la valeur `shared_buffers`
+ Nombre maximal de connexions ouvertes et en cours d'utilisation, qui est limité par `max_connections`
Pour plus d'informations sur le réglage de la mémoire, consultez [Consommation des ressources](https://www.postgresql.org/docs/current/runtime-config-resource.html) dans la documentation PostgreSQL.
#### Augmentez la taille de la zone de mémoire de travail
Dans certains cas, votre seule option consiste à augmenter la mémoire utilisée par votre session. Si vos requêtes sont correctement écrites et utilisent les bonnes clés pour les jointures, augmentez la valeur `work_mem`.
Pour savoir combien de fichiers temporaires une requête génère, définissez `log_temp_files` sur `0`. Si vous définissez la valeur `work_mem` sur la valeur maximale identifiée dans les journaux, vous empêchez la requête de générer des fichiers temporaires. Toutefois, `work_mem` définit le maximum par nœud du plan pour chaque connexion ou application de travail parallèle. Si la base de données compte 5 000 connexions, et si chacune d'entre elles utilise 256 Mio de mémoire, le moteur a besoin de 1,2 Tio de RAM. Votre instance risque donc de manquer de mémoire.
#### Réservez suffisamment de mémoire pour le groupe de mémoires tampons partagées
Votre base de données utilise des zones de mémoire telles que le groupe de mémoires tampons partagées, et pas seulement la zone de mémoire de travail. Prenez en compte les besoins de ces zones de mémoire supplémentaires avant d'augmenter `work_mem`.
Par exemple, supposons que votre classe d’instances RDS pour PostgreSQL est db.r5.2xlarge. Cette classe dispose de 64 Gio de mémoire. Par défaut, 25 % de la mémoire est réservée pour le groupe de mémoires tampons partagées. Après avoir soustrait la quantité allouée à la zone de mémoire partagée, il reste 16 384 Mo. Évitez d'allouer la mémoire restante exclusivement à la zone de mémoire de travail, car le système d'exploitation et le moteur ont également besoin de mémoire.
La mémoire que vous pouvez allouer à `work_mem` dépend de la classe d'instance. Si vous utilisez une classe d'instance plus importante, vous disposerez de plus de mémoire. Toutefois, dans l'exemple précédent, vous ne pouvez pas utiliser plus de 16 Gio. Sinon votre instance devient indisponible lorsqu'elle est à court de mémoire. Pour récupérer l’instance en cas d’indisponibilité, les services d’automatisation de RDS pour PostgreSQL redémarrent automatiquement.
#### Gérez le nombre de connexions
Supposons que votre instance de base de données compte 5 000 connexions simultanées. Chaque connexion utilise au moins 4 Mio de `work_mem`. La forte consommation de mémoire des connexions est susceptible de dégrader les performances. En réponse, vous disposez des options suivantes :
+ Passez à une classe d'instance supérieure.
+ Réduisez le nombre de connexions simultanées à la base de données à l'aide d'un proxy ou d'un regroupement de connexions.
Pour les proxies, utilisez Amazon RDS Proxy, PgBouncer ou un regroupement de connexions basé sur votre application. Cette solution réduit la charge de l'UC. Elle réduit également le risque lorsque toutes les connexions ont besoin de la zone de mémoire de travail. Lorsque les connexions à la base de données sont moins nombreuses, vous pouvez augmenter la valeur de `work_mem`. De cette façon, vous réduisez l'occurrence des événements d'attente `IO:BufFileRead` et `IO:BufFileWrite`. De plus, les requêtes en attente d'accès à la zone de mémoire de travail s'accélèrent de manière significative.
# IO : DataFileRead
L'événement `IO:DataFileRead` se produit lorsqu'une connexion attend qu'un processus backend lise une page requise à partir du stockage parce que la page n'est pas disponible dans la mémoire partagée.
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.iodatafileread.context.supported)
+ [
## Contexte
](#wait-event.iodatafileread.context)
+ [
## Causes probables de l’augmentation du nombre d’événements d’attente
](#wait-event.iodatafileread.causes)
+ [
## Actions
](#wait-event.iodatafileread.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente sont prises en charge pour toutes les versions de RDS pour PostgreSQL.
## Contexte
Toutes les requêtes et opérations en langage de manipulation de données (DML) accèdent aux pages du groupe de mémoires tampons. Les instructions qui peuvent induire des lectures sont : `SELECT`, `UPDATE` et `DELETE`. Par exemple, une instruction `UPDATE` peut lire des pages à partir de tables ou d'index. Si la page demandée ou mise à jour ne se trouve pas dans le groupe de mémoires tampons partagées, cette lecture peut provoquer l'événement `IO:DataFileRead`.
Comme le groupe de mémoires tampons partagées est limité, il peut être saturé. Dans ce cas, les requêtes de pages qui ne sont pas en mémoire forcent la base de données à lire des blocs sur le disque. Si l'événement `IO:DataFileRead` se produit fréquemment, votre groupe de mémoires tampons partagées est peut-être trop petit pour prendre en charge votre charge de travail. Ce problème se pose avec acuité pour les requêtes `SELECT` qui lisent un grand nombre de lignes qui ne rentrent pas dans le groupe de mémoires tampons. Pour plus d'informations sur le groupe de mémoires tampons, consultez [Consommation des ressources](https://www.postgresql.org/docs/current/runtime-config-resource.html) dans la documentation PostgreSQL.
## Causes probables de l’augmentation du nombre d’événements d’attente
Les principales causes de l'événement `IO:DataFileRead` sont les suivantes :
**Pics de connexion**
Il se peut que plusieurs connexions génèrent le même nombre d'événements IO : DataFileRead wait. Dans ce cas, un pic (augmentation soudaine et importante) d'événements `IO:DataFileRead` peut se produire.
**Instructions SELECT et DML effectuant des analyses séquentielles**
Votre application est peut-être en train d'effectuer une nouvelle opération. Ou une opération existante peut changer suite à un nouveau plan d'exécution. Dans ce cas, recherchez les tables (en particulier les tables volumineuses) qui présentent une valeur `seq_scan` plus élevée. Pour les trouver, interrogez `pg_stat_user_tables`. Pour suivre les requêtes qui génèrent plus d'opérations de lecture, utilisez l'extension `pg_stat_statements`.
**CTAS et CREATE INDEX pour les jeux de données volumineux**
Un *CTAS* est une instruction `CREATE TABLE AS SELECT`. Si vous exécutez un CTAS en utilisant un jeu de données volumineux comme source, ou si vous créez un index sur une table volumineuse, l'événement `IO:DataFileRead` peut se produire. Lorsque vous créez un index, la base de données peut avoir besoin de lire l'objet entier à l'aide d'une analyse séquentielle. Un CTAS génère des lectures `IO:DataFile` lorsque les pages ne sont pas en mémoire.
**Exécution simultanée de plusieurs processus employés vacuum**
Les processus employés vacuum peuvent être déclenchés manuellement ou automatiquement. Nous vous recommandons d'adopter une stratégie vacuum agressive. Toutefois, lorsqu'une table comporte de nombreuses lignes mises à jour ou supprimées, le nombre d'attentes `IO:DataFileRead` augmente. Une fois l'espace récupéré, le temps vacuum passé sur `IO:DataFileRead` diminue.
**Ingestion de grandes quantités de données**
Lorsque votre application ingère de grandes quantités de données, les opérations `ANALYZE` peuvent être plus fréquentes. Le processus `ANALYZE` peut être déclenché par un lanceur autovacuum, ou être appelé manuellement.
L'opération `ANALYZE` lit un sous-ensemble de la table. Le nombre de pages à analyser est calculé en multipliant 30 par la valeur `default_statistics_target`. Pour plus d’informations, consultez la [documentation sur PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET). Le paramètre `default_statistics_target` accepte des valeurs comprises entre 1 et 10 000, la valeur par défaut étant 100.
**Pénurie de ressources**
Si l'UC ou la bande passante réseau de l'instance sont entièrement utilisés, l'événement `IO:DataFileRead` peut se produire plus fréquemment.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.
**Topics**
+ [
### Vérifiez les filtres de prédicat pour détecter les requêtes qui génèrent des attentes
](#wait-event.iodatafileread.actions.filters)
+ [
### Minimisez l'effet des opérations de maintenance
](#wait-event.iodatafileread.actions.maintenance)
+ [
### Réagissez à un nombre élevé de connexions
](#wait-event.iodatafileread.actions.connections)
### Vérifiez les filtres de prédicat pour détecter les requêtes qui génèrent des attentes
Supposons que vous identifiez des requêtes spécifiques qui génèrent des événements d'attente `IO:DataFileRead`. Vous pouvez les identifier à l'aide des techniques suivantes :
+ Performance Insights
+ Vues catalogue telles que celles fournies par l'extension `pg_stat_statements`
+ Vue catalogue `pg_stat_all_tables`, si elle affiche périodiquement un nombre accru de lectures physiques
+ Vue `pg_statio_all_tables`, si elle montre que les compteurs `_read` sont en augmentation
Nous vous recommandons de déterminer quels filtres sont utilisés dans le prédicat (clause `WHERE`) de ces requêtes. Suivez ces instructions :
+ Exécutez la commande `EXPLAIN`. Dans la sortie, identifiez les types d'analyses utilisés. Une analyse séquentielle n'indique pas nécessairement un problème. Les requêtes qui utilisent des analyses séquentielles produisent naturellement plus d'événements `IO:DataFileRead` par rapport aux requêtes qui utilisent des filtres.
Vérifiez que la colonne répertoriée dans la clause `WHERE` est indexée. Si ce n'est pas le cas, envisagez de créer un index pour cette colonne. Cette approche évite les analyses séquentielles et réduit le nombre d'événements `IO:DataFileRead`. Si une requête comporte des filtres restrictifs et continue à produire des analyses séquentielles, assurez-vous que les index appropriés sont utilisés.
+ Déterminez si la requête accède à une table très volumineuse. Dans certains cas, le partitionnement d'une table peut améliorer les performances, en permettant à la requête de ne lire que les partitions nécessaires.
+ Examinez la cardinalité (nombre total de lignes) de vos opérations de jointure. Notez le caractère restrictif des valeurs que vous transmettez dans les filtres de la clause `WHERE`. Si possible, ajustez votre requête pour réduire le nombre de lignes transmises à chaque étape du plan.
### Minimisez l'effet des opérations de maintenance
Les opérations de maintenance telles que `VACUUM` et `ANALYZE` sont importantes. Nous vous recommandons de ne pas les désactiver parce que vous trouvez des événements d’attente `IO:DataFileRead` liés à ces opérations de maintenance. Les approches suivantes peuvent minimiser l’effet de ces opérations :
+ Exécutez les opérations de maintenance manuellement pendant les heures creuses. Cette technique empêche la base de données d'atteindre le seuil des opérations automatiques.
+ Pour les tables très volumineuses, partitionnez la table. Cette technique permet de réduire les frais liés aux opérations de maintenance. La base de données accède uniquement aux partitions qui nécessitent une maintenance.
+ Lorsque vous intégrez de grandes quantités de données, pensez à désactiver la fonction d'analyse automatique.
La fonction autovacuum est automatiquement déclenchée pour une table lorsque la formule suivante est vraie.
```
pg_stat_user_tables.n_dead_tup > (pg_class.reltuples x autovacuum_vacuum_scale_factor) + autovacuum_vacuum_threshold
```
La vue `pg_stat_user_tables` et le catalogue `pg_class` comportent plusieurs lignes. Une ligne peut correspondre à une ligne de votre table. Cette formule suppose que les `reltuples` sont destinés à une table spécifique. Les paramètres `autovacuum_vacuum_scale_factor` (0,20 par défaut) et `autovacuum_vacuum_threshold` (50 tuples par défaut) sont généralement définis globalement pour l'ensemble de l'instance. Vous pouvez toutefois définir des valeurs différentes pour une table spécifique.
**Topics**
+ [
#### Recherche des tables qui consomment de l'espace inutilement
](#wait-event.iodatafileread.actions.maintenance.tables)
+ [
#### Recherche des index qui consomment de l'espace inutilement
](#wait-event.iodatafileread.actions.maintenance.indexes)
+ [
#### Recherchez les tables éligibles au processus autovacuum
](#wait-event.iodatafileread.actions.maintenance.autovacuumed)
#### Recherche des tables qui consomment de l'espace inutilement
Pour rechercher les tables qui consomment inutilement de l'espace, vous pouvez utiliser les fonctions issues de l'extension PostgreSQL `pgstattuple`. Cette extension (module) est disponible par défaut sur toutes les instances de base de données RDS for PostgreSQL et peut être instanciée sur l'instance à l'aide de la commande suivante.
```
CREATE EXTENSION pgstattuple;
```
Pour plus d'informations sur cette extension, consultez [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html) dans la documentation PostgreSQL.
Vous pouvez vérifier qu'il n'existe pas de gonflement de tables et d'index dans votre application. Pour en savoir plus, consultez [Diagnostic du gonflement de la table et de l'index](https://docs.aws.amazon.com//AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html).
#### Recherche des index qui consomment de l'espace inutilement
Pour rechercher les index gonflés et estimer la quantité d'espace inutilement consommée sur les tables pour lesquelles vous disposez de privilèges de lecture, vous pouvez exécuter la requête suivante.
```
-- WARNING: rows with is_na = 't' are known to have bad statistics ("name" type is not supported).
-- This query is compatible with PostgreSQL 8.2 and later.
SELECT current_database(), nspname AS schemaname, tblname, idxname, bs*(relpages)::bigint AS real_size,
bs*(relpages-est_pages)::bigint AS extra_size,
100 * (relpages-est_pages)::float / relpages AS extra_ratio,
fillfactor, bs*(relpages-est_pages_ff) AS bloat_size,
100 * (relpages-est_pages_ff)::float / relpages AS bloat_ratio,
is_na
-- , 100-(sub.pst).avg_leaf_density, est_pages, index_tuple_hdr_bm,
-- maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, sub.reltuples, sub.relpages
-- (DEBUG INFO)
FROM (
SELECT coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata-pagehdr)/(4+nulldatahdrwidth)::float)), 0
-- ItemIdData size + computed avg size of a tuple (nulldatahdrwidth)
) AS est_pages,
coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata-pagehdr)*fillfactor/(100*(4+nulldatahdrwidth)::float))), 0
) AS est_pages_ff,
bs, nspname, table_oid, tblname, idxname, relpages, fillfactor, is_na
-- , stattuple.pgstatindex(quote_ident(nspname)||'.'||quote_ident(idxname)) AS pst,
-- index_tuple_hdr_bm, maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, reltuples
-- (DEBUG INFO)
FROM (
SELECT maxalign, bs, nspname, tblname, idxname, reltuples, relpages, relam, table_oid, fillfactor,
( index_tuple_hdr_bm +
maxalign - CASE -- Add padding to the index tuple header to align on MAXALIGN
WHEN index_tuple_hdr_bm%maxalign = 0 THEN maxalign
ELSE index_tuple_hdr_bm%maxalign
END
+ nulldatawidth + maxalign - CASE -- Add padding to the data to align on MAXALIGN
WHEN nulldatawidth = 0 THEN 0
WHEN nulldatawidth::integer%maxalign = 0 THEN maxalign
ELSE nulldatawidth::integer%maxalign
END
)::numeric AS nulldatahdrwidth, pagehdr, pageopqdata, is_na
-- , index_tuple_hdr_bm, nulldatawidth -- (DEBUG INFO)
FROM (
SELECT
i.nspname, i.tblname, i.idxname, i.reltuples, i.relpages, i.relam, a.attrelid AS table_oid,
current_setting('block_size')::numeric AS bs, fillfactor,
CASE -- MAXALIGN: 4 on 32bits, 8 on 64bits (and mingw32 ?)
WHEN version() ~ 'mingw32' OR version() ~ '64-bit|x86_64|ppc64|ia64|amd64' THEN 8
ELSE 4
END AS maxalign,
/* per page header, fixed size: 20 for 7.X, 24 for others */
24 AS pagehdr,
/* per page btree opaque data */
16 AS pageopqdata,
/* per tuple header: add IndexAttributeBitMapData if some cols are null-able */
CASE WHEN max(coalesce(s.null_frac,0)) = 0
THEN 2 -- IndexTupleData size
ELSE 2 + (( 32 + 8 - 1 ) / 8)
-- IndexTupleData size + IndexAttributeBitMapData size ( max num filed per index + 8 - 1 /8)
END AS index_tuple_hdr_bm,
/* data len: we remove null values save space using it fractionnal part from stats */
sum( (1-coalesce(s.null_frac, 0)) * coalesce(s.avg_width, 1024)) AS nulldatawidth,
max( CASE WHEN a.atttypid = 'pg_catalog.name'::regtype THEN 1 ELSE 0 END ) > 0 AS is_na
FROM pg_attribute AS a
JOIN (
SELECT nspname, tbl.relname AS tblname, idx.relname AS idxname,
idx.reltuples, idx.relpages, idx.relam,
indrelid, indexrelid, indkey::smallint[] AS attnum,
coalesce(substring(
array_to_string(idx.reloptions, ' ')
from 'fillfactor=([0-9]+)')::smallint, 90) AS fillfactor
FROM pg_index
JOIN pg_class idx ON idx.oid=pg_index.indexrelid
JOIN pg_class tbl ON tbl.oid=pg_index.indrelid
JOIN pg_namespace ON pg_namespace.oid = idx.relnamespace
WHERE pg_index.indisvalid AND tbl.relkind = 'r' AND idx.relpages > 0
) AS i ON a.attrelid = i.indexrelid
JOIN pg_stats AS s ON s.schemaname = i.nspname
AND ((s.tablename = i.tblname AND s.attname = pg_catalog.pg_get_indexdef(a.attrelid, a.attnum, TRUE))
-- stats from tbl
OR (s.tablename = i.idxname AND s.attname = a.attname))
-- stats from functional cols
JOIN pg_type AS t ON a.atttypid = t.oid
WHERE a.attnum > 0
GROUP BY 1, 2, 3, 4, 5, 6, 7, 8, 9
) AS s1
) AS s2
JOIN pg_am am ON s2.relam = am.oid WHERE am.amname = 'btree'
) AS sub
-- WHERE NOT is_na
ORDER BY 2,3,4;
```
#### Recherchez les tables éligibles au processus autovacuum
Pour rechercher les tables éligibles au processus autovacuum, exécutez la requête suivante.
```
--This query shows tables that need vacuuming and are eligible candidates.
--The following query lists all tables that are due to be processed by autovacuum.
-- During normal operation, this query should return very little.
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold
FROM pg_settings WHERE name = 'autovacuum_vacuum_threshold')
, vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor
FROM pg_settings WHERE name = 'autovacuum_vacuum_scale_factor')
, fma AS (SELECT setting AS autovacuum_freeze_max_age
FROM pg_settings WHERE name = 'autovacuum_freeze_max_age')
, sto AS (SELECT opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value
FROM (SELECT oid opt_oid, unnest(reloptions) setting FROM pg_class) opt)
SELECT
'"'||ns.nspname||'"."'||c.relname||'"' as relation
, pg_size_pretty(pg_table_size(c.oid)) as table_size
, age(relfrozenxid) as xid_age
, coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age
, (coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
as autovacuum_vacuum_tuples
, n_dead_tup as dead_tuples
FROM pg_class c
JOIN pg_namespace ns ON ns.oid = c.relnamespace
JOIN pg_stat_all_tables stat ON stat.relid = c.oid
JOIN vbt on (1=1)
JOIN vsf ON (1=1)
JOIN fma on (1=1)
LEFT JOIN sto cvbt ON cvbt.param = 'autovacuum_vacuum_threshold' AND c.oid = cvbt.opt_oid
LEFT JOIN sto cvsf ON cvsf.param = 'autovacuum_vacuum_scale_factor' AND c.oid = cvsf.opt_oid
LEFT JOIN sto cfma ON cfma.param = 'autovacuum_freeze_max_age' AND c.oid = cfma.opt_oid
WHERE c.relkind = 'r'
AND nspname <> 'pg_catalog'
AND (
age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
or
coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples <= n_dead_tup
-- or 1 = 1
)
ORDER BY age(relfrozenxid) DESC;
```
### Réagissez à un nombre élevé de connexions
Lorsque vous surveillez Amazon CloudWatch, vous constaterez peut-être que les `DatabaseConnections` statistiques augmentent. Cette augmentation indique un nombre accru de connexions à votre base de données. Nous vous recommandons l'approche suivante :
+ Limitez le nombre de connexions que l'application peut ouvrir avec chaque instance. Si votre application dispose d'une fonction intégrée de regroupement des connexions, définissez-la sur un nombre raisonnable de connexions. Basez le nombre sur ce que le v CPUs de votre instance peut paralléliser efficacement.
Si votre application n'utilise pas de fonction de regroupement des connexions, envisagez d'utiliser un proxy Amazon RDS ou une autre solution. Cette approche permet à votre application d'ouvrir plusieurs connexions à l'aide de l'équilibreur de charge. L'équilibreur peut alors ouvrir un nombre restreint de connexions avec la base de données. Comme le nombre de connexions exécutées en parallèle est moindre, votre instance de base de données effectue moins de changements de contexte dans le noyau. Les requêtes progressent plus rapidement, ce qui entraîne une diminution des événements d'attente. Pour de plus amples informations, veuillez consulter [Proxy Amazon RDS ](rds-proxy.md).
+ Dans la mesure du possible, tirez parti des réplicas en lecture pour RDS for PostgreSQL. Lorsque votre application exécute une opération en lecture seule, envoyez ces demandes aux réplicas en lecture. Cette technique réduit la I/O pression sur le nœud principal (écrivain).
+ Envisagez une augmentation d'échelle de votre instance de base de données. Une classe d'instances de plus grande capacité offre davantage de mémoire, ce qui permet à RDS for PostgreSQL de disposer d'un groupe de mémoires tampons partagées plus important pour stocker les pages. La plus grande taille donne également à l'instance de base de données plus CPUs de v pour gérer les connexions. More v CPUs est particulièrement utile lorsque les opérations qui génèrent des événements d'`IO:DataFileRead`attente sont des écritures.
# IO:WALWrite
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.iowalwrite.context.supported)
+ [
## Contexte
](#wait-event.iowalwrite.context)
+ [
## Causes probables de l’augmentation du nombre d’événements d’attente
](#wait-event.iowalwrite.causes)
+ [
## Actions
](#wait-event.iowalwrite.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente sont prises en charge pour RDS pour PostgreSQL versions 10 et ultérieures.
## Contexte
L'activité de la base de données qui génère les données WAL remplit d'abord les tampons WAL, puis écrit sur le disque de manière asynchrone. L'événement d'attente `IO:WALWrite` est généré quand la session SQL attend la fin de l'écriture des données WAL sur le disque afin de pouvoir libérer l'appel COMMIT de la transaction.
## Causes probables de l’augmentation du nombre d’événements d’attente
Si cet événement d'attente se produit souvent, vous devez examiner votre charge de travail, le type des mises à jour effectuées par votre charge de travail et leur fréquence. En particulier, recherchez les types d'activités suivants.
**Activité DML intense**
La modification des données dans les tables de base de données ne se produit pas instantanément. Une insertion dans une table peut nécessiter l'attente d'une insertion ou d'une mise à jour dans la même table par un autre client. Les instructions du langage de manipulation de données (DML) permettant de modifier les valeurs des données (INSERT, UPDATE, DELETE, COMMIT, ROLLBACK TRANSACTION) peuvent provoquer des conflits qui obligent le fichier WAL à attendre que les tampons soient vidés. Cette situation est capturée dans les métriques Analyse des performances d'Amazon RDS suivantes, qui indiquent une activité DML intense.
+ `tup_inserted`
+ `tup_updated`
+ `tup_deleted`
+ `xact_rollback`
+ `xact_commit`
Pour plus d’informations sur ces métriques, consultez [Compteurs Performance Insights pour Amazon RDS pour PostgreSQL](USER_PerfInsights_Counters.md#USER_PerfInsights_Counters.PostgreSQL).
**Activité des points de vérification fréquents**
Les points de contrôle fréquents contribuent à augmenter le nombre de fichiers WAL. Dans RDS pour PostgreSQL, les écritures de pages complètes sont toujours « activées ». Les écritures de pages complètes favorisent la protection contre les pertes de données. Toutefois, lorsque les points de vérification sont trop fréquents, le système peut rencontrer des problèmes de performances globales. Cela est particulièrement vrai sur les systèmes à activité DML intense. Dans certains cas, vous pouvez trouver des messages d'erreur dans votre fichier `postgresql.log` indiquant que « les points de vérification se produisent trop fréquemment ».
Lors du réglage des points de vérification, nous vous recommandons de bien équilibrer les performances par rapport au temps nécessaire prévu pour récupérer en cas d'arrêt anormal.
## Actions
Nous recommandons les actions suivantes pour réduire le nombre de cet événement d'attente.
**Topics**
+ [
### Réduisez le nombre de validations
](#wait-event.iowalwrite.actions.problem)
+ [
### Surveillance de vos points de vérification
](#wait-event.iowalwrite.actions.monitor)
+ [
### Augmenter les E/S
](#wait-event.iowalwrite.actions.scale-io)
+ [
### Volume dédié aux journaux (DLV)
](#wait-event.iowalwrite.actions.dlv)
### Réduisez le nombre de validations
Pour réduire le nombre de validations, vous pouvez combiner les instructions en blocs de transactions. Utilisez Analyse des performances d'Amazon RDS pour examiner le type des requêtes en cours d'exécution. Vous pouvez également déplacer les opérations de maintenance importantes à des heures creuses. Par exemple, créez des index ou utilisez les opérations `pg_repack` en dehors des heures de production.
### Surveillance de vos points de vérification
Vous pouvez surveiller deux paramètres pour voir à quelle fréquence votre instance de base de données RDS pour PostgreSQL écrit dans le fichier WAL pour les points de vérification.
+ `log_checkpoints` – Ce paramètre est « activé » par défaut. Il provoque l'envoi d'un message au journal PostgreSQL pour chaque point de vérification. Ces messages de journal incluent le nombre de tampons écrits, le temps passé à les écrire et le nombre de fichiers WAL ajoutés, supprimés ou recyclés pour le point de vérification donné.
Pour plus d'informations sur ce paramètre, consultez [Error Reporting and Logging](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-CHECKPOINTS) (Signalisation et journalisation des erreurs) dans la documentation PostgreSQL.
+ `checkpoint_warning` – Ce paramètre définit une valeur seuil (en secondes) pour la fréquence des points de vérification, au-dessus de laquelle un avertissement est généré. Par défaut, ce paramètre n’est pas défini dans RDS pour PostgreSQL. Vous pouvez définir la valeur de ce paramètre pour recevoir un avertissement lorsque les modifications de base de données dans votre instance de base de données RDS pour PostgreSQL sont écrites à une vitesse que les fichiers WAL ne sont pas dimensionnés pour gérer. Par exemple, supposons que vous définissiez ce paramètre sur 30. Si votre instance RDS pour PostgreSQL doit écrire des modifications plus souvent que toutes les 30 secondes, l’avertissement indiquant que « les points de vérification se produisent trop fréquemment » est envoyé dans le journal PostgreSQL. Cela peut indiquer que votre valeur `max_wal_size` doit être augmentée.
Pour plus d'informations, consultez [Write Ahead Log](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS) dans la documentation PostgreSQL.
### Augmenter les E/S
Ce type d'événement d'attente d'entrée/sortie (E/S) peut être corrigé en mettant à l'échelle les opérations d'entrée/sortie par seconde (IOPS) afin de fournir plus rapidement les E/S. La mise à l'échelle des E/S est préférable à la mise à l'échelle du processeur, car la mise à l'échelle du processeur peut entraîner encore plus de conflits d'E/S en gérant plus de travail et aggraver ainsi le goulot d'étranglement d'E/S. En règle générale, nous recommandons d'envisager le réglage de votre charge de travail avant d'exécuter des opérations de mise à l'échelle.
### Volume dédié aux journaux (DLV)
Vous pouvez utiliser un volume dédié aux journaux (DLV) pour une instance de base de données qui utilise le stockage IOPS provisionnés (PIOPS) en utilisant la console Amazon RDS, l’AWS CLI ou l’API Amazon RDS. Un DLV déplace les journaux de transactions de base de données vers un volume de stockage distinct du volume contenant les tables de base de données. Pour plus d’informations, consultez [Volume dédié aux journaux (DLV)](CHAP_Storage.md#CHAP_Storage.dlv).
# IPC:parallel wait events
Les événements `IPC:parallel wait events` suivants indiquent qu’une session est en attente d’une communication interprocessus liée aux opérations d’exécution de requêtes parallèles.
+ `IPC:BgWorkerStartup` : un processus attend qu’un processus de travail parallèle termine sa séquence de démarrage. Cela se produit lors de l’initialisation des applications de travail pour l’exécution de requêtes parallèles.
+ `IPC:BgWorkerShutdown` : un processus attend la fin de la séquence d’arrêt d’un processus de travail parallèle. Cela se produit pendant la phase de nettoyage de l’exécution de requêtes parallèles.
+ `IPC:ExecuteGather` : un processus attend de recevoir des données de processus de travail en parallèle pendant l’exécution de la requête. Cela se produit lorsque le processus principal doit recueillir des résultats auprès de ses applications de travail.
+ `IPC:ParallelFinish` : un processus attend que les applications de travail en parallèle terminent leur exécution et publient leurs résultats finaux. Cela se produit pendant la phase de finalisation de l’exécution des requêtes parallèles.
**Topics**
+ [
## Versions de moteur prises en charge
](#rpg-ipc-parallel-context-supported)
+ [
## Contexte
](#rpg-ipc-parallel-context)
+ [
## Causes probables de l’augmentation du nombre d’événements d’attente
](#rpg-ipc-parallel-causes)
+ [
## Actions
](#rpg-ipc-parallel-actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente s’appliquent à toutes les versions d’Aurora PostgreSQL.
## Contexte
L’exécution de requêtes parallèles dans PostgreSQL implique la collaboration de plusieurs processus pour le traitement d’une seule requête. Lorsqu’une requête est jugée appropriée pour la parallélisation, un processus principal est coordonné avec un ou plusieurs processus de travail en parallèle en fonction du réglage du paramètre `max_parallel_workers_per_gather`. Le processus principal répartit le travail entre les applications de travail, chaque application de travail traite sa partie des données de manière indépendante et les résultats sont renvoyés au processus principal.
**Note**
Chaque application de travail en parallèle fonctionne comme un processus distinct dont les besoins en ressources sont similaires à ceux d’une session utilisateur complète. Cela signifie qu'une requête parallèle avec 4 travailleurs peut consommer jusqu'à 5 fois plus de ressources (processeur, mémoire, I/O bande passante) par rapport à une requête non parallèle, car le processus principal et chaque processus de travail conservent leurs propres allocations de ressources. Par exemple, des paramètres tels que `work_mem` sont appliqués individuellement à chaque application de travail, multipliant potentiellement l’utilisation totale de la mémoire entre tous les processus.
L’architecture des requêtes parallèles comprend trois composants principaux :
+ Processus principal : processus clé qui initie l’opération en parallèle, répartit la charge de travail et assure la coordination avec les processus de travail.
+ Processus de travail : processus d’arrière-plan qui exécutent des parties de la requête parallèle.
+ Fusion Gather/Gather : opérations qui combinent les résultats de plusieurs processus de travail pour les renvoyer au processus principal.
Lors d’une exécution en parallèle, les processus doivent communiquer entre eux par le biais de mécanismes de communication interprocessus (IPC). Ces événements d’attente IPC se produisent au cours de différentes phases :
+ Démarrage des applications de travail : lorsque des applications de travail en parallèle sont initialisées
+ Échange de données : lorsque les applications de travail traitent les données et envoient les résultats au processus principal
+ Arrêt des applications de travail : lorsque l’exécution en parallèle est terminée et que les applications de travail sont arrêtées
+ Points de synchronisation : lorsque les processus doivent se coordonner ou attendre que d’autres processus terminent leurs tâches
Il est essentiel de comprendre ces événements d’attente pour pouvoir résoudre les problèmes de performances liés à l’exécution de requêtes parallèles, en particulier dans les environnements à forte concurrence dans lesquels plusieurs requêtes parallèles peuvent s’exécuter simultanément.
## Causes probables de l’augmentation du nombre d’événements d’attente
Plusieurs facteurs peuvent contribuer à augmenter le nombre d’événements d’attente IPC liés à l’exécution de requêtes parallèles :
**Forte concurrence des requêtes parallèles**
Lorsque de nombreuses requêtes parallèles sont exécutées simultanément, cela peut entraîner une contention des ressources et une augmentation des temps d’attente pour les opérations IPC. Cela est particulièrement courant dans les systèmes impliquant des volumes de transactions ou des charges de travail analytiques élevés.
**Plans de requêtes parallèles sous-optimaux**
Si le planificateur de requêtes choisit des plans de requêtes parallèles inefficaces, cela peut entraîner une parallélisation inutile ou une mauvaise répartition du travail entre les applications de travail. Cela peut entraîner une augmentation des temps d’attente IPC, en particulier pour les événements `IPC:ExecuteGather` et `IPC:ParallelFinish`. Ces problèmes de planification sont souvent dus à des statistiques périmées et table/index à des excès.
**Démarrage et arrêt fréquents des applications de travail en parallèle**
Les requêtes de courte durée qui déclenchent et interrompent fréquemment des applications de travail en parallèle peuvent entraîner une augmentation du nombre d’événements `IPC:BgWorkerStartup` et `IPC:BgWorkerShutdown`. Cela se produit souvent dans les charges de travail OLTP, qui impliquent beaucoup de petites requêtes pouvant être exécutées en parallèle.
**Contraintes liées aux ressources**
Un processeur, une mémoire ou une I/O capacité limités peuvent entraîner des blocages lors de l'exécution en parallèle, ce qui augmente les temps d'attente pour tous les événements IPC. Par exemple, si le processeur est saturé, les processus de travail peuvent mettre plus de temps à démarrer ou à traiter leur part du travail.
**Structures de requête complexes**
Les requêtes comportant plusieurs niveaux de parallélisme (jointures en parallèle suivies d’agrégations parallèles, par exemple) peuvent entraîner des modèles IPC plus complexes et des temps d’attente potentiellement accrus, en particulier pour les événements `IPC:ExecuteGather`.
**Ensembles de résultats volumineux**
Les requêtes qui génèrent des ensembles de résultats volumineux peuvent entraîner une augmentation des temps d’attente `IPC:ExecuteGather`, car le processus principal passe plus de temps à collecter et à traiter les résultats des processus de travail.
La compréhension de ces facteurs peut aider à diagnostiquer et à résoudre les problèmes de performances liés à l’exécution de requêtes parallèles dans Aurora PostgreSQL.
## Actions
Lorsque vous voyez des temps d’attente liés à une requête parallèle, cela signifie généralement qu’un processus dorsal coordonne ou attend des processus de travail parallèles. Ces temps d’attente sont courants lors de l’exécution de plans en parallèle. Vous pouvez étudier et atténuer l’impact de ces temps d’attente en surveillant l’utilisation des applications de travail en parallèle, en vérifiant les paramètres et en ajustant l’exécution des requêtes et l’allocation des ressources.
**Topics**
+ [
### Analyse des plans de requêtes pour détecter un parallélisme inefficace
](#rpg-ipc-parallel-analyze-plans)
+ [
### Surveillance de l’utilisation des requêtes parallèles
](#rpg-ipc-parallel-monitor)
+ [
### Vérification et ajustement des paramètres des requêtes parallèles
](#rpg-ipc-parallel-adjust-settings)
+ [
### Optimisation de l’allocation des ressources
](#rpg-ipc-parallel-optimize-resources)
+ [
### Vérification de la gestion des connexions
](#rpg-ipc-parallel-connection-management)
+ [
### Vérification et optimisation des opérations de maintenance
](#rpg-ipc-parallel-maintenance)
### Analyse des plans de requêtes pour détecter un parallélisme inefficace
L’exécution de requêtes parallèles peut souvent entraîner une instabilité du système, des pics de processeur et des variations imprévisibles des performances des requêtes. Il est essentiel d’analyser de manière approfondie si le parallélisme améliore réellement votre charge de travail spécifique. Utilisez EXPLAIN ANALYZE pour passer en revue les plans d’exécution de requêtes parallèles.
Désactivez temporairement le parallélisme au niveau de la session pour comparer l’efficacité du plan :
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
```
Réactivez le parallélisme et comparez :
```
RESET max_parallel_workers_per_gather;
EXPLAIN ANALYZE ;
```
Si la désactivation du parallélisme donne des résultats meilleurs ou plus cohérents, envisagez de le désactiver pour des requêtes spécifiques au niveau de la session à l’aide des commandes SET. Pour un impact plus large, vous pouvez désactiver le parallélisme au niveau de l’instance en ajustant les paramètres pertinents dans le groupe de paramètres de votre base de données. Pour plus d’informations, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Surveillance de l’utilisation des requêtes parallèles
Utilisez les requêtes suivantes pour avoir une meilleure visibilité sur l’activité et la capacité des requêtes parallèles :
Vérifiez les processus de travail en parallèle actifs :
```
SELECT
COUNT(*)
FROM
pg_stat_activity
WHERE
backend_type = 'parallel worker';
```
Cette requête indique le nombre de processus de travail en parallèle actifs. Une valeur élevée peut indiquer que le paramètre max\$1parallel\$1workers est configuré avec une valeur élevée, ce que vous pouvez choisir de réduire.
Vérifiez les requêtes parallèles simultanées :
```
SELECT
COUNT(DISTINCT leader_pid)
FROM
pg_stat_activity
WHERE
leader_pid IS NOT NULL;
```
Cette requête renvoie le nombre de processus principaux distincts qui ont lancé des requêtes parallèles. Un nombre élevé indique que plusieurs sessions exécutent des requêtes parallèles simultanément, ce qui peut augmenter la demande en termes de processeur et de mémoire.
### Vérification et ajustement des paramètres des requêtes parallèles
Passez en revue les paramètres suivants pour vous assurer qu’ils correspondent à votre charge de travail :
+ `max_parallel_workers` : nombre total d’applications de travail en parallèle entre toutes les sessions.
+ `max_parallel_workers_per_gather` : nombre maximum d’applications de travail par requête.
Pour les charges de travail OLAP, l’augmentation de ces valeurs peut améliorer les performances. Pour les charges de travail OLTP, des valeurs plus faibles sont généralement préférées.
```
SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;
```
### Optimisation de l’allocation des ressources
Surveillez l'utilisation du processeur et envisagez d'ajuster le nombre de v CPUs s'il est constamment élevé et si votre application bénéficie de requêtes parallèles. Assurez-vous que la mémoire disponible est suffisante pour les opérations en parallèle.
+ Utilisez les métriques Performance Insights pour déterminer si le système est lié au processeur.
+ Chaque application de travail en parallèle utilise sa propre `work_mem`. Assurez-vous que l’utilisation totale de la mémoire respecte les limites de l’instance.
Les requêtes parallèles peuvent consommer beaucoup plus de ressources que les requêtes qui ne sont pas exécutées en parallèle, car chaque processus de travail est un processus complètement distinct qui a à peu près le même impact sur le système qu’une session utilisateur supplémentaire. Cela doit être pris en compte lors du choix d’une valeur pour ce paramètre, ainsi que lors de la configuration des autres paramètres contrôlant l’utilisation des ressources, tels que `work_mem`. Pour plus d’informations, consultez la [documentation sur PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Les limites de ressources telles que `work_mem` sont appliquées individuellement à chaque application de travail, ce qui signifie que l’utilisation totale peut être beaucoup plus élevée entre tous les processus qu’elle ne le serait normalement pour un seul processus.
Envisagez d'augmenter v CPUs ou de régler les paramètres de mémoire si votre charge de travail est fortement parallélisée.
### Vérification de la gestion des connexions
En cas de saturation des connexions, passez en revue les stratégies de regroupement des connexions des applications. Envisagez d’implémenter le regroupement de connexions au niveau de l’application s’il n’est pas déjà utilisé.
### Vérification et optimisation des opérations de maintenance
Coordonnez la création d’index et les autres tâches de maintenance pour éviter les conflits de ressources. Pensez à planifier ces opérations pendant les heures creuses. Évitez de planifier de lourdes opérations de maintenance (par exemple, des constructions d’index en parallèle) pendant les périodes de forte charge des requêtes utilisateur. Ces opérations peuvent consommer des applications de travail en parallèle et avoir un impact sur les performances des requêtes régulières.
# IPC : ProcArrayGroupUpdate
L'`IPC:ProcArrayGroupUpdate`événement se produit lorsqu'une session attend que le chef de groupe mette à jour le statut de la transaction à la fin de cette opération. Alors que PostgreSQL associe généralement les événements d'attente de type IPC aux opérations de requêtes parallèles, cet événement d'attente particulier n'est pas spécifique aux requêtes parallèles.
**Topics**
+ [
## Versions de moteur prises en charge
](#apg-rpg-ipcprocarraygroup.supported)
+ [
## Contexte
](#apg-rpg-ipcprocarraygroup.context)
+ [
## Causes probables de l’augmentation du nombre d’événements d’attente
](#apg-rpg-ipcprocarraygroup.causes)
+ [
## Actions
](#apg-rpg-ipcprocarraygroup.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente sont prises en charge pour toutes les versions de RDS pour PostgreSQL.
## Contexte
**Comprendre le tableau de processus** — Le tableau de processus (proc) est une structure de mémoire partagée dans PostgreSQL. Il contient des informations sur tous les processus en cours, y compris les détails des transactions. Au cours de la fin de la transaction (`COMMIT`ou`ROLLBACK`), il ProcArray doit être mis à jour pour refléter le changement et effacer le TransactionID du tableau. La session qui tente de terminer sa transaction doit acquérir un verrou exclusif sur le ProcArray. Cela empêche d'autres processus d'obtenir des verrous partagés ou exclusifs sur celui-ci.
**Mécanisme de mise à jour de groupe** — Lors de l'exécution d'un COMMIT ou d'un ROLLBACK, si un processus principal ne parvient pas à obtenir un ProcArrayLock code en mode exclusif, il met à jour un champ spécial appelé. ProcArrayGroupMember Cela ajoute la transaction à la liste des sessions qui ont l'intention de se terminer. Ce processus principal est ensuite mis en veille et le temps qu'il passe en veille est instrumenté comme événement d' ProcArrayGroupUpdate attente. Le premier processus du ProcArray with procArrayGroup Member, appelé processus leader, acquiert ProcArrayLock le mode exclusif. Il efface ensuite la liste des processus en attente d'effacement de l'identifiant de transaction du groupe. Une fois cette opération terminée, le leader libère ProcArrayLock puis réveille tous les processus de cette liste, les informant que leur transaction est terminée.
## Causes probables de l’augmentation du nombre d’événements d’attente
Plus le nombre de processus en cours d'exécution est élevé, plus un leader conservera longtemps un procArrayLock mode exclusif. Par conséquent, plus le nombre de transactions d'écriture aboutit à un scénario de mise à jour de groupe, ce qui entraîne une accumulation potentielle de processus en attente de l'événement d'`ProcArrayGroupUpdate`attente. Dans la vue SQL principale de Database Insights, vous verrez que COMMIT est l'instruction présentant la majeure partie de cet événement d'attente. Cela est normal, mais cela nécessitera une étude plus approfondie du code SQL d'écriture spécifique en cours d'exécution afin de déterminer les mesures appropriées à prendre.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente. Identifiez les `IPC:ProcArrayGroupUpdate` événements à l'aide d'Amazon RDS Performance Insights ou en interrogeant la vue système de PostgreSQL. `pg_stat_activity`
**Topics**
+ [
### Surveillance des opérations de validation et d'annulation des transactions
](#apg-rpg-ipcprocarraygroup.actions.monitor)
+ [
### Réduire la simultanéité
](#apg-rpg-ipcprocarraygroup.actions.concurrency)
+ [
### Mise en œuvre du regroupement de connexions
](#apg-rpg-ipcprocarraygroup.actions.pooling)
+ [
### Utilisation d'un stockage plus rapide
](#apg-rpg-ipcprocarraygroup.actions.storage)
### Surveillance des opérations de validation et d'annulation des transactions
**Surveillez les validations et les annulations** — L'augmentation du nombre de validations et de annulations peut entraîner une pression accrue sur le. ProcArray Par exemple, si une instruction SQL commence à échouer en raison d'une augmentation du nombre de violations de clés dupliquées, vous pouvez assister à une augmentation des annulations, ce qui peut accroître les ProcArray contentions et le surpeuplement des tables.
Amazon RDS Database Insights fournit les `xact_commit` métriques PostgreSQL et indique le nombre de validations `xact_rollback` et de rollbacks par seconde.
### Réduire la simultanéité
**Transactions par lots** — Dans la mesure du possible, opérations groupées en transactions uniques afin de réduire les commit/rollback opérations.
**Limiter la simultanéité** — Réduisez le nombre de transactions actives simultanément afin d'atténuer les conflits liés au verrouillage sur le. ProcArray Bien que cela nécessite quelques tests, la réduction du nombre total de connexions simultanées peut réduire les conflits et maintenir le débit.
### Mise en œuvre du regroupement de connexions
**Solutions de regroupement de connexions** : utilisez le regroupement de connexions pour gérer efficacement les connexions aux bases de données, en réduisant le nombre total de backends et donc la charge de travail sur le ProcArray. Bien que cela nécessite quelques tests, la réduction du nombre total de connexions simultanées peut réduire les conflits et maintenir le débit.
**Réduisez les tempêtes de connexion** — De même, une tendance à créer et à terminer fréquemment des connexions entraîne une pression supplémentaire sur le ProcArray. En réduisant ce schéma, la contention globale est réduite.
### Utilisation d'un stockage plus rapide
**Volume de journal dédié** — Si l'événement d'`IPC:ProcArrayGroupUpdate`attente s'accompagne d'événements d'`IO:WALWrite`attente élevés, la configuration d'un volume de journal dédié peut réduire le goulot d'étranglement lors de l'écriture sur WAL. Cela améliore à son tour les performances des validations.
Pour plus d'informations, consultez la section [Volume de journal dédié](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.dlv.html).
# Lock:advisory
L'événement `Lock:advisory` se produit lorsqu'une application PostgreSQL utilise un verrou pour coordonner l'activité sur plusieurs sessions.
**Topics**
+ [
## Versions de moteur pertinentes
](#wait-event.lockadvisory.context.supported)
+ [
## Contexte
](#wait-event.lockadvisory.context)
+ [
## Causes
](#wait-event.lockadvisory.causes)
+ [
## Actions
](#wait-event.lockadvisory.actions)
## Versions de moteur pertinentes
Ces informations sur les événements d'attente s'appliquent à RDS for PostgreSQL 9.6 et versions ultérieures.
## Contexte
Les verrous consultatifs PostgreSQL sont des verrous coopératifs de niveau application explicitement verrouillés et déverrouillés par le code d'application de l'utilisateur. Une application peut utiliser des verrous consultatifs PostgreSQL pour coordonner l'activité sur plusieurs sessions. Contrairement aux verrous standard, de niveau objet ou ligne, l'application dispose d'un contrôle total sur la durée de vie du verrou. Pour en savoir plus, consultez [Advisory Locks](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) dans la documentation PostgreSQL.
Les verrous consultatifs peuvent être libérés avant la fin d'une transaction ou être maintenus par une session sur plusieurs transactions. Cela ne s'applique pas aux verrous implicites appliqués par le système, comme un verrou exclusif d'accès à une table acquis par une instruction `CREATE INDEX`.
Pour accéder à la description des fonctions utilisées pour acquérir (verrouiller) et libérer (déverrouiller) les verrous consultatifs, consultez [Advisory Lock Functions](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS) dans la documentation PostgreSQL.
Les verrous consultatifs sont implémentés au-dessus du système de verrouillage PostgreSQL standard et sont visibles dans la vue système `pg_locks`.
## Causes
Ce type de verrou est exclusivement contrôlé par une application qui l'utilise explicitement. Les verrous consultatifs qui sont acquis pour chaque ligne dans le cadre d'une requête peuvent provoquer un pic de verrous ou une accumulation à long terme.
Ces effets se produisent lorsque la requête est exécutée d'une manière qui acquiert des verrous sur plus de lignes que celles renvoyées par la requête. L'application doit finir par libérer chaque verrou, mais si des verrous sont acquis sur des lignes qui ne sont pas renvoyées, l'application ne peut pas tous les trouver.
L'exemple suivant est extrait de la section [Advisory Locks](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) de la documentation PostgreSQL.
```
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100;
```
Dans cet exemple, la clause `LIMIT` ne peut arrêter la sortie de la requête que lorsque les lignes ont déjà été sélectionnées en interne et que leurs valeurs d'ID ont été verrouillées. Cela peut se produire soudainement lorsqu'un volume de données croissant amène le planificateur à choisir un plan d'exécution différent qui n'a pas été testé lors de la phase de développement. Dans ce cas, l'accumulation se produit parce que l'application appelle explicitement `pg_advisory_unlock` pour chaque valeur d'ID verrouillée. Mais elle ne trouve pas l'ensemble de verrous acquis sur les lignes qui n'ont pas été renvoyées. Comme les verrous sont acquis au niveau de la session, ils ne sont pas libérés automatiquement à la fin de la transaction.
Les pics de tentatives de verrouillage bloquées peuvent également être liés à des conflits involontaires. Lors de ces conflits, des parties non liées de l'application partagent par erreur le même espace d'ID de verrou.
## Actions
Examinez la façon dont les verrous consultatifs sont utilisés par l'application et indiquez où et quand, dans le flux d'application, chaque type de verrou consultatif est acquis et libéré.
Déterminez si une session acquiert trop de verrous ou si une session longue ne libère pas les verrous suffisamment tôt, ce qui entraîne une accumulation lente des verrous. Vous pouvez corriger une accumulation lente de verrous au niveau de la session en mettant fin à la session à l'aide de `pg_terminate_backend(pid)`.
Un client en attente d'un verrou consultatif apparaît dans `pg_stat_activity` avec `wait_event_type=Lock` et `wait_event=advisory`. Vous pouvez obtenir des valeurs de verrouillage spécifiques en interrogeant la vue système `pg_locks` sur le même `pid`, à la recherche de `locktype=advisory` et `granted=f`.
Vous pouvez ensuite identifier la session de blocage en interrogeant `pg_locks` sur le même verrou consultatif doté de `granted=t`, comme illustré dans l'exemple suivant.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
Toutes les fonctions d'API des verrous consultatifs comportent deux ensembles d'arguments, soit un argument `bigint`, soit deux arguments `integer` :
+ Pour les fonctions d'API comportant un argument `bigint`, les 32 bits supérieurs figurent dans `pg_locks.classid` et les 32 bits inférieurs se trouvent dans `pg_locks.objid`.
+ Pour les fonctions d'API comportant deux arguments `integer`, le premier argument est `pg_locks.classid` et le deuxième est `pg_locks.objid`.
La valeur `pg_locks.objsubid` indique quelle forme d'API a été utilisée : `1` pour un argument `bigint` et `2` pour deux arguments `integer`.
# Lock:extend
L'événement `Lock:extend` se produit lorsqu'un processus backend attend de verrouiller une relation pour l'étendre alors qu'un autre processus présente un verrou sur cette relation dans le même but.
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.lockextend.context.supported)
+ [
## Contexte
](#wait-event.lockextend.context)
+ [
## Causes probables de l'augmentation du nombre d'événements d'attente
](#wait-event.lockextend.causes)
+ [
## Actions
](#wait-event.lockextend.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d'attente sont prises en charge pour toutes les versions de RDS for PostgreSQL.
## Contexte
L'événement `Lock:extend` indique qu'un processus backend attend d'étendre une relation sur laquelle un autre processus backend détient un verrou pendant qu'il étend cette relation. Comme un seul processus à la fois peut étendre une relation, le système génère un événement d'attente `Lock:extend`. Les opérations `INSERT`, `COPY` et `UPDATE` peuvent générer cet événement.
## Causes probables de l'augmentation du nombre d'événements d'attente
Un événement `Lock:extend` trop fréquent peut révéler un problème de performances dont les causes sont généralement les suivantes :
**Augmentation du nombre d'insertions ou de mises à jour simultanées dans la même table **
Le nombre de sessions simultanées associées à des requêtes d'insertion ou de mise à jour peut augmenter.
**Bande passante réseau insuffisante**
La bande passante réseau de l'instance de base de données peut être insuffisante pour répondre aux besoins de communication de stockage de la charge de travail actuelle. Cela peut contribuer à une latence de stockage qui entraîne une augmentation des événements `Lock:extend`.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d'attente.
**Topics**
+ [
### Réduisez les insertions et les mises à jour simultanées dans la même relation
](#wait-event.lockextend.actions.action1)
+ [
### Augmentez la bande passante réseau
](#wait-event.lockextend.actions.increase-network-bandwidth)
### Réduisez les insertions et les mises à jour simultanées dans la même relation
Tout d'abord, déterminez s'il y a une augmentation des métriques `tup_inserted` et `tup_updated`, et une augmentation concomitante de cet événement d'attente. Si tel est le cas, déterminez quelles relations sont en conflit pour les opérations d'insertion et de mise à jour. Pour ce faire, interrogez la vue `pg_stat_all_tables` afin de connaître les valeurs des champs `n_tup_ins` et `n_tup_upd`. Pour en savoir plus sur la vue `pg_stat_all_tables`, consultez [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW) dans la documentation PostgreSQL.
Pour en savoir plus sur les requêtes de blocage et les requêtes bloquées, interrogez `pg_stat_activity` comme dans l'exemple suivant :
```
SELECT
blocked.pid,
blocked.usename,
blocked.query,
blocking.pid AS blocking_id,
blocking.query AS blocking_query,
blocking.wait_event AS blocking_wait_event,
blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
pid | usename | query | blocking_id | blocking_query | blocking_wait_event | blocking_wait_event_type
------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
7143 | myuser | insert into tab1 values (1); | 4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend | IO
```
Après avoir identifié les relations qui contribuent à l'augmentation des événements `Lock:extend`, utilisez les techniques suivantes pour réduire les conflits :
+ Déterminez si vous pouvez utiliser le partitionnement pour réduire les conflits relatifs à la même table. La séparation des tuples insérés ou mis à jour dans différentes partitions peut réduire les conflits. Pour plus d'informations sur le partitionnement, voir [Gestion des partitions PostgreSQL avec l’extension pg\$1partman](PostgreSQL_Partitions.md).
+ Si l'événement d'attente est principalement dû à une activité de mise à jour, vous pouvez réduire la valeur du facteur de remplissage de la relation. Cela peut réduire les requêtes de nouveaux blocs lors de la mise à jour. Le facteur de remplissage est un paramètre de stockage relatif à une table qui détermine la quantité maximale d'espace requise pour remplir une page de la table. Il est exprimé en pourcentage de l'espace total d'une page. Pour en savoir plus sur le facteur de remplissage, consultez [CREATE TABLE](https://www.postgresql.org/docs/13/sql-createtable.html) dans la documentation PostgreSQL.
**Important**
Si vous modifiez le facteur de remplissage, nous vous recommandons vivement de tester votre système, car en fonction de votre charge de travail, la modification de cette valeur peut nuire aux performances.
### Augmentez la bande passante réseau
Pour déterminer si la latence d'écriture a augmenté, consultez la métrique `WriteLatency` dans CloudWatch. Le cas échéant, utilisez les métriques Amazon CloudWatch `WriteThroughput` et `ReadThroughput` pour surveiller le trafic lié au stockage sur l'instance de base de données. Ces métriques peuvent vous aider à déterminer si la bande passante réseau est suffisante pour l'activité de stockage de votre charge de travail.
Si la bande passante réseau est insuffisante, augmentez-la. Si votre instance de base de données atteint les limites de sa bande passante réseau, le seul moyen d'augmenter la bande passante est d'augmenter la taille de l'instance de base de données.
Pour plus d’informations sur les métriques CloudWatch, consultez [Mesures au CloudWatch niveau de l'instance Amazon pour Amazon RDS](rds-metrics.md#rds-cw-metrics-instance). Pour en savoir plus sur les performances réseau de chaque classe d'instance de base de données, consultez [Mesures au CloudWatch niveau de l'instance Amazon pour Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
# Lock:Relation
L’événement `Lock:Relation` se produit lorsqu’une requête attend d’acquérir un verrou sur une table ou une vue (relation) actuellement verrouillée par une autre transaction.
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.lockrelation.context.supported)
+ [
## Contexte
](#wait-event.lockrelation.context)
+ [
## Causes probables de l’augmentation du nombre d’événements d’attente
](#wait-event.lockrelation.causes)
+ [
## Actions
](#wait-event.lockrelation.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente sont prises en charge pour toutes les versions de RDS pour PostgreSQL.
## Contexte
La plupart des commandes PostgreSQL utilisent implicitement des verrous pour contrôler les accès simultanés aux données des tables. Vous pouvez également utiliser ces verrous explicitement dans le code de votre application grâce à la commande `LOCK`. De nombreux modes de verrouillage ne sont pas compatibles entre eux et peuvent bloquer des transactions lorsqu’ils tentent d’accéder au même objet. Dans ce cas, RDS for PostgreSQL génère un événement `Lock:Relation`. Voici quelques exemples courants :
+ Des verrous exclusifs tels que `ACCESS EXCLUSIVE` peuvent bloquer tous les accès simultanés. Les opérations en langage de définition de données (DDL) telles que `DROP TABLE`, `TRUNCATE`, `VACUUM FULL` et `CLUSTER` acquièrent implicitement des verrous `ACCESS EXCLUSIVE`. `ACCESS EXCLUSIVE` est également le mode de verrouillage par défaut pour les instructions `LOCK TABLE` qui ne spécifient pas explicitement de mode.
+ L’utilisation de `CREATE INDEX (without CONCURRENT)` sur une table entre en conflit avec les instructions du langage de manipulation de données (DML) `UPDATE`, `DELETE` et `INSERT`, qui acquièrent des verrous `ROW EXCLUSIVE`.
Pour en savoir plus sur les verrous de niveau table et les modes de verrouillage conflictuels, consultez [Explicit Locking](https://www.postgresql.org/docs/13/explicit-locking.html) dans la documentation PostgreSQL.
Le déblocage lié aux requêtes et transactions de blocage s’effectue généralement de l’une des manières suivantes :
+ Requête de blocage : l’application peut annuler la requête ou l’utilisateur peut mettre fin au processus. Le moteur peut également forcer la requête à se terminer en raison de l’expiration du délai d’attente d’une instruction de la session ou d’un mécanisme de détection de blocage.
+ Transaction de blocage : une transaction met fin à son blocage lorsqu’elle exécute une instruction `ROLLBACK` ou `COMMIT`. Les restaurations sont également automatiques lorsque les sessions sont déconnectées par un client ou suite à des problèmes de réseau, ou lorsqu’elles sont interrompues. Les sessions peuvent être interrompues lorsque le moteur de base de données est arrêté, lorsque le système est à court de mémoire, etc.
## Causes probables de l’augmentation du nombre d’événements d’attente
Lorsque l’événement `Lock:Relation` se produit plus fréquemment que la normale, il peut indiquer un problème de performances. Les causes sont généralement les suivantes :
**Augmentation du nombre de sessions simultanées avec des verrous de table conflictuels**
Le nombre de sessions simultanées peut augmenter lorsque des requêtes verrouillent la même table avec des modes de verrouillage conflictuels.
**Opérations de maintenance**
Les opérations de maintenance liées à l’état comme `VACUUM` et `ANALYZE` peuvent considérablement augmenter le nombre de verrous en conflit. `VACUUM FULL` acquiert un verrou `ACCESS EXCLUSIVE`, et `ANALYSE` acquiert un verrou `SHARE UPDATE EXCLUSIVE`. Ces deux types de verrous peuvent provoquer un événement d’attente `Lock:Relation`. Les opérations de maintenance des données d’application telles que l’actualisation d’une vue matérialisée peuvent également augmenter le nombre de requêtes et de transactions bloquées.
**Verrous sur les instances de lecture**
Il peut y avoir un conflit entre les verrous relationnels des volumes en écriture et des volumes en lecture. Actuellement, seuls les verrous relationnels `ACCESS EXCLUSIVE` sont répliqués vers les instances de lecture. Cependant, le verrou relationnel `ACCESS EXCLUSIVE` entrera en conflit avec tout verrou relationnel `ACCESS SHARE` détenu par le volume en lecture. Cela peut entraîner une augmentation des événements d’attente de relation de verrouillage sur le volume en lecture.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.
**Topics**
+ [
### Réduisez l’impact des instructions SQL de blocage
](#wait-event.lockrelation.actions.reduce-blocks)
+ [
### Minimisez l’effet des opérations de maintenance
](#wait-event.lockrelation.actions.maintenance)
### Réduisez l’impact des instructions SQL de blocage
Pour réduire l’impact des instructions SQL de blocage, si possible, modifiez le code de votre application. Voici deux techniques courantes pour réduire les blocages :
+ Utilisez l’option `NOWAIT` : certaines commandes SQL, telles que les instructions `SELECT` et `LOCK` prennent en charge cette option. La directive `NOWAIT` annule la requête liée à la demande de verrou si le verrou ne peut pas être acquis immédiatement. Cette technique permet d’éviter qu’une session de blocage ne provoque un empilement de sessions bloquées derrière elle.
Par exemple, supposons que la transaction A attende un verrou détenu par la transaction B. Si B demande un verrou sur une table qui est verrouillée par la transaction C, la transaction A peut être bloquée jusqu’à ce que la transaction C se termine. Mais si la transaction B utilise `NOWAIT` lorsqu’elle demande le verrou sur C, elle peut échouer rapidement et faire en sorte que la transaction A n’ait pas à attendre indéfiniment.
+ Utilisez `SET lock_timeout` – Définissez une valeur `lock_timeout` afin de limiter le délai d'attente d'une instruction SQL pour acquérir un verrou sur une relation. Si le verrou n'est pas acquis dans le délai spécifié, la transaction qui a demandé celui-ci est annulée. Définissez cette valeur au niveau de la session.
### Minimisez l’effet des opérations de maintenance
Les opérations de maintenance telles que `VACUUM` et `ANALYZE` sont importantes. Nous vous recommandons de ne pas les désactiver parce que vous trouvez des événements d’attente `Lock:Relation` liés à ces opérations de maintenance. Les approches suivantes peuvent minimiser l’effet de ces opérations :
+ Exécutez les opérations de maintenance manuellement pendant les heures creuses.
+ Pour réduire les attentes `Lock:Relation` causées par les tâches autovacuum, procédez aux réglages nécessaires de la fonction autovacuum. Pour en savoir plus sur le réglage de la fonction autovacuum, consultez [ Utilisation de la fonction autovacuum de PostgreSQL sur Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) dans le *Guide de l’utilisateur Amazon RDS*.
# Lock:transactionid
L'événement `Lock:transactionid` se produit lorsqu'une transaction attend un verrou au niveau ligne.
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.locktransactionid.context.supported)
+ [
## Contexte
](#wait-event.locktransactionid.context)
+ [
## Causes probables de l'augmentation du nombre d'événements d'attente
](#wait-event.locktransactionid.causes)
+ [
## Actions
](#wait-event.locktransactionid.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente sont prises en charge pour toutes les versions de RDS pour PostgreSQL.
## Contexte
L'événement `Lock:transactionid` se produit lorsqu'une transaction tente d'acquérir un verrou de niveau ligne qui a déjà été accordé à une transaction exécutée en même temps. La session qui présente l'événement d'attente `Lock:transactionid` est bloquée à cause de ce verrou. Une fois la transaction de blocage terminée dans une instruction `COMMIT` ou `ROLLBACK`, la transaction bloquée peut se poursuivre.
La sémantique de contrôle de simultanéité multiversion de RDS for PostgreSQL garantit l'absence de blocage des processus de lecture par les processus d'écriture, et vice versa. Pour que des conflits se produisent au niveau ligne, les transactions de blocage et les transactions bloquées doivent émettre des instructions conflictuelles des types suivants :
+ `UPDATE`
+ `SELECT … FOR UPDATE`
+ `SELECT … FOR KEY SHARE`
L'instruction `SELECT … FOR KEY SHARE` est un cas particulier. La base de données utilise la clause `FOR KEY SHARE` pour optimiser les performances de l'intégrité référentielle. La présence d'un verrou de niveau ligne sur une ligne peut bloquer les commandes `INSERT`, `UPDATE` et `DELETE` sur d'autres tables qui font référence à la ligne.
## Causes probables de l'augmentation du nombre d'événements d'attente
Un événement trop fréquent est généralement dû à des instructions `UPDATE`, `SELECT … FOR UPDATE` ou `SELECT … FOR KEY SHARE` combinées aux conditions suivantes.
**Topics**
+ [
### Forte simultanéité
](#wait-event.locktransactionid.concurrency)
+ [
### État Idle in transaction (Transaction inactive)
](#wait-event.locktransactionid.idle)
+ [
### Transactions de longue durée
](#wait-event.locktransactionid.long-running)
### Forte simultanéité
RDS for PostgreSQL peut utiliser une sémantique de verrouillage détaillée de niveau ligne. La probabilité de conflits au niveau ligne augmente lorsque les conditions suivantes sont réunies :
+ Une charge de travail à forte simultanéité se dispute les mêmes lignes.
+ La simultanéité augmente.
### État Idle in transaction (Transaction inactive)
Parfois, la colonne `pg_stat_activity.state` affiche la valeur `idle in transaction`. Cette valeur apparaît pour les sessions qui ont entamé une transaction, mais qui n'ont pas encore émis de commande `COMMIT` ou `ROLLBACK`. Si la valeur `pg_stat_activity.state` n'est pas `active`, la requête affichée dans `pg_stat_activity` est la plus récente à avoir été exécutée. La session de blocage ne traite pas activement une requête, car une transaction ouverte comporte un verrou.
Si une transaction inactive a acquis un verrou au niveau ligne, cela peut empêcher d'autres sessions de l'acquérir. Cette condition entraîne l'apparition fréquente de l'événement d'attente `Lock:transactionid`. Pour diagnostiquer le problème, examinez la sortie de `pg_stat_activity` et `pg_locks`.
### Transactions de longue durée
Les transactions qui s'exécutent depuis longtemps comportent des verrous pendant longtemps. Ces verrous de longue durée peuvent bloquer l'exécution d'autres transactions.
## Actions
Le verrouillage de ligne correspond à un conflit entre les instructions `UPDATE`, `SELECT … FOR UPDATE` ou `SELECT … FOR KEY SHARE`. Avant de rechercher une solution, déterminez quand ces instructions sont exécutées sur la même ligne. Utilisez ces informations pour choisir une des stratégies décrites dans les sections suivantes.
**Topics**
+ [
### Réagissez à une forte simultanéité
](#wait-event.locktransactionid.actions.problem)
+ [
### Réagissez aux transactions inactives
](#wait-event.locktransactionid.actions.find-blocker)
+ [
### Réagissez aux transactions de longue durée
](#wait-event.locktransactionid.actions.concurrency)
### Réagissez à une forte simultanéité
En cas de problème lié à la simultanéité, essayez l'une des techniques suivantes :
+ Réduisez la simultanéité dans l'application. Par exemple, réduisez le nombre de sessions actives.
+ Implémentez un groupe de connexions. Pour savoir comment regrouper des connexions à l'aide de RDS Proxy, consultez [Proxy Amazon RDS ](rds-proxy.md).
+ Concevez l'application ou le modèle de données de manière à éviter les instructions `UPDATE` et `SELECT … FOR UPDATE` conflictuelles. Vous pouvez également réduire le nombre de clés étrangères accessibles par les instructions `SELECT … FOR KEY SHARE`.
### Réagissez aux transactions inactives
Si `pg_stat_activity.state` indique `idle in transaction`, utilisez les stratégies suivantes :
+ Si possible, activez la validation automatique. Cette approche empêche les transactions de bloquer d'autres transactions en attendant une instruction `COMMIT` ou `ROLLBACK`.
+ Recherchez les chemins de code qui ne contiennent pas d'instruction `COMMIT`, `ROLLBACK` ou `END`.
+ Assurez-vous que la logique de gestion des exceptions de votre application comporte toujours un chemin vers une `end of transaction` valide.
+ Assurez-vous que votre application traite les résultats des requêtes après avoir mis fin à la transaction avec `COMMIT` ou `ROLLBACK`.
### Réagissez aux transactions de longue durée
Si des transactions de longue durée sont à l'origine de l'apparition fréquente de `Lock:transactionid`, essayez les stratégies suivantes :
+ N'utilisez pas de verrous de ligne dans les transactions de longue durée.
+ Limitez la longueur des requêtes en implémentant la validation automatique chaque fois que possible.
# Lock:tuple
L'événement `Lock:tuple` se produit lorsqu'un processus backend attend d'acquérir un verrou sur un tuple.
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.locktuple.context.supported)
+ [
## Contexte
](#wait-event.locktuple.context)
+ [
## Causes probables de l'augmentation du nombre d'événements d'attente
](#wait-event.locktuple.causes)
+ [
## Actions
](#wait-event.locktuple.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d'attente sont prises en charge pour toutes les versions de RDS for PostgreSQL.
## Contexte
L'événement `Lock:tuple` indique qu'un backend attend d'acquérir un verrou sur un tuple alors qu'un autre moteur détient un verrou conflictuel sur le même tuple. Le tableau suivant illustre un scénario dans lequel les sessions génèrent l'événement `Lock:tuple`.
| Heure | Session 1 | Session 2 | Session 3 |
| --- | --- | --- | --- |
| t1 | Démarre une transaction. | | |
| t2 | Met à jour la ligne 1. | | |
| t3 | | Met à jour la ligne 1. La session acquiert un verrou exclusif sur le tuple, puis attend que la session 1 libère le verrou par le biais d'une validation ou d'une restauration. | |
| t4 | | | Met à jour la ligne 1. La session attend que la session 2 libère le verrou exclusif sur le tuple. |
Vous pouvez également simuler cet événement d'attente à l'aide de l'outil de définition de points de référence `pgbench`. Configurez un nombre élevé de sessions simultanées pour mettre à jour la même ligne au sein d'une table avec un fichier SQL personnalisé.
Pour en savoir plus sur les modes de verrouillage conflictuels, consultez [Explicit Locking](https://www.postgresql.org/docs/current/explicit-locking.html) dans la documentation PostgreSQL. Pour en savoir plus sur `pgbench`, consultez [pgbench](https://www.postgresql.org/docs/current/pgbench.html) dans la documentation PostgreSQL.
## Causes probables de l'augmentation du nombre d'événements d'attente
Un événement de ce type trop fréquent peut révéler un problème de performances dont les causes sont généralement les suivantes :
+ Un grand nombre de sessions simultanées tentent d'acquérir un verrou conflictuel pour le même tuple en exécutant des instructions `UPDATE` ou `DELETE`.
+ Les sessions à forte simultanéité exécutent une instruction `SELECT` en utilisant les modes de verrouillage `FOR UPDATE` ou `FOR NO KEY UPDATE`.
+ Divers facteurs poussent les groupes d'applications ou de connexions à ouvrir davantage de sessions pour exécuter les mêmes opérations. Comme de nouvelles sessions tentent de modifier les mêmes lignes, la charge de base de données peut augmenter et un événement `Lock:tuple` peut apparaître.
Pour en savoir plus, consultez [Row-Level Locks](https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS) dans la documentation PostgreSQL.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d'attente.
**Topics**
+ [
### Examinez la logique de votre application
](#wait-event.locktuple.actions.problem)
+ [
### Recherchez la session de blocage
](#wait-event.locktuple.actions.find-blocker)
+ [
### Réduisez la simultanéité lorsqu'elle est forte
](#wait-event.locktuple.actions.concurrency)
+ [
### Résolvez les problèmes liés aux goulots d'étranglement
](#wait-event.locktuple.actions.bottlenecks)
### Examinez la logique de votre application
Déterminez si une session de blocage est restée longtemps dans l'état `idle in transaction`. Si tel est le cas, la solution à court terme peut consister à mettre fin à la session de blocage. Vous pouvez utiliser la fonction `pg_terminate_backend`. Pour en savoir plus sur cette fonction, consultez [Server Signaling Functions](https://www.postgresql.org/docs/13/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL) dans la documentation PostgreSQL.
Pour une solution à long terme, procédez comme suit :
+ Modifiez la logique de l'application.
+ Utilisez le paramètre `idle_in_transaction_session_timeout`. Ce paramètre met fin à toute session associée à une transaction ouverte qui est restée inactive plus longtemps que la durée spécifiée. Pour en savoir plus, consultez [Client Connection Defaults](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT) dans la documentation PostgreSQL.
+ Chaque fois que possible, utilisez la validation automatique. Pour en savoir plus, consultez [SET AUTOCOMMIT](https://www.postgresql.org/docs/current/ecpg-sql-set-autocommit.html) dans la documentation PostgreSQL.
### Recherchez la session de blocage
Pendant l'événement d'attente `Lock:tuple`, identifiez le blocage et la session bloquée en déterminant quels verrous dépendent les uns des autres. Pour en savoir plus, consultez [Lock dependency information](https://wiki.postgresql.org/wiki/Lock_dependency_information) dans le wiki PostgreSQL.
L'exemple suivant interroge toutes les sessions, en y appliquant le filtre `tuple` et en les classant par `wait_time`.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
### Réduisez la simultanéité lorsqu'elle est forte
L'événement `Lock:tuple` peut se produire constamment, en particulier lorsque la charge de travail est élevée. Dans ce cas, réduisez la simultanéité pour les lignes très occupées. Souvent, quelques lignes seulement contrôlent une file d'attente ou la logique booléenne, ce qui explique pourquoi ces lignes sont très occupées.
Vous pouvez réduire la simultanéité en utilisant différentes approches basées sur les besoins métier, la logique de l'application et le type de charge de travail. Par exemple, vous pouvez effectuer les opérations suivantes :
+ Redéfinissez la logique de votre table et de vos données pour réduire la simultanéité.
+ Modifiez la logique de l'application pour réduire la simultanéité au niveau ligne.
+ Exploitez et redéfinissez les requêtes avec des verrous de niveau ligne.
+ Utilisez la clause `NOWAIT` lors des nouvelles tentatives.
+ Envisagez d'utiliser un contrôle de simultanéité logique optimiste et à verrouillage hybride.
+ Envisagez de modifier le niveau d'isolement de la base de données.
### Résolvez les problèmes liés aux goulots d'étranglement
L'événement `Lock:tuple` peut se produire avec des goulots d'étranglement tels qu'une pénurie d'UC ou une saturation de la bande passante d'Amazon EBS. Pour réduire les goulots d'étranglement, adoptez les approches suivantes :
+ Procédez à une augmentation d'échelle de votre type de classe d'instance.
+ Optimisez les requêtes gourmandes en ressources.
+ Modifiez la logique de l'application.
+ Archivez les données rarement consultées.
# LWLock: BufferMapping (:buffer\$1mapping) LWLock
Cet événement se produit lorsqu'une session attend d'associer un bloc de données à une mémoire tampon dans le groupe de mémoires tampons partagées.
**Note**
Cet événement est nommé `LWLock:BufferMapping` pour RDS for PostgreSQL 13 et versions ultérieures. Pour RDS for PostgreSQL version 12 et versions antérieures, cet événement est nommé `LWLock:buffer_mapping`.
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.lwl-buffer-mapping.context.supported)
+ [
## Contexte
](#wait-event.lwl-buffer-mapping.context)
+ [
## Causes
](#wait-event.lwl-buffer-mapping.causes)
+ [
## Actions
](#wait-event.lwl-buffer-mapping.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d'attente s'appliquent à RDS for PostgreSQL 9.6 et versions ultérieures.
## Contexte
Le *groupe de mémoires tampons partagées* est une zone de mémoire PostgreSQL qui contient toutes les pages actuellement ou précédemment utilisées par les processus. Lorsqu'un processus a besoin d'une page, il la lit dans le groupe de mémoires tampons partagées. Le paramètre `shared_buffers` définit la taille de la mémoire tampon partagée et réserve une zone de mémoire pour stocker la table et les pages d'index. Si vous modifiez ce paramètre, veillez à redémarrer la base de données.
L'événement d'attente `LWLock:buffer_mapping` se produit dans les scénarios suivants :
+ Un processus recherche une page dans la table des mémoires tampons et acquiert un verrou de mappage de mémoire tampon partagée.
+ Un processus charge une page dans le groupe de mémoires tampons et acquiert un verrou exclusif de mappage de mémoire tampon.
+ Un processus supprime une page du groupe et acquiert un verrou exclusif de mappage de mémoire tampon.
## Causes
Lorsque cet événement se produit plus souvent qu'à l'accoutumée, indiquant un possible problème de performances, la base de données effectue une pagination dans et hors du groupe de mémoires tampons partagées. Les causes sont généralement les suivantes :
+ Requêtes volumineuses
+ Index et tables gonflés
+ Analyses de tables complètes
+ Taille de groupe partagé inférieure à celle de l'ensemble de travail
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.
**Topics**
+ [
### Surveillez les métriques liées à la mémoire tampon
](#wait-event.lwl-buffer-mapping.actions.monitor-metrics)
+ [
### Évaluez votre stratégie d'indexation
](#wait-event.lwl-buffer-mapping.actions.indexes)
+ [
### Réduisez le nombre de mémoires tampons qui doivent être allouées rapidement
](#wait-event.lwl-buffer-mapping.actions.buffers)
### Surveillez les métriques liées à la mémoire tampon
Lorsque les événements d'attente `LWLock:buffer_mapping` atteignent un pic, examinez le taux d'accès à la mémoire tampon. Vous pouvez utiliser ces métriques pour mieux comprendre ce qui se passe dans le cache de mémoire tampon. Examinez les métriques suivantes :
`blks_hit`
Cette métrique de compteur Performance Insights indique le nombre de blocs qui ont été récupérés à partir du groupe de mémoires tampons partagées. Après l'apparition de l'événement d'attente `LWLock:buffer_mapping`, vous pouvez observer un pic dans `blks_hit`.
`blks_read`
Ce compteur Performance Insights indique le nombre de blocs devant I/O être lus dans le pool de mémoire tampon partagé. Vous observerez peut-être un pic de `blks_read` dans la période précédant l'événement d'attente `LWLock:buffer_mapping`.
### Évaluez votre stratégie d'indexation
Pour vous assurer que votre stratégie d'indexation ne nuit pas aux performances, vérifiez les éléments suivants :
Gonflement des index
Assurez-vous que le gonflement des index et des tables n'entraîne pas la lecture de pages inutiles dans la mémoire tampon partagée. Si vos tables contiennent des lignes inutilisées, archivez les données et supprimez les lignes des tables. Vous pouvez ensuite reconstruire les index des tables redimensionnées.
Index pour les requêtes fréquemment utilisées
Pour déterminer si vos index sont optimaux, surveillez les métriques du moteur de base de données dans Performance Insights. La métrique `tup_returned` indique le nombre de lignes lues. La métrique `tup_fetched` indique le nombre de lignes renvoyées au client. Si la métrique `tup_returned` est nettement supérieure à la métrique `tup_fetched`, les données risquent de ne pas être correctement indexées. De plus, les statistiques de votre table ne sont peut-être pas à jour.
### Réduisez le nombre de mémoires tampons qui doivent être allouées rapidement
Pour réduire le nombre d'événements d'attente `LWLock:buffer_mapping`, essayez de réduire le nombre de mémoires tampons qui doivent être allouées rapidement. Une stratégie consiste à effectuer des opérations par lots de plus petite taille. Vous pouvez obtenir des lots plus petits en partitionnant vos tables.
# LWLock:BufferIO (IPC:BufferIO)
L'événement `LWLock:BufferIO` se produit quand RDS for PostgreSQL attend que d'autres processus terminent leurs opérations d'entrée/sortie (E/S) en cas de tentative simultanée d'accès à une page. Le but est que la même page soit lue dans la mémoire tampon partagée.
**Topics**
+ [
## Versions de moteur pertinentes
](#wait-event.lwlockbufferio.context.supported)
+ [
## Contexte
](#wait-event.lwlockbufferio.context)
+ [
## Causes
](#wait-event.lwlockbufferio.causes)
+ [
## Actions
](#wait-event.lwlockbufferio.actions)
## Versions de moteur pertinentes
Ces informations sur les événements d'attente s'appliquent à toutes les versions de RDS for PostgreSQL. Pour RDS for PostgreSQL 12 et versions antérieures, cet événement d'attente est nommé lwlock:buffer\$1io, tandis qu'il est nommé lwlock:bufferio dans la version RDS for PostgreSQL 13. Depuis la version RDS for PostgreSQL 14, l'événement d'attente BufferIO est passé du type d'événement d'attente (IPC:Bufferio) `LWLock` à `IPC`.
## Contexte
Chaque mémoire tampon partagée possède un verrou I/O qui est associé à l'événement d'attente `LWLock:BufferIO`, chaque fois qu'un bloc (ou une page) doit être récupéré en dehors du groupe de mémoires tampons partagées.
Ce verrou est utilisé pour gérer plusieurs sessions qui ont toutes besoin d'accéder au même bloc. Ce bloc doit être lu en dehors du groupe de mémoires tampons partagées, défini par le paramètre `shared_buffers`.
Dès que la page est lue dans le groupe de mémoires tampons partagées, le verrou `LWLock:BufferIO` est libéré.
**Note**
L'événement d'attente `LWLock:BufferIO` précède l'événement d'attente [IO : DataFileRead](wait-event.iodatafileread.md). L'événement d'attente `IO:DataFileRead` se produit lorsque les données sont lues à partir du stockage.
Pour en savoir plus sur les verrous légers, consultez [Présentation du verrouillage](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20).
## Causes
Les principales causes de l'événement d'attente `LWLock:BufferIO` sont les suivantes :
+ Plusieurs backends ou connexions tentant d'accéder à la même page qui est également en attente d'une opération I/O
+ Rapport entre la taille du groupe de mémoires tampons partagées (défini par le paramètre `shared_buffers`) et le nombre de mémoires tampons nécessaires à la charge de travail actuelle
+ La taille du groupe de mémoires tampons partagées n'est pas bien équilibrée par rapport au nombre de pages expulsées par d'autres opérations
+ Index volumineux ou gonflés qui obligent le moteur à lire plus de pages que nécessaire dans le groupe de mémoires tampons partagées
+ Absence d'index qui oblige le moteur de base de données à lire plus de pages que nécessaire dans les tables
+ Points de contrôle trop fréquents ou nécessité de vider un trop grand nombre de pages modifiées
+ Pics soudains de connexions à la base de données tentant d'effectuer des opérations sur la même page
## Actions
Nous vous recommandons différentes actions en fonction de l'origine de votre événement d'attente :
+ Réglez `max_wal_size` et `checkpoint_timeout` en fonction de l'heure de pointe de votre charge de travail si vous constatez que `LWLock:BufferIO` coïncide avec des baisses de la métrique `BufferCacheHitRatio`. Identifiez ensuite la requête qui pourrait en être la cause.
+ Recherchez les index inutilisés et supprimez-les.
+ Utilisez des tables partitionnées (qui comportent également des index partitionnés). Cela permet de limiter la réorganisation des index et de réduire son impact.
+ Évitez d'indexer inutilement des colonnes.
+ Empêchez les pics soudains de connexions à la base de données en utilisant un groupe de connexions.
+ En guise de bonne pratique, limitez le nombre maximal de connexions à la base de données.
# LWLock:buffer\$1content (BufferContent)
L'événement `LWLock:buffer_content` se produit lorsqu'une session attend de lire ou d'écrire une page de données en mémoire alors que celle-ci est verrouillée en écriture dans une autre session. Dans RDS for PostgreSQL 13 et versions ultérieures, cet événement d'attente est appelé `BufferContent`.
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.lwlockbuffercontent.context.supported)
+ [
## Contexte
](#wait-event.lwlockbuffercontent.context)
+ [
## Causes probables de l'augmentation du nombre d'événements d'attente
](#wait-event.lwlockbuffercontent.causes)
+ [
## Actions
](#wait-event.lwlockbuffercontent.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d'attente sont prises en charge pour toutes les versions de RDS for PostgreSQL.
## Contexte
Pour lire ou manipuler des données, PostgreSQL y accède via des mémoires tampons partagées. Pour lire à partir de la mémoire tampon, un processus obtient un verrou léger (LWLock) sur le contenu de la mémoire tampon en mode partagé. Pour écrire dans la mémoire tampon, il obtient ce verrou en mode exclusif. Les verrous partagés permettent à d'autres processus d'acquérir simultanément des verrous partagés sur ce contenu. Les verrous exclusifs empêchent les autres processus d'obtenir tout type de verrou sur ce contenu.
L'événement `LWLock:buffer_content` (`BufferContent`) indique que plusieurs processus tentent d'obtenir un verrou sur le contenu d'une mémoire tampon spécifique.
## Causes probables de l'augmentation du nombre d'événements d'attente
Un événement `LWLock:buffer_content` (`BufferContent`) trop fréquent peut révéler un problème de performances dont les causes sont généralement les suivantes :
**Augmentation des mises à jour simultanées des mêmes données**
Le nombre de sessions simultanées associées à des requêtes de mise à jour du même contenu de mémoire tampon peut augmenter. Ce conflit peut être plus marqué sur les tables contenant beaucoup d'index.
**Les données de la charge de travail ne sont pas en mémoire**
Lorsque les données traitées par la charge de travail active ne sont pas en mémoire, la fréquence de ces événements d'attente peut augmenter. Cet effet est dû au fait que les processus détenant des verrous peuvent les conserver plus longtemps pendant qu'ils effectuent des opérations d'I/O disque.
**Utilisation excessive de contraintes de clé étrangère**
Les contraintes de clé étrangère peuvent augmenter la durée pendant laquelle un processus conserve un verrou de contenu de mémoire tampon. Cet effet est dû au fait que les opérations de lecture ont besoin d'un verrou de contenu de mémoire tampon partagée sur la clé référencée pendant la mise à jour de cette clé.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d'attente. Vous pouvez identifier les événements `LWLock:buffer_content` (`BufferContent`) en utilisant Amazon RDS Performance Insights ou en interrogeant la vue `pg_stat_activity`.
**Topics**
+ [
### Améliorez l'efficacité en mémoire
](#wait-event.lwlockbuffercontent.actions.in-memory)
+ [
### Réduisez l'utilisation des contraintes de clé étrangère
](#wait-event.lwlockbuffercontent.actions.foreignkey)
+ [
### Supprimez les index inutilisés
](#wait-event.lwlockbuffercontent.actions.indexes)
+ [
### Augmentation de la taille du cache lors de l'utilisation de séquences
](#wait-event.lwlockbuffercontent.actions.sequences)
### Améliorez l'efficacité en mémoire
Pour que les données de la charge de travail active aient plus de chances d'être mises en mémoire, partitionnez les tables ou procédez à une augmentation d'échelle de votre classe d'instance. Pour plus d'informations sur les classes d'instances de base de données, consultez [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).
### Réduisez l'utilisation des contraintes de clé étrangère
Examinez les charges de travail qui présentent un nombre élevé d'événements d'attente `LWLock:buffer_content` (`BufferContent`) pour déterminer si des contraintes de clé étrangère sont utilisées. Supprimez les contraintes de clé étrangère inutiles.
### Supprimez les index inutilisés
Pour les charges de travail qui présentent un nombre élevé d'événements d'attente `LWLock:buffer_content` (`BufferContent`), identifiez les index inutilisés et supprimez-les.
### Augmentation de la taille du cache lors de l'utilisation de séquences
Si vos tables utilisent des séquences, augmentez la taille du cache pour éliminer les conflits sur les pages des séquences et les pages d'index. Chaque séquence correspond à une page unique en mémoire partagée. Le cache prédéfini s'applique à chaque connexion. Cela peut ne pas être suffisant pour gérer la charge de travail lorsque de nombreuses sessions simultanées obtiennent une valeur de séquence.
# LWLock:lock\$1manager (:lockmanager) LWLock
Cet événement se produit lorsque le moteur RDS pour PostgreSQL conserve la zone de mémoire du verrou partagé pour allouer, vérifier et libérer un verrou quand il est impossible d’utiliser un verrou à chemin d’accès rapide.
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.lw-lock-manager.context.supported)
+ [
## Contexte
](#wait-event.lw-lock-manager.context)
+ [
## Causes probables de l'augmentation du nombre d'événements d'attente
](#wait-event.lw-lock-manager.causes)
+ [
## Actions
](#wait-event.lw-lock-manager.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente s’appliquent à RDS pour PostgreSQL 9.6 et versions ultérieures. Pour les versions de RDS pour PostgreSQL antérieures à la version 13, le nom de cet événement d’attente est `LWLock:lock_manager`. Pour RDS pour PostgreSQL 13 et versions ultérieures, le nom de cet événement d’attente est `LWLock:lockmanager`.
## Contexte
Lorsque vous émettez une instruction SQL, RDS pour PostgreSQL enregistre des verrous pour protéger la structure, les données et l’intégrité de votre base de données pendant les opérations simultanées. Le moteur peut atteindre cet objectif en utilisant un verrou à chemin d'accès rapide ou non rapide. Un verrou à chemin d'accès non rapide est plus coûteux et génère plus de frais qu'un verrou à chemin d'accès rapide.
### Verrouillage à chemin d'accès rapide
Pour réduire les frais liés aux verrous qui sont fréquemment acquis et libérés, mais qui entrent rarement en conflit, les processus dorsaux peuvent utiliser le verrouillage à chemin d’accès rapide. La base de données utilise ce mécanisme pour les verrous qui répondent aux critères suivants :
+ Ils utilisent la méthode de verrouillage DEFAULT.
+ Ils représentent un verrou sur une relation de base de données plutôt qu'une relation partagée.
+ Il s'agit de verrous faibles qui sont peu susceptibles d'entrer en conflit.
+ Le moteur peut rapidement vérifier qu'aucun verrou conflictuel ne peut exister.
Le moteur ne peut pas utiliser de verrouillage à chemin d'accès rapide lorsque l'une des conditions suivantes est vraie :
+ Le verrou ne répond pas aux critères précédents.
+ Il n’y a plus d’emplacements disponibles pour le processus dorsal.
Pour ajuster vos requêtes pour le verrouillage à chemin d’accès rapide, vous pouvez utiliser la requête suivante.
```
SELECT count(*), pid, mode, fastpath
FROM pg_locks
WHERE fastpath IS NOT NULL
GROUP BY 4,3,2
ORDER BY pid, mode;
count | pid | mode | fastpath
-------+------+-----------------+----------
16 | 9185 | AccessShareLock | t
336 | 9185 | AccessShareLock | f
1 | 9185 | ExclusiveLock | t
```
La requête suivante affiche uniquement le total sur la base de données.
```
SELECT count(*), mode, fastpath
FROM pg_locks
WHERE fastpath IS NOT NULL
GROUP BY 3,2
ORDER BY mode,1;
count | mode | fastpath
-------+-----------------+----------
16 | AccessShareLock | t
337 | AccessShareLock | f
1 | ExclusiveLock | t
(3 rows)
```
Pour en savoir plus sur le verrouillage à chemin d'accès rapide, consultez [fast path](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76) dans le fichier README du gestionnaire de verrous PostgreSQL et [pg-locks](https://www.postgresql.org/docs/9.3/view-pg-locks.html#AEN98195) dans la documentation PostgreSQL.
### Exemple de problème de mise à l'échelle pour le gestionnaire de verrous
Dans cet exemple, une table nommée `purchases` stocke cinq ans de données, partitionnées par jour. Chaque partition possède deux index. La séquence d'événements suivante se produit :
1. Vous interrogez des données réparties sur différents jours, ce qui oblige la base de données à lire de nombreuses partitions.
1. La base de données crée une entrée de verrou pour chaque partition. Si les index de partition font partie du chemin d'accès de l'optimiseur, la base de données crée également une entrée de verrou pour eux.
1. Lorsque le nombre d’entrées de verrou demandées pour le même processus dorsal est supérieur à 16, ce qui correspond à la valeur de `FP_LOCK_SLOTS_PER_BACKEND`, le gestionnaire de verrous utilise la méthode de verrouillage à chemin d’accès non rapide.
Les applications modernes peuvent comporter des centaines de sessions. Si des sessions simultanées interrogent le parent sans élaguer correctement les partitions, la base de données peut créer des centaines, voire des milliers, de verrous à chemin d'accès non rapide. Généralement, lorsque cette simultanéité est supérieure au nombre de vCPUs, l'événement d'`LWLock:lock_manager`attente apparaît.
**Note**
L'événement d'attente `LWLock:lock_manager` n'est pas lié au nombre de partitions ou d'index contenus dans un schéma de base de données. Il est plutôt lié au nombre de verrous à chemin d'accès non rapide que la base de données doit contrôler.
## Causes probables de l'augmentation du nombre d'événements d'attente
Lorsque l'événement d'attente `LWLock:lock_manager` se produit plus souvent qu'à l'accoutumée, indiquant un possible problème de performances, les causes les plus probables des pics soudains sont les suivantes :
+ Les sessions actives simultanées exécutent des requêtes qui n'utilisent pas de verrous à chemin d'accès rapide. Ces sessions dépassent également le nombre maximum de vCPU.
+ Un grand nombre de sessions actives simultanées accèdent à une table fortement partitionnée. Chaque partition possède plusieurs index.
+ La base de données subit une tempête de connexions. Par défaut, certaines applications et certains logiciels de regroupement de connexions créent davantage de connexions lorsque la base de données est lente. Cette pratique aggrave le problème. Réglez le logiciel de regroupement de connexions de manière à éviter les tempêtes de connexions.
+ Un grand nombre de sessions interrogent une table parente sans élaguer les partitions.
+ Un langage de définition de données (DDL), un langage de manipulation de données (DML) ou une commande de maintenance verrouille exclusivement une relation occupée ou des tuples fréquemment consultés ou modifiés.
## Actions
L'événement d'attente `CPU` n'est pas nécessairement lié à un problème de performances. Ne réagissez à cet événement que lorsque les performances se dégradent et que cet événement d'attente domine la charge de la base de données.
**Topics**
+ [
### Élaguez les partitions
](#wait-event.lw-lock-manager.actions.pruning)
+ [
### Supprimez les index inutiles
](#wait-event.lw-lock-manager.actions.indexes)
+ [
### Réglez vos requêtes pour qu'elles utilisent le verrouillage à chemin d'accès rapide
](#wait-event.lw-lock-manager.actions.tuning)
+ [
### Procédez au réglage d'autres événements d'attente
](#wait-event.lw-lock-manager.actions.other-waits)
+ [
### Réduisez les goulots d'étranglement matériels
](#wait-event.lw-lock-manager.actions.hw-bottlenecks)
+ [
### Utilisez une fonction de regroupement de connexions
](#wait-event.lw-lock-manager.actions.pooler)
+ [
### Mise à niveau de votre version de RDS pour PostgreSQL
](#wait-event.lw-lock-manager.actions.pg-version)
### Élaguez les partitions
L'*élagage des partitions* est une stratégie d'optimisation des requêtes pour tables partitionnées de manière déclarative, qui exclut les partitions inutiles des analyses de tables, améliorant ainsi les performances. L'élagage des partitions est activé par défaut. S'il est désactivé, activez-le comme suit.
```
SET enable_partition_pruning = on;
```
Les requêtes peuvent tirer parti de l'élagage des partitions lorsque leur clause `WHERE` contient la colonne utilisée pour le partitionnement. Pour en savoir plus, consultez [Partition Pruning](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING) dans la documentation PostgreSQL.
### Supprimez les index inutiles
Votre base de données peut contenir des index inutilisés ou rarement utilisés. Si tel est le cas, pensez à les supprimer. Effectuez l’une des actions suivantes :
+ Pour en savoir plus sur la recherche des index inutiles, consultez [Unused Indexes](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes) dans le wiki PostgreSQL.
+ Exécutez PG Collector. Ce script SQL rassemble les informations de la base de données et les présente sous forme de rapport HTML. Consultez la section « Unused indexes » (Index inutilisés). Pour plus d'informations, consultez [pg-collector](https://github.com/awslabs/pg-collector) dans le référentiel AWS Labs GitHub .
### Réglez vos requêtes pour qu'elles utilisent le verrouillage à chemin d'accès rapide
Pour savoir si vos requêtes utilisent le verrouillage à chemin d'accès rapide, interrogez la colonne `fastpath` de la table `pg_locks`. Si vos requêtes n'utilisent pas le verrouillage à chemin d'accès rapide, essayez de réduire le nombre de relations par requête à moins de 16.
### Procédez au réglage d'autres événements d'attente
Si `LWLock:lock_manager` est premier ou deuxième dans la liste des attentes les plus fréquentes, vérifiez si les événements d'attente suivants apparaissent également dans la liste :
+ `Lock:Relation`
+ `Lock:transactionid`
+ `Lock:tuple`
S'ils figurent parmi les premiers de la liste, commencez par régler ces événements d'attente. Ces événements peuvent être un moteur pour `LWLock:lock_manager`.
### Réduisez les goulots d'étranglement matériels
Un goulot d'étranglement matériel peut se produire, comme une pénurie d'UC ou une saturation de votre bande passante Amazon EBS. Envisagez alors de réduire les goulots d'étranglement matériels. Procédez comme suit :
+ Procédez à une augmentation d'échelle de votre classe d'instance.
+ Optimisez les requêtes qui sollicitent énormément l'UC et la mémoire.
+ Modifiez la logique de votre application.
+ Archivez vos données.
Pour en savoir plus sur l’UC, la mémoire et la bande passante réseau EBS, consultez [Types d’instance Amazon RDS](https://aws.amazon.com/rds/instance-types/).
### Utilisez une fonction de regroupement de connexions
Si le nombre total de connexions actives dépasse le nombre maximal de vCPU, cela signifie que l'UC requise par les processus du système d'exploitation est supérieure à ce que votre type d'instance peut prendre en charge. Dans ce cas, vous pouvez utiliser ou régler un groupe de connexions. Pour plus d'informations sur le v correspondant CPUs à votre type d'instance, consultez [Amazon RDS Instance Types](https://aws.amazon.com/rds/instance-types/).
Pour en savoir plus sur les groupes de connexions, consultez les ressources suivantes :
+ [Proxy Amazon RDS ](rds-proxy.md)
+ [pgbouncer](http://www.pgbouncer.org/usage.html)
+ [Connection Pools and Data Sources](https://www.postgresql.org/docs/7.4/jdbc-datasource.html) dans la *documentation PostgreSQL*
### Mise à niveau de votre version de RDS pour PostgreSQL
Si votre version actuelle de RDS pour PostgreSQL est inférieure à 12, procédez à une mise à niveau vers la version 12 ou ultérieure. PostgreSQL versions 12 et ultérieures disposent d'un mécanisme de partition amélioré. Pour en savoir plus la version 12, consultez [Notes de mise à jour de PostgreSQL 12.0]( https://www.postgresql.org/docs/release/12.0/). Pour plus d’informations sur la mise à niveau de RDS pour PostgreSQL, consultez [Mises à niveau du moteur de base de données RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md).
# LWLock:pg\$1stat\$1statements
L'événement d' LWLockattente :pg\$1stat\$1statements se produit lorsque l'extension verrouille de manière exclusive la `pg_stat_statements` table de hachage qui suit les instructions SQL. Cela se produit dans les scénarios suivants :
+ Lorsque le nombre d’instructions suivies atteint la valeur de paramètre `pg_stat_statements.max` configurée et qu’il est nécessaire de faire de la place à d’autres entrées, l’extension effectue un tri sur le nombre d’appels, supprime les 5 % des instructions les moins exécutées et remplit à nouveau le hachage avec les entrées restantes.
+ Lorsque `pg_stat_statements` effectue une opération `garbage collection` sur le fichier `pgss_query_texts.stat` sur le disque et réécrit le fichier.
**Topics**
+ [
## Versions de moteur prises en charge
](#apg-rpg-lwlockpgstat.supported)
+ [
## Contexte
](#apg-rpg-lwlockpgstat.context)
+ [
## Causes probables de l’augmentation du nombre d’événements d’attente
](#apg-rpg-lwlockpgstat.causes)
+ [
## Actions
](#apg-rpg-lwlockpgstat.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente sont prises en charge pour toutes les versions de RDS pour PostgreSQL.
## Contexte
**Comprendre l’extension pg\$1stat\$1statements** : l’extension pg\$1stat\$1statements suit les statistiques d’exécution des instructions SQL dans une table de hachage. L’extension suit les instructions SQL jusqu’à la limite définie par le paramètre `pg_stat_statements.max`. Ce paramètre détermine le nombre maximum d’instructions pouvant être suivies, ce qui correspond au nombre maximum de lignes dans la vue pg\$1stat\$1statements.
**Persistance des statistiques des instructions** : l’extension conserve les statistiques des instructions lors des redémarrages de l’instance en :
+ Écrivant des données dans un fichier nommé pg\$1stat\$1statements.stat
+ Utilisant le paramètre pg\$1stat\$1statements.save pour contrôler le comportement de persistance
Lorsque pg\$1stat\$1statements.save est :
+ activé (par défaut) : les statistiques sont enregistrées à l’arrêt et rechargées au démarrage du serveur
+ désactivé : les statistiques ne sont ni enregistrées à l’arrêt, ni rechargées au démarrage du serveur
**Stockage du texte des requêtes** : l’extension stocke le texte des requêtes suivies dans un fichier nommé `pgss_query_texts.stat`. Ce fichier peut atteindre le double de la taille moyenne de toutes les instructions SQL suivies avant le récupérateur de mémoire. L’extension nécessite un verrouillage exclusif de la table de hachage pendant les opérations de nettoyage et de réécriture du fichier `pgss_query_texts.stat`.
**Processus d’annulation de l’allocation des instructions** : lorsque le nombre d’instructions suivies atteint la limite `pg_stat_statements.max` et que de nouvelles instructions doivent être suivies, l’extension :
+ Prend un verrou exclusif (:pg\$1stat\$1statementsLWLock) sur la table de hachage.
+ Charge les données existantes dans la mémoire locale.
+ Effectue un tri rapide en fonction du nombre d’appels.
+ Supprime les instructions les moins appelées (les 5 % inférieures).
+ Reremplit la table de hachage avec les entrées restantes.
**Surveillance de l’annulation de l’allocation des instructions** : dans PostgreSQL 14 et versions ultérieures, vous pouvez surveiller l’annulation de l’allocation des instructions à l’aide de la vue pg\$1stat\$1statements\$1info. Cette vue inclut une colonne dealloc qui indique le nombre de fois où l’allocation des instructions a été annulée pour faire de la place à de nouvelles.
Si l’annulation de l’allocation des instructions se produit fréquemment, cela accroît la fréquence du récupérateur de mémoire au niveau du fichier `pgss_query_texts.stat` sur le disque.
## Causes probables de l’augmentation du nombre d’événements d’attente
Les causes typiques de l’allongement des temps d’attente de `LWLock:pg_stat_statements` sont les suivantes :
+ Augmentation du nombre de requêtes uniques utilisées par l’application.
+ La valeur du paramètre `pg_stat_statements.max` est faible par rapport au nombre de requêtes uniques utilisées.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente. Vous pouvez identifier les événements `LWLock:pg_stat_statements` en utilisant Analyse des performances d’Amazon RDS ou en interrogeant la vue `pg_stat_activity`.
Ajustez les `pg_stat_statements` paramètres suivants pour contrôler le comportement de suivi et réduire:les instructions LWLock pg\$1stat\$1 attendent les événements.
**Topics**
+ [
### Désactivation du paramètre pg\$1stat\$1statements.track
](#apg-rpg-lwlockpgstat.actions.disabletrack)
+ [
### Augmentation de la valeur du paramètre pg\$1stat\$1statements.max
](#apg-rpg-lwlockpgstat.actions.increasemax)
+ [
### Désactivation du paramètre pg\$1stat\$1statements.track\$1utility
](#apg-rpg-lwlockpgstat.actions.disableutility)
### Désactivation du paramètre pg\$1stat\$1statements.track
Si l'événement:pg\$1stat\$1statements LWLock wait a un impact négatif sur les performances de la base de données et qu'une solution rapide est requise avant de poursuivre l'analyse de la vue `pg_stat_statements` afin d'identifier la cause première, le paramètre `pg_stat_statements.track` peut être désactivé en le définissant sur. `none` Cela désactive la collecte des statistiques des instructions.
### Augmentation de la valeur du paramètre pg\$1stat\$1statements.max
Pour réduire les annulations d’allocation d’instructions et minimiser le récupérateur de mémoire du fichier `pgss_query_texts.stat` sur le disque, augmentez la valeur du paramètre `pg_stat_statements.max`. La valeur par défaut est `5,000`.
**Note**
Le paramètre `pg_stat_statements.max` est statique. Vous devez redémarrer votre instance de base de données pour appliquer les éventuelles modifications apportées à ce paramètre.
### Désactivation du paramètre pg\$1stat\$1statements.track\$1utility
Vous pouvez analyser la vue pg\$1stat\$1statements pour déterminer les commandes utilitaires consommant le plus de ressources suivies par `pg_stat_statements`.
Le paramètre `pg_stat_statements.track_utility` contrôle si le module suit les commandes utilitaires, qui incluent toutes les commandes sauf SELECT, INSERT, UPDATE, DELETE et MERGE. Par défaut, ce paramètre est défini sur `on`.
Par exemple, lorsque votre application utilise de nombreuses requêtes de point de sauvegarde, qui sont intrinsèquement uniques, cela peut augmenter l’annulation de l’allocation des instructions. Pour résoudre ce problème, vous pouvez désactiver le paramètre `pg_stat_statements.track_utility` pour empêcher `pg_stat_statements` de suivre les requêtes de point de sauvegarde.
**Note**
Le paramètre `pg_stat_statements.track_utility` est un paramètre dynamique. Vous pouvez modifier sa valeur sans redémarrer votre instance de base de données.
**Example Exemple de requêtes de point de sauvegarde uniques dans pg\$1stat\$1statements**
```
query | queryid
-------------------------------------------------+---------------------
SAVEPOINT JDBC_SAVEPOINT_495701 | -7249565344517699703
SAVEPOINT JDBC_SAVEPOINT_1320 | -1572997038849006629
SAVEPOINT JDBC_SAVEPOINT_26739 | 54791337410474486
SAVEPOINT JDBC_SAVEPOINT_1294466 | 8170064357463507593
ROLLBACK TO SAVEPOINT JDBC_SAVEPOINT_65016 | -33608214779996400
SAVEPOINT JDBC_SAVEPOINT_14185 | -2175035613806809562
SAVEPOINT JDBC_SAVEPOINT_45837 | -6201592986750645383
SAVEPOINT JDBC_SAVEPOINT_1324 | 6388797791882029332
```
PostgreSQL 17 inclut plusieurs améliorations pour le suivi des commandes utilitaires :
+ Les noms des points de sauvegarde sont désormais affichés sous forme de constantes.
+ La transaction globale IDs (GIDs) des commandes de validation en deux phases est désormais affichée sous forme de constantes.
+ Les noms des instructions DEALLOCATE sont affichés sous forme de constantes.
+ Les paramètres CALL sont désormais affichés sous forme de constantes.
# LWLock:SubTransSLRU (:) LWLock SubtransControlLock
Les événements `LWLock:SubtransSLRU` and `LWLock:SubtransBuffer` wait indiquent qu'une session attend d'accéder au cache simple le moins récemment utilisé (SLRU) pour les informations relatives aux sous-transactions. Cela se produit lors de la détermination de la visibilité des transactions et des relations parent-enfant.
+ `LWLock:SubtransSLRU`: un processus attend d'accéder au cache simple le moins récemment utilisé (SLRU) pour une sous-transaction. Dans RDS pour PostgreSQL avant la version 13, cet événement d'attente est appelé. `SubtransControlLock`
+ `LWLock:SubtransBuffer`: Un processus attend I/O une sous-transaction dans une mémoire tampon simple la moins récemment utilisée (SLRU). Dans RDS pour PostgreSQL avant la version 13, cet événement d'attente est appelé. `subtrans`
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.lwlocksubtransslru.supported)
+ [
## Contexte
](#wait-event.lwlocksubtransslru.context)
+ [
## Causes probables de l’augmentation du nombre d’événements d’attente
](#wait-event.lwlocksubtransslru.causes)
+ [
## Actions
](#wait-event.lwlocksubtransslru.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente sont prises en charge pour toutes les versions de RDS pour PostgreSQL.
## Contexte
**Comprendre les sous-transactions** — Une sous-transaction est une transaction au sein d'une transaction dans PostgreSQL. Elle est également connue sous le nom de transaction imbriquée.
Les sous-transactions sont généralement créées lorsque vous utilisez :
+ Commandes de l’`SAVEPOINT`
+ Blocs d'exception (`BEGIN/EXCEPTION/END`)
Les sous-transactions vous permettent d'annuler certaines parties d'une transaction sans affecter l'ensemble de la transaction. Cela vous donne un contrôle précis sur la gestion des transactions.
**Détails de mise en œuvre** — PostgreSQL implémente les sous-transactions sous forme de structures imbriquées dans les transactions principales. Chaque sous-transaction reçoit son propre identifiant de transaction.
Principaux aspects de la mise en œuvre :
+ IDs Les transactions sont suivies dans `pg_xact`
+ Les relations parent-enfant sont stockées dans `pg_subtrans` le sous-répertoire sous `PGDATA`
+ Chaque session de base de données peut gérer jusqu'à des `64` sous-transactions actives
+ Le dépassement de cette limite entraîne un débordement des sous-transactions, ce qui nécessite d'accéder au cache simple utilisé le moins récemment (SLRU) pour les informations relatives aux sous-transactions
## Causes probables de l’augmentation du nombre d’événements d’attente
Les causes courantes de contention du SLRU lié aux sous-transactions sont les suivantes :
+ **Utilisation excessive de SAVEPOINT et de gestion des EXCEPTIONS** : PL/pgSQL les procédures dotées de `EXCEPTION` gestionnaires créent automatiquement des points de sauvegarde implicites, que des exceptions se produisent ou non. Chacune `SAVEPOINT` initie une nouvelle sous-transaction. Lorsqu'une seule transaction cumule plus de 64 sous-transactions, elle déclenche un dépassement du SLRU des sous-transactions.
+ **Configurations du pilote et de l'ORM** : `SAVEPOINT` l'utilisation peut être explicite dans le code de l'application ou implicite dans les configurations du pilote. De nombreux outils ORM et frameworks d'applications couramment utilisés prennent en charge les transactions imbriquées de manière native. Voici quelques exemples courants :
+ Le paramètre du pilote JDBC`autosave`, s'il est défini sur `always` ou`conservative`, génère des points de sauvegarde avant chaque requête.
+ Définitions de transactions Spring Framework lorsqu'elles sont définies sur`propagation_nested`.
+ Rails quand `requires_new: true` c'est réglé.
+ SQLAlchemy quand `session.begin_nested` est utilisé.
+ Django lorsque des `atomic()` blocs imbriqués sont utilisés.
+ GORM lorsqu'il `Savepoint` est utilisé.
+ PSQLodBC lorsque le paramètre de niveau d'annulation est défini sur Annulation au niveau de l'instruction (par exemple,). `PROTOCOL=7.4-2`
+ **Charges de travail simultanées élevées associées à des transactions et sous-transactions de longue durée : lorsque le nombre de sous-transactions** SLRU déborde lors de charges de travail simultanées élevées et de transactions et sous-transactions de longue durée, PostgreSQL est confronté à une augmentation des contentions. Cela se traduit par des temps d'attente élevés `LWLock:SubtransBuffer` et des `LWLock:SubtransSLRU` blocages.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente. Certaines actions apportent un soulagement immédiat, tandis que d'autres nécessitent une enquête et une correction à long terme.
**Topics**
+ [
### Surveillance de l'utilisation des sous-transactions
](#wait-event.lwlocksubtransslru.actions.monitor)
+ [
### Configuration des paramètres de mémoire
](#wait-event.lwlocksubtransslru.actions.memory)
+ [
### Actions à long terme
](#wait-event.lwlocksubtransslru.actions.longterm)
### Surveillance de l'utilisation des sous-transactions
Pour les versions 16.1 et ultérieures de PostgreSQL, utilisez la requête suivante pour surveiller le nombre de sous-transactions et l'état des dépassements par backend. Cette requête associe les statistiques du backend aux informations d'activité pour indiquer quels processus utilisent des sous-transactions :
```
SELECT a.pid, usename, query, state, wait_event_type,
wait_event, subxact_count, subxact_overflowed
FROM (SELECT id, pg_stat_get_backend_pid(id) pid, subxact_count, subxact_overflowed
FROM pg_stat_get_backend_idset() id
JOIN LATERAL pg_stat_get_backend_subxact(id) AS s ON true
) a
JOIN pg_stat_activity b ON a.pid = b.pid;
```
Pour les versions 13.3 et ultérieures de PostgreSQL, surveillez la vue pour détecter la pression `pg_stat_slru` du cache des sous-transactions. La requête SQL suivante extrait les statistiques du cache SLRU pour le composant Subtrans :
```
SELECT * FROM pg_stat_slru WHERE name = 'Subtrans';
```
Une `blks_read` valeur en augmentation constante indique un accès fréquent au disque pour les sous-transactions non mises en cache, ce qui indique une pression potentielle sur le cache du SLRU.
### Configuration des paramètres de mémoire
Pour PostgreSQL 17.1 et versions ultérieures, vous pouvez configurer la taille du cache SLRU des sous-transactions à l'aide du paramètre. `subtransaction_buffers` L'exemple de configuration suivant montre comment définir le paramètre du tampon de sous-transactions :
```
subtransaction_buffers = 128
```
Ce paramètre indique la quantité de mémoire partagée utilisée pour mettre en cache le contenu des sous-transactions (`pg_subtrans`). Lorsqu'elle est spécifiée sans unités, la valeur représente des blocs d'`BLCKSZ`octets, généralement de 8 Ko chacun. Par exemple, définir la valeur sur 128 alloue 1 Mo (128 x 8 Ko) de mémoire au cache de sous-transactions.
**Note**
Vous pouvez définir ce paramètre au niveau du cluster afin que toutes les instances restent cohérentes. Testez et ajustez la valeur en fonction de vos exigences spécifiques en matière de charge de travail et de classe d'instance. Vous devez redémarrer l'instance du rédacteur pour que les modifications des paramètres soient prises en compte.
### Actions à long terme
+ **Examinez le code et les configurations de l'**application : passez en revue les configurations du code de votre application et du pilote de base de données pour en déterminer `SAVEPOINT` l'utilisation explicite et implicite et l'utilisation des sous-transactions en général. Identifiez les transactions susceptibles de générer plus de 64 sous-transactions.
+ **Réduisez l'utilisation des points de sauvegarde** — Minimisez l'utilisation de points de sauvegarde dans vos transactions :
+ Passez en revue PL/pgSQL les procédures et les fonctions à l'aide de blocs EXCEPTION. Les blocs EXCEPTION créent automatiquement des points de sauvegarde implicites, ce qui peut contribuer au dépassement des sous-transactions. Chaque clause EXCEPTION crée une sous-transaction, qu'une exception se produise ou non pendant l'exécution.
**Example**
Exemple 1 : utilisation problématique du bloc EXCEPTION
L'exemple de code suivant montre l'utilisation problématique du bloc EXCEPTION qui crée plusieurs sous-transactions :
```
CREATE OR REPLACE FUNCTION process_user_data()
RETURNS void AS $$
DECLARE
user_record RECORD;
BEGIN
FOR user_record IN SELECT * FROM users LOOP
BEGIN
-- This creates a subtransaction for each iteration
INSERT INTO user_audit (user_id, action, timestamp)
VALUES (user_record.id, 'processed', NOW());
UPDATE users
SET last_processed = NOW()
WHERE id = user_record.id;
EXCEPTION
WHEN unique_violation THEN
-- Handle duplicate audit entries
UPDATE user_audit
SET timestamp = NOW()
WHERE user_id = user_record.id AND action = 'processed';
END;
END LOOP;
END;
$$ LANGUAGE plpgsql;
```
L'exemple de code amélioré suivant réduit l'utilisation des sous-transactions en utilisant UPSERT au lieu de la gestion des exceptions :
```
CREATE OR REPLACE FUNCTION process_user_data()
RETURNS void AS $$
DECLARE
user_record RECORD;
BEGIN
FOR user_record IN SELECT * FROM users LOOP
-- Use UPSERT to avoid exception handling
INSERT INTO user_audit (user_id, action, timestamp)
VALUES (user_record.id, 'processed', NOW())
ON CONFLICT (user_id, action)
DO UPDATE SET timestamp = NOW();
UPDATE users
SET last_processed = NOW()
WHERE id = user_record.id;
END LOOP;
END;
$$ LANGUAGE plpgsql;
```
**Example**
Exemple 2 : gestionnaire d'exceptions STRICT
L'exemple de code suivant montre la gestion problématique des EXCEPTIONS avec NO\$1DATA\$1FOUND :
```
CREATE OR REPLACE FUNCTION get_user_email(p_user_id INTEGER)
RETURNS TEXT AS $$
DECLARE
user_email TEXT;
BEGIN
BEGIN
-- STRICT causes an exception if no rows or multiple rows found
SELECT email INTO STRICT user_email
FROM users
WHERE id = p_user_id;
RETURN user_email;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RETURN 'Email not found';
END;
END;
$$ LANGUAGE plpgsql;
```
L'exemple de code amélioré suivant permet d'éviter les sous-transactions en utilisant IF NOT FOUND au lieu de la gestion des exceptions :
```
CREATE OR REPLACE FUNCTION get_user_email(p_user_id INTEGER)
RETURNS TEXT AS $$
DECLARE
user_email TEXT;
BEGIN
SELECT email INTO user_email
FROM users
WHERE id = p_user_id;
IF NOT FOUND THEN
RETURN 'Email not found';
ELSE
RETURN user_email;
END IF;
END;
$$ LANGUAGE plpgsql;
```
+ Pilote JDBC — Le `autosave` paramètre, s'il est défini sur `always` ou`conservative`, génère des points de sauvegarde avant chaque requête. Évaluez si le `never` paramètre est acceptable pour votre application.
+ Pilote ODBC PostgreSQL (PSQLodBC) : le paramètre du niveau de restauration (pour la restauration au niveau des instructions) crée des points de sauvegarde implicites pour activer la fonctionnalité de restauration des instructions. Déterminez si une annulation au niveau de la transaction est acceptable ou non pour votre application.
+ Examiner les configurations de transactions ORM
+ Envisagez d'autres stratégies de gestion des erreurs qui ne nécessitent pas de points de sauvegarde
+ **Optimisez la conception** des transactions : restructurez les transactions pour éviter une imbrication excessive et réduire le risque de débordement des sous-transactions.
+ **Réduction des transactions de longue durée — Les transactions** de longue durée peuvent exacerber les problèmes de sous-transactions en conservant plus longtemps les informations relatives aux sous-transactions. Surveillez les métriques Performance Insights et configurez le `idle_in_transaction_session_timeout` paramètre pour mettre fin automatiquement aux transactions inactives.
+ Surveillez les indicateurs de Performance Insights : suivez des indicateurs tels que `idle_in_transaction_count` (nombre de sessions inactives dans l'état de transaction) et `idle_in_transaction_max_time` (durée de la transaction inactive la plus longue) pour détecter les transactions de longue durée.
+ Configurer `idle_in_transaction_session_timeout` : définissez ce paramètre dans votre groupe de paramètres pour mettre fin automatiquement aux transactions inactives après une durée spécifiée.
+ Surveillance proactive : surveillez les occurrences élevées d'événements `LWLock:SubtransBuffer` et `LWLock:SubtransSLRU` attendez afin de détecter les litiges liés aux sous-transactions avant qu'ils ne deviennent critiques.
# Timeout:PgSleep
L'événement `Timeout:PgSleep` se produit lorsqu'un processus serveur a appelé la fonction `pg_sleep` et attend l'expiration du délai de mise en veille.
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.timeoutpgsleep.context.supported)
+ [
## Causes probables de l'allongement des temps d'attente
](#wait-event.timeoutpgsleep.causes)
+ [
## Actions
](#wait-event.timeoutpgsleep.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d'attente sont prises en charge pour toutes les versions de RDS for PostgreSQL.
## Causes probables de l'allongement des temps d'attente
Cet événement d'attente se produit lorsqu'une application, une fonction stockée ou un utilisateur émet une instruction SQL qui appelle l'une des fonctions suivantes :
+ `pg_sleep`
+ `pg_sleep_for`
+ `pg_sleep_until`
Les fonctions précédentes retardent l'exécution jusqu'à ce que le nombre de secondes spécifié se soit écoulé. Par exemple, `SELECT pg_sleep(1)` marque une pause d'une seconde. Pour en savoir plus, consultez [Delaying Execution](https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-DELAY) dans la documentation PostgreSQL.
## Actions
Identifiez l'instruction qui exécutait la fonction `pg_sleep`. Déterminez si l'utilisation de la fonction est appropriée.
# Timeout:VacuumDelay
L'événement `Timeout:VacuumDelay` indique que la limite de coût des E/S du processus vacuum a été dépassée et que le processus vacuum a été mis en veille. Les opérations vacuum s'arrêtent pendant la durée spécifiée dans le paramètre de délai de coût correspondant, puis le processus reprend. Pour la commande vacuum manuelle, le délai est spécifié dans le paramètre `vacuum_cost_delay`. Pour le démon autovacuum, le délai est spécifié dans `autovacuum_vacuum_cost_delay parameter.`
**Topics**
+ [
## Versions de moteur prises en charge
](#wait-event.timeoutvacuumdelay.context.supported)
+ [
## Contexte
](#wait-event.timeoutvacuumdelay.context)
+ [
## Causes probables de l'allongement des temps d'attente
](#wait-event.timeoutvacuumdelay.causes)
+ [
## Actions
](#wait-event.timeoutvacuumdelay.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d'attente sont prises en charge pour toutes les versions de RDS for PostgreSQL.
## Contexte
PostgreSQL possède à la fois un démon autovacuum et une commande vacuum manuelle. Le processus autovacuum est « activé » par défaut pour les instances de base de données RDS for PostgreSQL. La commande vacuum manuelle est utilisée selon les besoins, par exemple pour purger les tables des tuples morts ou générer de nouvelles statistiques.
Lorsque le processus vacuum est en cours, PostgreSQL utilise un compteur interne pour suivre les coûts estimés au fur et à mesure que le système effectue les diverses opérations d'E/S. Quand le compteur atteint la valeur spécifiée par le paramètre de limite de coût, le processus exécutant l'opération est en veille pendant la brève durée spécifiée dans le paramètre de délai de coût. Il réinitialise ensuite le compteur et poursuit les opérations.
Le processus vacuum comporte des paramètres qui peuvent être utilisés pour réguler la consommation de ressources. Le processus autovacuum et la commande vacuum manuelle ont leurs propres paramètres pour définir la valeur limite de coût. Ils ont également leurs propres paramètres pour spécifier un délai de coût, c'est-à-dire le temps alloué pour mettre en veille le processus vacuum quand la limite est atteinte. De cette manière, le paramètre de délai de coût fonctionne comme un mécanisme de limitation de la consommation de ressources. Les listes suivantes contiennent les descriptions de ces paramètres.
**Paramètres affectant la limitation du démon autovacuum**
+ `[autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)` – Spécifie la valeur limite de coût à utiliser dans les opérations vacuum automatiques. L'augmentation de la valeur de ce paramètre permet au processus vacuum d'utiliser davantage de ressources et réduit l'événement d'attente `Timeout:VacuumDelay`.
+ `[autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)` – Spécifie la valeur de délai de coût à utiliser dans les opérations vacuum automatiques. La valeur par défaut est de 2 millisecondes. La définition du paramètre de délai sur 0 désactive le mécanisme de limitation, si bien que l'événement d'attente `Timeout:VacuumDelay` n'apparaîtra pas.
Pour plus d'informations, veuillez consulter [Action Vacuum automatique](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY) dans la documentation PostgreSQL.
**Paramètres affectant la limitation du processus vacuum manuel**
+ `vacuum_cost_limit` – Le seuil à partir duquel le processus vacuum est mis en veille. Par défaut, cette limite est de 200. Ce nombre représente les estimations des coûts cumulés pour les E/S supplémentaires requises par les diverses ressources. L'augmentation de cette valeur réduit le nombre d'événements d'attente `Timeout:VacuumDelay`.
+ `vacuum_cost_delay` – La durée pendant laquelle le processus vacuum est en veille quand la limite de coût du processus vacuum est atteinte. La valeur par défaut est 0, ce qui signifie que cette fonctionnalité est désactivée. Vous pouvez définir une valeur entière pour spécifier le nombre de millisecondes nécessaires à l'activation de cette fonctionnalité, mais nous vous recommandons de conserver la valeur par défaut.
Pour plus d'informations sur le paramètre `vacuum_cost_delay`, consultez [Consommation des ressources](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST) dans la documentation PostgreSQL.
Pour en savoir plus sur la configuration et l'utilisation d'autovacuum avec RDS for PostgreSQL, consultez [Utilisation de la fonction autovacuum de PostgreSQL sur Amazon RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md).
## Causes probables de l'allongement des temps d'attente
Le paramètre `Timeout:VacuumDelay` est affecté par l'équilibre entre les valeurs des paramètres de limite de coût (`vacuum_cost_limit`, `autovacuum_vacuum_cost_limit`) et les paramètres de délai de coût (`vacuum_cost_delay`, `autovacuum_vacuum_cost_delay`) qui contrôlent la durée de veille du processus vacuum. L'augmentation d'une valeur de paramètre de limite de coût permet d'utiliser davantage de ressources pour le processus vacuum avant qu'il soit mis en veille. Cela se traduit par une diminution des événements d'attente `Timeout:VacuumDelay`. L'augmentation de l'un ou l'autre des paramètres de délai entraîne une hausse de la fréquence et de la durée de l'événement d'attente `Timeout:VacuumDelay`.
Le réglage du paramètre `autovacuum_max_workers` peut également augmenter les nombres de `Timeout:VacuumDelay`. Chaque processus de travail autovacuum supplémentaire contribue au contre-mécanisme interne, de sorte que la limite peut être atteinte plus rapidement qu'avec un seul processus de travail autovacuum. Comme la limite de coût est atteinte plus rapidement, le délai de coût entre en vigueur plus fréquemment, ce qui se traduit par un plus grand nombre d'événements d'attente `Timeout:VacuumDelay`. Pour plus d'informations, consultez [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS) dans la documentation PostgreSQL.
Les objets volumineux, de 500 Go ou plus, déclenchent également cet événement d'attente, car le traitement des objets volumineux par le processus vacuum peut prendre un certain temps.
## Actions
Si les opérations vacuum se terminent comme prévu, aucune correction n'est requise. En d'autres termes, cet événement d'attente n'indique pas nécessairement un problème. Il indique que le processus vacuum est mis en veille pendant la période spécifiée dans le paramètre de délai, afin que les ressources puissent être affectées à d'autres processus qui doivent être achevés.
Si vous souhaitez terminer plus rapidement les opérations vacuum, vous pouvez réduire les paramètres de délai. Cela raccourcit le temps de veille du processus vacuum.
# Optimisation de RDS pour PostgreSQL Aurora PostgreSQL DevOps
DevOpsGuru Proactive Insights détecte les conditions sur vos instances de base de données RDS pour PostgreSQL (clusters de bases de données ) susceptibles de provoquer des problèmes, et vous en informe avant qu'ils ne surviennent. Des insights proactifs peuvent vous alerter lorsqu’une connexion reste inactive pendant une transaction de longue durée. Pour plus d’informations sur la résolution des problèmes liés aux connexions restées inactives trop longtemps pendant une transaction, consultez [La base de données a une connexion de longue durée à l’état Transaction inactive](#proactive-insights.idle-txn)
DevOpsGuru peut effectuer les opérations suivantes :
+ Éviter de nombreux problèmes courants liés aux bases de données en recoupant la configuration de votre base de données par rapport aux paramètres courants recommandés.
+ Vous alerter face à des problèmes critiques dans votre flotte qui, s’ils ne sont pas vérifiés, peuvent entraîner des problèmes plus importants ultérieurement.
+ Vous alerter face à des problèmes nouvellement découverts.
Chaque insight proactif contient une analyse de la cause du problème et des recommandations d’actions correctives.
Pour plus d'informations sur Amazon DevOps Guru pour Amazon RDS, consultez[Analyse des anomalies de performance avec Amazon DevOps Guru pour Amazon RDS](devops-guru-for-rds.md).
## La base de données a une connexion de longue durée à l’état Transaction inactive
Une connexion à la base de données est à l’état `idle in transaction` depuis plus de 1 800 secondes.
**Topics**
+ [
### Versions de moteur prises en charge
](#proactive-insights.idle-txn.context.supported)
+ [
### Contexte
](#proactive-insights.idle-txn.context)
+ [
### Causes probables de ce problème
](#proactive-insights.idle-txn.causes)
+ [
### Actions
](#proactive-insights.idle-txn.actions)
+ [
### Métriques pertinentes
](#proactive-insights.idle-txn.metrics)
### Versions de moteur prises en charge
Ces données d’insight sont prises en charge pour toutes les versions de RDS pour PostgreSQL.
### Contexte
Une transaction à l’état `idle in transaction` peut contenir des verrous qui bloquent d’autres requêtes. Elle peut également empêcher `VACUUM` (y compris autovacuum) de nettoyer les lignes inactives, ce qui entraînerait le gonflement des index ou des tables ou le bouclage des identifiants de transactions.
### Causes probables de ce problème
Une transaction initiée dans une session interactive avec BEGIN ou START TRANSACTION ne s’est pas terminée à l’aide d’une commande COMMIT, ROLLBACK ou END. Cela entraîne le passage de la transaction à l’état `idle in transaction`.
### Actions
Vous pouvez trouver les transactions inactives en exécutant la requête `pg_stat_activity`.
Dans votre client SQL, exécutez la requête suivante pour répertorier toutes les connexions à l’état `idle in transaction` et les ordonner par durée :
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
Nous vous recommandons différentes actions en fonction des causes de votre insight.
**Topics**
+ [
#### Arrêt de la transaction
](#proactive-insights.idle-txn.actions.end-txn)
+ [
#### Interruption de la connexion
](#proactive-insights.idle-txn.actions.end-connection)
+ [
#### Configuration du paramètre idle\$1in\$1transaction\$1session\$1timeout
](#proactive-insights.idle-txn.actions.parameter)
+ [
#### Vérification du statut AUTOCOMMIT
](#proactive-insights.idle-txn.actions.autocommit)
+ [
#### Vérification de la logique de transaction dans le code de votre application
](#proactive-insights.idle-txn.actions.app-logic)
#### Arrêt de la transaction
Lorsque vous lancez une transaction dans une session interactive avec BEGIN ou START TRANSACTION, elle passe à l’état `idle in transaction`. Elle reste dans cet état jusqu’à ce que vous terminiez la transaction en émettant une commande COMMIT, ROLLBACK ou END, ou que vous déconnectiez complètement la connexion pour annuler la transaction.
#### Interruption de la connexion
Mettez fin à la connexion avec une transaction inactive à l’aide de la requête suivante :
```
SELECT pg_terminate_backend(pid);
```
pid est l’ID de processus de la connexion.
#### Configuration du paramètre idle\$1in\$1transaction\$1session\$1timeout
Définissez le paramètre `idle_in_transaction_session_timeout` dans le nouveau groupe de paramètres. La configuration de ce paramètre présente l’avantage de ne pas nécessiter d’intervention manuelle pour mettre fin à la longue période d’inactivité de la transaction. Pour plus d’informations sur ce paramètre, consultez [la documentation PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-client.html).
Le message suivant sera enregistré dans le fichier journal de PostgreSQL après l’interruption de la connexion, quand une transaction sera dans l’état idle\$1in\$1transaction pendant un temps supérieur à la durée spécifiée.
```
FATAL: terminating connection due to idle in transaction timeout
```
#### Vérification du statut AUTOCOMMIT
AUTOCOMMIT est activé par défaut. Mais s’il est désactivé accidentellement dans le client, veillez à le réactiver.
+ Dans votre client psql, exécutez la commande suivante :
```
postgres=> \set AUTOCOMMIT on
```
+ Dans pgadmin, activez-la en choisissant l’option AUTOCOMMIT à partir de la flèche déroulante.
![\[Dans pgadmin, choisissez AUTOCOMMIT pour l’activer.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/apg-insight-pgadmin-autocommit.png)
#### Vérification de la logique de transaction dans le code de votre application
Examinez la logique de votre application pour détecter d’éventuels problèmes. Procédez comme suit :
+ Vérifiez si la validation automatique JDBC est définie sur true dans votre application. Pensez également à utiliser des commandes `COMMIT` explicites dans votre code.
+ Vérifiez votre logique de gestion des erreurs pour voir si elle clôture une transaction après des erreurs.
+ Vérifiez si votre application met du temps à traiter les lignes renvoyées par une requête lorsque la transaction est ouverte. Si tel est le cas, pensez à coder l’application pour clôturer la transaction avant de traiter les lignes.
+ Vérifiez si une transaction contient de nombreuses opérations de longue durée. Si tel est le cas, divisez une transaction individuelle en plusieurs transactions.
### Métriques pertinentes
Les métriques PI suivantes sont liées à cet insight :
+ idle\$1in\$1transaction\$1count : nombre de sessions à l’état `idle in transaction`.
+ idle\$1in\$1transaction\$1max\$1time : durée de la transaction la plus longue à l’état `idle in transaction`.
# Utilisation des extensions PostgreSQL avec Amazon RDS pour PostgreSQL
Vous pouvez étendre les fonctionnalités de PostgreSQL en installant divers extensions et modules. Par exemple, pour utiliser des données spatiales, vous pouvez installer et utiliser l'extension PostGIS. Pour plus d’informations, consultez [Gestion des données spatiales avec l’extension PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md). Par exemple, si vous souhaitez améliorer la saisie de données pour des tables très volumineuses, vous pouvez envisager de partitionner vos données en utilisant l'extension `pg_partman`. Pour en savoir plus, consultez [Gestion des partitions PostgreSQL avec l’extension pg\$1partman](PostgreSQL_Partitions.md).
**Note**
RDS pour PostgreSQL prend en charge le kit Trusted Language Extensions pour PostgreSQL via l’extension `pg_tle`, que vous pouvez ajouter à votre instance de base de données. En utilisant cette extension, les développeurs peuvent créer leurs propres extensions PostgreSQL dans un environnement sûr qui simplifie les exigences d'installation et de configuration. Pour en savoir plus sur les versions de RDS pour PostgreSQL prenant en charge l’extension `pg_tle` et pour plus d’informations, consultez [Utilisation de Trusted Language Extensions pour PostgreSQL](PostgreSQL_trusted_language_extension.md).
Dans certains cas, plutôt que d’installer une extension, vous pouvez ajouter un module spécifique à la liste de `shared_preload_libraries` dans votre groupe de paramètres de base de données personnalisé de votre instance de base de données RDS pour PostgreSQL. Généralement, le groupe de paramètres du cluster de bases de données par défaut charge uniquement le `pg_stat_statements`, mais plusieurs autres modules peuvent être ajoutés à la liste. Par exemple, vous pouvez ajouter une fonctionnalité de planification en ajoutant le module `pg_cron`, comme indiqué dans [Planification de la maintenance avec l’extension PostgreSQL pg\$1cron](PostgreSQL_pg_cron.md). Autre exemple, vous pouvez enregistrer les plans d'exécution des requêtes en chargeant le module `auto_explain`. Pour en savoir plus, consultez la section [Enregistrement des plans d'exécution des requêtes](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) dans le centre de AWS connaissances.
Selon votre version de RDS pour PostgreSQL, l’installation d’une extension peut exiger des autorisations `rds_superuser`, comme suit :
+ Pour RDS pour PostgreSQL version 12 et versions antérieures, l’installation d’extensions exige des privilèges `rds_superuser`.
+ Pour RDS pour PostgreSQL version 13 et versions ultérieures, les utilisateurs (rôles) disposant d’autorisations de création sur une instance de base de données donnée peuvent installer et utiliser n’importe quelle *extension approuvée*. Pour obtenir la liste des extensions approuvées, consultez [Extensions de confiance PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.Extensions.Trusted).
Vous pouvez également spécifier précisément quelles extensions peuvent être installées sur votre instance de base de données RDS pour PostgreSQL, en les répertoriant dans le paramètre `rds.allowed_extensions`. Pour plus d’informations, consultez [Restriction de l'installation des extensions PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Pour en savoir sur le rôle `rds_superuser`, consultez [Comprendre les rôles et les autorisations PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
**Topics**
+ [
# Utilisation des fonctions de l'extension orafce
](Appendix.PostgreSQL.CommonDBATasks.orafce.md)
+ [
# Utilisation de la prise en charge de la délégation des extensions Amazon RDS pour PostgreSQL
](RDS_delegated_ext.md)
+ [
# Gestion des partitions PostgreSQL avec l’extension pg\$1partman
](PostgreSQL_Partitions.md)
+ [
# Utilisation de pgAudit pour journaliser l'activité de la base de données
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)
+ [
# Planification de la maintenance avec l’extension PostgreSQL pg\$1cron
](PostgreSQL_pg_cron.md)
+ [
# Utilisation de pglogical pour synchroniser les données entre les instances
](Appendix.PostgreSQL.CommonDBATasks.pglogical.md)
+ [
# Utilisation de pgactive pour prendre en charge la réplication active-active
](Appendix.PostgreSQL.CommonDBATasks.pgactive.md)
+ [
# Réduction du gonflement des tables et des index avec l’extension pg\$1repack
](Appendix.PostgreSQL.CommonDBATasks.pg_repack.md)
+ [
# Mise à niveau et utilisation de l' PLV8 extension
](PostgreSQL.Concepts.General.UpgradingPLv8.md)
+ [
# Utilisation PL/Rust pour écrire des fonctions PostgreSQL dans le langage Rust
](PostgreSQL.Concepts.General.Using.PL_Rust.md)
+ [
# Gestion des données spatiales avec l’extension PostGIS
](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md)
# Utilisation des fonctions de l'extension orafce
L'extension orafce fournit des fonctions et des opérateurs qui émulent un sous-ensemble de fonctions et de packages à partir d'une base de données Oracle. L'extension orafce vous permet de porter plus facilement une application Oracle vers PostgreSQL. Cette extension est prise en charge sur RDS for PostgreSQL versions 9.6.6 et ultérieures. Pour plus d'informations sur Oracle, voir [orace](https://github.com/orafce/orafce) on. GitHub
**Note**
RDS for PostgreSQL ne prend pas en charge le package `utl_file` qui fait partie de l'extension orafce. La raison en est que les fonctions du schéma `utl_file` fournissent des opérations de lecture et d'écriture sur les fichiers de texte des systèmes d'exploitation, ce qui nécessite un accès de super-utilisateur à l'hôte sous-jacent. En tant que service géré, RDS for PostgreSQL ne fournit pas d'accès à l'hôte.
**Pour utiliser l'extension orafce**
1. Connectez-vous à l'instance de base de données avec le nom d'utilisateur principal que vous avez utilisé pour créer l'instance de base de données.
Si vous souhaitez activer orafce pour une base de données différente dans la même instance de base de données, utilisez la commande psql `/c dbname`. À l'aide de cette commande, vous passez de base de données primaire après avoir initié la connexion.
1. Activez l'extension orafce avec l'instruction `CREATE EXTENSION`.
```
CREATE EXTENSION orafce;
```
1. Transférez la propriété du schéma oracle au rôle rds\$1superuser avec la déclaration `ALTER SCHEMA`.
```
ALTER SCHEMA oracle OWNER TO rds_superuser;
```
Si vous souhaitez voir la liste des propriétaires du schéma oracle, utilisez la commande psql `\dn`.
# Utilisation de la prise en charge de la délégation des extensions Amazon RDS pour PostgreSQL
Grâce à la prise en charge de la délégation des extensions d’Amazon RDS pour PostgreSQL, vous pouvez déléguer la gestion des extensions à un utilisateur qui n’a pas besoin d’être un `rds_superuser`. Avec cette prise en charge de la délégation des extensions, un rôle appelé `rds_extension` est créé. Vous devrez l’attribuer à un utilisateur pour qu’il puisse gérer les autres extensions. Ce rôle peut créer, mettre à jour et supprimer des extensions.
Vous pouvez spécifier les extensions qui peuvent être installées sur votre instance de base de données RDS, en les répertoriant dans le paramètre `rds.allowed_extensions`. Pour en savoir plus, consultez [Utilisation des extensions PostgreSQL avec Amazon RDS pour PostgreSQL](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Extensions.html).
Vous pouvez restreindre la liste des extensions disponibles qui peuvent être gérées par l’utilisateur ayant le rôle `rds_extension` à l’aide du paramètre `rds.allowed_delegated_extensions`.
La prise en charge de la délégation des extensions est disponible dans les versions suivantes :
+ Toutes les versions supérieures
+ 16.4 et versions 16 ultérieures
+ 15.8 et versions 15 ultérieures
+ 14.13 et versions 14 ultérieures
+ 13.16 et versions 13 ultérieures
+ 12.20 et versions 12 ultérieures
**Topics**
+ [
## Activation de la prise en charge de la délégation des extensions pour un utilisateur
](#RDSPostgreSQL.delegated_ext_mgmt)
+ [
## Configuration utilisée dans la prise en charge de la délégation des extensions RDS pour PostgreSQL
](#RDSPostgreSQL.delegated_ext_config)
+ [
## Désactiver la prise en charge de la délégation des extensions
](#RDSPostgreSQL.delegated_ext_disable)
+ [
## Avantages liés à l’utilisation de la prise en charge de la délégation des extensions Amazon RDS
](#RDSPostgreSQL.delegated_ext_benefits)
+ [
## Limitation de la prise en charge de la délégation des extensions Amazon RDS pour PostgreSQL
](#RDSPostgreSQL.delegated_ext_limit)
+ [
## Autorisations requises pour certaines extensions
](#RDSPostgreSQL.delegated_ext_perm)
+ [
## Considérations de sécurité
](#RDSPostgreSQL.delegated_ext_sec)
+ [
## Désactivation de la suppression d’extension en cascade
](#RDSPostgreSQL.delegated_ext_drop)
+ [
## Exemples d’extensions pouvant être ajoutées à l’aide de la prise en charge de la délégation des extensions
](#RDSPostgreSQL.delegated_ext_support)
## Activation de la prise en charge de la délégation des extensions pour un utilisateur
Vous devez effectuer les opérations suivantes pour activer la prise en charge de la délégation des extensions pour un utilisateur :
1. **Accorder un rôle `rds_extension` à un utilisateur** : connectez-vous à la base de données en tant que `rds_superuser` et exécutez la commande suivante.
```
Postgres => grant rds_extension to user_name;
```
1. **Définir la liste des extensions que les utilisateurs délégués pourront gérer** : `rds.allowed_delegated_extensions` permet de spécifier un sous-ensemble des extensions disponibles à l’aide de `rds.allowed_extensions` dans le paramètre de cluster de bases de données. Vous pouvez effectuer cette opération à l’un des niveaux suivants :
+ Dans le groupe de paramètres du cluster ou de l’instance, via la AWS Management Console ou l’API. Pour plus d’informations, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
+ Utilisez la commande suivante au niveau de la base de données :
```
alter database database_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
+ Utilisez la commande suivante au niveau de l’utilisateur :
```
alter user user_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
**Note**
Il n’est pas nécessaire de redémarrer la base de données après avoir modifié le paramètre dynamique `rds.allowed_delegated_extensions`.
1. **Autoriser l’utilisateur délégué à accéder aux objets créés lors du processus de création des extensions** : certaines extensions créent des objets qui nécessitent l’octroi d’autorisations supplémentaires avant que l’utilisateur ayant le rôle `rds_extension` puisse y accéder. `rds_superuser` doit accorder à l’utilisateur délégué l’accès à ces objets. L’une des options consiste à utiliser un déclencheur d’événement pour accorder automatiquement l’autorisation à l’utilisateur délégué.
**Exemple de déclencheur d'événement**
Si vous souhaitez autoriser un utilisateur délégué ayant le rôle `rds_extension` à utiliser des extensions qui nécessitent de définir des autorisations sur ses objets créés lors de la création des extensions, vous pouvez personnaliser l’exemple de déclencheur d’événement ci-dessous et ajouter uniquement les extensions pour lesquelles vous souhaitez que les utilisateurs délégués aient accès à toutes les fonctionnalités. Ce déclencheur d’événement peut être créé sur template1 (modèle par défaut). Par conséquent, toutes les bases de données créées à partir de template1 auront ce déclencheur d’événement. Lorsqu’un utilisateur délégué installe l’extension, ce déclencheur octroie automatiquement la propriété des objets créés par l’extension.
```
CREATE OR REPLACE FUNCTION create_ext()
RETURNS event_trigger AS $$
DECLARE
schemaname TEXT;
databaseowner TEXT;
r RECORD;
BEGIN
IF tg_tag = 'CREATE EXTENSION' and current_user != 'rds_superuser' THEN
RAISE NOTICE 'SECURITY INVOKER';
RAISE NOTICE 'user: %', current_user;
FOR r IN SELECT * FROM pg_catalog.pg_event_trigger_ddl_commands()
LOOP
CONTINUE WHEN r.command_tag != 'CREATE EXTENSION' OR r.object_type != 'extension';
schemaname = (
SELECT n.nspname
FROM pg_catalog.pg_extension AS e
INNER JOIN pg_catalog.pg_namespace AS n
ON e.extnamespace = n.oid
WHERE e.oid = r.objid
);
databaseowner = (
SELECT pg_catalog.pg_get_userbyid(d.datdba)
FROM pg_catalog.pg_database d
WHERE d.datname = current_database()
);
RAISE NOTICE 'Record for event trigger %, objid: %,tag: %, current_user: %, schema: %, database_owenr: %', r.object_identity, r.objid, tg_tag, current_user, schemaname, databaseowner;
IF r.object_identity = 'address_standardizer_data_us' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_gaz TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_lex TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_rules TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'dict_int' THEN
EXECUTE pg_catalog.format('ALTER TEXT SEARCH DICTIONARY %I.intdict OWNER TO %I;', schemaname, databaseowner);
ELSIF r.object_identity = 'pg_partman' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config_sub TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.custom_time_partitions TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'postgis_topology' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE ON SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
END IF;
END LOOP;
END IF;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
CREATE EVENT TRIGGER log_create_ext ON ddl_command_end EXECUTE PROCEDURE create_ext();
```
## Configuration utilisée dans la prise en charge de la délégation des extensions RDS pour PostgreSQL
| Nom de la configuration | Description | Valeur par défaut | Remarques | Qui peut modifier ou accorder l’autorisation |
| --- | --- | --- | --- | --- |
| `rds.allowed_delegated_extensions` | Ce paramètre limite les extensions qu’un rôle rds\$1extension peut gérer dans une base de données. Il doit s’agir d’un sous-ensemble de rds.allowed\$1extensions. | chaîne vide | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/RDS_delegated_ext.html) Pour en savoir plus sur la configuration de ce paramètre, consultez [Activation de la prise en charge de la délégation des extensions pour un utilisateur](#RDSPostgreSQL.delegated_ext_mgmt). | RDS\$1SUPERUSER |
| `rds.allowed_extensions` | Ce paramètre permet au client de limiter les extensions qui peuvent être installées dans l’instance de base de données RDS. Pour plus d’informations, consultez [Restriction de l’installation des extensions PostgreSQL](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction). | "\$1" | Par défaut, ce paramètre est défini sur \$1, ce qui signifie que toutes les extensions prises en charge par RDS pour PostgreSQL et Aurora PostgreSQL peuvent être créées par les utilisateurs disposant des privilèges nécessaires. Une chaîne vide signifie qu’aucune extension ne peut être installée dans l’instance de base de données RDS. | administrateur |
| `rds-delegated_extension_allow_drop_cascade` | Ce paramètre contrôle la capacité de l’utilisateur ayant le rôle `rds_extension` à supprimer l’extension à l’aide de l’option en cascade. | off | Par défaut, la propriété `rds-delegated_extension_allow_drop_cascade` a la valeur `off`. Cela signifie que les utilisateurs ayant le rôle `rds_extension` ne sont pas autorisés à supprimer une extension à l’aide de l’option en cascade. Pour qu’ils puissent effectuer cette action, le paramètre `rds.delegated_extension_allow_drop_cascade` doit être défini sur `on`. | rds\$1superuser |
## Désactiver la prise en charge de la délégation des extensions
**Désactivation partielle**
Les utilisateurs délégués ne peuvent pas créer d’extensions, mais peuvent toujours mettre à jour les extensions existantes.
+ Réinitialisez `rds.allowed_delegated_extensions` dans le groupe de paramètres de cluster de bases de données.
+ Utilisez la commande suivante au niveau de la base de données :
```
alter database database_name reset rds.allowed_delegated_extensions;
```
+ Utilisez la commande suivante au niveau de l’utilisateur :
```
alter user user_name reset rds.allowed_delegated_extensions;
```
**Désactivation complète**
La révocation du rôle `rds_extension` d’un utilisateur rétablit ses autorisations standard. L’utilisateur ne pourra plus créer, mettre à jour ni supprimer des extensions.
```
postgres => revoke rds_extension from user_name;
```
## Avantages liés à l’utilisation de la prise en charge de la délégation des extensions Amazon RDS
Grâce à la prise en charge de la délégation des extensions d’Amazon RDS pour PostgreSQL, vous déléguez en toute sécurité la gestion des extensions aux utilisateurs qui n’ont pas le rôle `rds_superuser`. Cette fonctionnalité présente les avantages suivants :
+ Vous pouvez facilement déléguer la gestion des extensions aux utilisateurs de votre choix.
+ Cela ne nécessite pas le rôle `rds_superuser`.
+ Permet de prendre en charge différents ensembles d’extensions pour différentes bases de données dans le même cluster de bases de données.
## Limitation de la prise en charge de la délégation des extensions Amazon RDS pour PostgreSQL
+ Les objets créés pendant le processus de création d’une extension peuvent nécessiter des privilèges supplémentaires pour que l’extension fonctionne correctement.
+ Certaines extensions ne peuvent pas être gérées par l’utilisateur de l’extension déléguée par défaut, notamment les suivantes : `log_fdw`, `pg_cron`, `pg_tle`, `pgactive`, `pglogical`, `postgis_raster`, `postgis_tiger_geocoder`, `postgis_topology`.
## Autorisations requises pour certaines extensions
Pour créer, utiliser ou mettre à jour les extensions suivantes, l’utilisateur délégué doit disposer des privilèges nécessaires sur les fonctions, tables et schémas suivants.
| Extensions nécessitant des droits de propriété ou des autorisations | Fonction | Tables | Schema | Dictionnaire de recherche de texte | Comment |
| --- | --- | --- | --- | --- | --- |
| address\$1standardizer\$1data\$1us | Aucune | us\$1gaz, us\$1lex, us\$1lex, I.us\$1rules | Aucune | none | none |
| amcheck | bt\$1index\$1check, bt\$1index\$1parent\$1check | Aucune | none | none | none |
| dict\$1int | Aucune | none | none | intdict | Aucune |
| pg\$1partman | Aucune | custom\$1time\$1partitions, part\$1config, part\$1config\$1sub | Aucune | none | none |
| pg\$1stat\$1statements | Aucune | none | none | none | none |
| PostGIS | st\$1tileenvelope | spatial\$1ref\$1sys | Aucune | none | none |
| postgis\$1raster | Aucune | none | none | none | none |
| postgis\$1topology | Aucune | topologie, couche | topologie | Aucune | l’utilisateur délégué doit être le propriétaire de la base de données |
| log\$1fdw | create\$1foreign\$1table\$1for\$1log\$1file | Aucune | none | none | none |
| rds\$1tools | role\$1password\$1encryption\$1type | Aucune | none | none | none |
| postgis\$1tiger\$1geocoder | Aucune | geocode\$1settings\$1default, geocode\$1settings | tiger | Aucune | none |
| pg\$1freespacemap | pg\$1freespace | Aucune | none | none | none |
| pg\$1visibility | pg\$1visibility | Aucune | none | none | none |
## Considérations de sécurité
N’oubliez pas qu’un utilisateur doté d’un rôle `rds_extension` peut gérer les extensions sur toutes les bases de données sur lesquelles il dispose du privilège de connexion. Si l’intention est de permettre à l’utilisateur délégué de ne gérer une extension que sur une seule base de données, il est recommandé de révoquer tous les privilèges publics sur chaque base de données, puis d’accorder explicitement le privilège de connexion pour cette base de données spécifique à l’utilisateur délégué.
Plusieurs extensions peuvent permettre à un utilisateur d’accéder aux informations de plusieurs bases de données. Assurez-vous que les utilisateurs auxquels vous accordez `rds_extension` disposent de fonctionnalités entre les bases de données avant d’ajouter ces extensions à `rds.allowed_delegated_extensions`. Par exemple, `postgres_fdw` et `dblink` fournissent des fonctionnalités permettant d’interroger les bases de données sur la même instance ou sur des instances distantes. `log_fdw` lit les fichiers journaux du moteur Postgres, qui concernent toutes les bases de données de l’instance et peuvent contenir des requêtes lentes ou des messages d’erreur provenant de plusieurs bases de données. `pg_cron` permet d’exécuter des tâches d’arrière-plan planifiées sur l’instance de base de données et peut configurer des tâches pour qu’elles s’exécutent dans une autre base de données.
## Désactivation de la suppression d’extension en cascade
La possibilité de supprimer l’extension avec l’option en cascade par un utilisateur ayant le rôle `rds_extension` est contrôlée par le paramètre `rds.delegated_extension_allow_drop_cascade`. Par défaut, la propriété `rds-delegated_extension_allow_drop_cascade` a la valeur `off`. Cela signifie que les utilisateurs dotés du rôle `rds_extension` ne sont pas autorisés à supprimer une extension à l’aide de l’option en cascade, comme indiqué dans la requête ci-dessous.
```
DROP EXTENSION CASCADE;
```
Car cela supprime automatiquement les objets qui dépendent de l’extension, puis tous les objets qui dépendent de ces objets. Toute tentative d’utilisation de l’option en cascade entraînera une erreur.
Pour qu’ils puissent effectuer cette action, le paramètre `rds.delegated_extension_allow_drop_cascade` doit être défini sur `on`.
La modification du paramètre dynamique `rds.delegated_extension_allow_drop_cascade` ne nécessite pas de redémarrage de la base de données. Vous pouvez procéder à l’un des niveaux suivants :
+ Dans le cluster ou le groupe de paramètres d'instance, via l'API AWS Management Console or.
+ À l’aide de la commande suivante au niveau de la base de données :
```
alter database database_name set rds.delegated_extension_allow_drop_cascade = 'on';
```
+ À l’aide de la commande suivante au niveau de l’utilisateur :
```
alter role tenant_user set rds.delegated_extension_allow_drop_cascade = 'on';
```
## Exemples d’extensions pouvant être ajoutées à l’aide de la prise en charge de la délégation des extensions
+ `rds_tools`
```
extension_test_db=> create extension rds_tools;
CREATE EXTENSION
extension_test_db=> SELECT * from rds_tools.role_password_encryption_type() where rolname = 'pg_read_server_files';
ERROR: permission denied for function role_password_encryption_type
```
+ `amcheck`
```
extension_test_db=> CREATE TABLE amcheck_test (id int);
CREATE TABLE
extension_test_db=> INSERT INTO amcheck_test VALUES (generate_series(1,100000));
INSERT 0 100000
extension_test_db=> CREATE INDEX amcheck_test_btree_idx ON amcheck_test USING btree (id);
CREATE INDEX
extension_test_db=> create extension amcheck;
CREATE EXTENSION
extension_test_db=> SELECT bt_index_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_check
extension_test_db=> SELECT bt_index_parent_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_parent_check
```
+ `pg_freespacemap`
```
extension_test_db=> create extension pg_freespacemap;
CREATE EXTENSION
extension_test_db=> SELECT * FROM pg_freespace('pg_authid');
ERROR: permission denied for function pg_freespace
extension_test_db=> SELECT * FROM pg_freespace('pg_authid',0);
ERROR: permission denied for function pg_freespace
```
+ `pg_visibility`
```
extension_test_db=> create extension pg_visibility;
CREATE EXTENSION
extension_test_db=> select * from pg_visibility('pg_database'::regclass);
ERROR: permission denied for function pg_visibility
```
+ `postgres_fdw`
```
extension_test_db=> create extension postgres_fdw;
CREATE EXTENSION
extension_test_db=> create server myserver foreign data wrapper postgres_fdw options (host 'foo', dbname 'foodb', port '5432');
ERROR: permission denied for foreign-data wrapper postgres_fdw
```
# Gestion des partitions PostgreSQL avec l’extension pg\$1partman
Le partitionnement de table PostgreSQL fournit un cadre à des fins de traitement hautes performances des entrées de données et des rapports. Utilisez le partitionnement pour les bases de données nécessitant une saisie très rapide de grandes quantités de données. Le partitionnement permet également d’interroger plus rapidement les tables volumineuses. Le partitionnement permet de maintenir les données sans affecter l’instance de base de données, car il nécessite moins de ressources d’I/O.
Le partitionnement vous permet de diviser les données en morceaux de taille personnalisée à des fins de traitement. Par exemple, vous pouvez choisir de partitionner des données chronologiques pour des plages telles que les plages horaires, quotidiennes, hebdomadaires, mensuelles, trimestrielles, annuelles, personnalisées ou toute autre combinaison de celles-ci. Pour un exemple de données chronologiques, si vous partitionnez la table par heure, chaque partition contiendra une heure de données. Si vous partitionnez la table chronologique par jour, chaque partition contiendra un jour de données, etc. La clé de partition contrôle la taille d’une partition.
Lorsque vous utilisez une commande SQL `INSERT` ou `UPDATE` sur une table partitionnée, le moteur de base de données achemine les données vers la partition qui convient. Les partitions de table PostgreSQL qui stockent les données sont des tables enfants de la table principale.
Lors de la lecture d’une requête de base de données, l’optimiseur PostgreSQL examine la clause `WHERE` de la requête et, si possible, dirige l’analyse de base de données vers les seules partitions pertinentes.
À partir de la version 10, PostgreSQL utilise le partitionnement déclaratif pour implémenter le partitionnement de table. Cette technique est également connue sous le nom de partitionnement PostgreSQL natif. Avant PostgreSQL version 10, il fallait utiliser des déclencheurs pour implémenter des partitions.
Le partitionnement de table PostgreSQL offre les fonctionnalités suivantes :
+ Création de nouvelles partitions à tout moment.
+ Plages de partitions variables.
+ Partitions détachables et ré-attachables à l’aide d’instructions DDL (data definition language).
Par exemple, les partitions détachables sont utiles pour supprimer les données historiques de la partition principale, tout en les conservant à des fins d’analyse.
+ Les nouvelles partitions héritent des propriétés de la table de base de données parent, et notamment :
+ Index
+ Clés primaires devant inclure la colonne de clé de partition
+ Clés étrangères
+ Contraintes de validation
+ Références
+ Création d’index pour la table complète ou chaque partition spécifique.
Vous ne pouvez pas modifier le schéma d’une partition individuelle. Vous pouvez cependant modifier la table parent (par exemple, ajouter une nouvelle colonne), qui se propage aux partitions.
**Topics**
+ [
## Présentation de l’extension PostgreSQL pg\$1partman
](#PostgreSQL_Partitions.pg_partman)
+ [
## Activation de l’extension pg\$1partman
](#PostgreSQL_Partitions.enable)
+ [
## Configuration des partitions à l’aide de la fonction create\$1parent
](#PostgreSQL_Partitions.create_parent)
+ [
## Configuration de la maintenance des partitions à l’aide de la fonction run\$1maintenance\$1proc
](#PostgreSQL_Partitions.run_maintenance_proc)
## Présentation de l’extension PostgreSQL pg\$1partman
Vous pouvez utiliser l’extension `pg_partman` PostgreSQL pour automatiser la création et la maintenance des partitions de table. Pour plus d’informations générales, consultez [PG Partition Manager](https://github.com/pgpartman/pg_partman) dans la documentation `pg_partman`.
**Note**
L’extension `pg_partman` est prise en charge sur RDS PostgreSQL versions 12.5 et ultérieures.
Plutôt que de créer manuellement chaque partition, vous configurez `pg_partman` avec les paramètres suivants :
+ Table à partitionner
+ Type de partition
+ Clé de partition
+ Granularité de partition
+ Options de pré-création et de gestion des partitions
Après avoir créé une table partitionnée PostgreSQL, vous l’enregistrez auprès de `pg_partman` en appelant la fonction `create_parent`. Cela crée les partitions nécessaires en fonction des paramètres passés dans la fonction.
L’extension `pg_partman` propose également la fonction `run_maintenance_proc` que vous pouvez appeler sur une base planifiée pour gérer automatiquement les partitions. Programmez cette fonction de manière à ce qu’elle s’exécute périodiquement (par exemple, toutes les heures) pour vous assurer que les partitions appropriées sont créées, si besoin. Vous pouvez également vous assurer que les partitions sont automatiquement supprimées.
## Activation de l’extension pg\$1partman
En présence de plusieurs bases de données au sein de la même instance de base de données pour laquelle vous souhaitez gérer les partitions, activez l’extension `pg_partman` séparément pour chaque base de données. Pour activer l’extension `pg_partman` pour une base de données spécifique, créez le schéma de maintenance de partition, puis créez l’extension `pg_partman` comme suit.
```
CREATE SCHEMA partman;
CREATE EXTENSION pg_partman WITH SCHEMA partman;
```
**Note**
Pour créer l’extension `pg_partman`, assurez-vous que vous disposez des privilèges `rds_superuser`.
Si vous recevez une erreur similaire à la suivante, accordez les privilèges `rds_superuser` au compte ou utilisez votre compte de super-utilisateur.
```
ERROR: permission denied to create extension "pg_partman"
HINT: Must be superuser to create this extension.
```
Pour accorder des privilèges `rds_superuser`, connectez-vous avec votre compte de super-utilisateur et exécutez la commande suivante :
```
GRANT rds_superuser TO user-or-role;
```
Pour les exemples illustrant l’utilisation de l’extension pg\$1partman, nous utilisons l’exemple de table et de partition de base de données ci-dessous. Cette base de données utilise une table partitionnée basée sur un horodatage. Un schéma `data_mart` contient une table nommée `events` avec une colonne nommée `created_at`. Les paramètres suivants sont inclus dans la table `events` :
+ Clés primaires `event_id` et `created_at`, qui doivent utiliser la colonne pour guider la partition.
+ Contrainte de vérification `ck_valid_operation` pour appliquer des valeurs pour une colonne de table `operation`.
+ Deux clés étrangères, l’une (`fk_orga_membership)`) pointant vers la table externe `organization` et l’autre (`fk_parent_event_id`) correspondant à un clé étrangère auto-référencée.
+ Deux index, l’un (`idx_org_id`) correspondant à la clé étrangère et l’autre (`idx_event_type`) au type d’événement.
Les instructions DDL suivantes créent ces objets, qui sont automatiquement inclus dans chaque partition.
```
CREATE SCHEMA data_mart;
CREATE TABLE data_mart.organization ( org_id BIGSERIAL,
org_name TEXT,
CONSTRAINT pk_organization PRIMARY KEY (org_id)
);
CREATE TABLE data_mart.events(
event_id BIGSERIAL,
operation CHAR(1),
value FLOAT(24),
parent_event_id BIGINT,
event_type VARCHAR(25),
org_id BIGSERIAL,
created_at timestamp,
CONSTRAINT pk_data_mart_event PRIMARY KEY (event_id, created_at),
CONSTRAINT ck_valid_operation CHECK (operation = 'C' OR operation = 'D'),
CONSTRAINT fk_orga_membership
FOREIGN KEY(org_id)
REFERENCES data_mart.organization (org_id),
CONSTRAINT fk_parent_event_id
FOREIGN KEY(parent_event_id, created_at)
REFERENCES data_mart.events (event_id,created_at)
) PARTITION BY RANGE (created_at);
CREATE INDEX idx_org_id ON data_mart.events(org_id);
CREATE INDEX idx_event_type ON data_mart.events(event_type);
```
## Configuration des partitions à l’aide de la fonction create\$1parent
Après avoir activé l’extension `pg_partman`, utilisez la fonction `create_parent` pour configurer les partitions dans le schéma de maintenance des partitions. L’exemple suivant utilise l’exemple de table `events` créé dans [Activation de l’extension pg\$1partmanConfiguration de la maintenance des partitions à l’aide de la fonction run\$1maintenance\$1proc](#PostgreSQL_Partitions.enable). Appelez la fonction `create_parent` comme suit.
```
SELECT partman.create_parent(
p_parent_table => 'data_mart.events',
p_control => 'created_at',
p_type => 'range',
p_interval => '1 day',
p_premake => 30);
```
Les paramètres sont les suivants :
+ `p_parent_table` – Table parent partitionnée. Cette table doit être présente et pleinement qualifiée, y compris le schéma.
+ `p_control` – Colonne sur laquelle le partitionnement doit être basé. Le type de données doit être un entier ou une valeur basée sur le temps.
+ `p_type` – Le type est `'range'` ou `'list'`.
+ `p_interval` : intervalle de temps ou plage d’entiers pour chaque partition. Par exemple : `1 day`, `1 hour` et d’autres valeurs similaires.
+ `p_premake` : nombre de partitions à créer à l’avance pour prendre en charge les nouvelles insertions.
Pour une description complète de la fonction `create_parent`, consultez [Fonctions de création](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#user-content-creation-functions) dans la documentation `pg_partman`.
## Configuration de la maintenance des partitions à l’aide de la fonction run\$1maintenance\$1proc
Vous pouvez exécuter des opérations de maintenance des partitions pour créer automatiquement de nouvelles partitions, détacher des partitions ou supprimer d’anciennes partitions. La maintenance des partitions repose sur la fonction `run_maintenance_proc` de l’extension `pg_partman`, et l’extension `pg_cron`, qui lance un planificateur interne. Le planificateur `pg_cron` exécute automatiquement les instructions SQL, fonctions et procédures définies dans vos bases de données.
L’exemple suivant utilise l’exemple de table `events` créé dans [Activation de l’extension pg\$1partmanConfiguration de la maintenance des partitions à l’aide de la fonction run\$1maintenance\$1proc](#PostgreSQL_Partitions.enable) pour définir l’exécution automatique des opérations de maintenance des partitions. Au préalable, ajoutez `pg_cron` au paramètre `shared_preload_libraries` dans le groupe de paramètres de l’instance de base de données.
```
CREATE EXTENSION pg_cron;
UPDATE partman.part_config
SET infinite_time_partitions = true,
retention = '3 months',
retention_keep_table=true
WHERE parent_table = 'data_mart.events';
SELECT cron.schedule('@hourly', $$CALL partman.run_maintenance_proc()$$);
```
Vous trouverez ci-dessous une step-by-step explication de l'exemple précédent :
1. Modifiez le groupe de paramètres associé à votre instance de base de données et ajoutez `pg_cron` à la valeur du paramètre `shared_preload_libraries`. Pour prendre effet, cette modification implique un redémarrage de l’instance de base de données. Pour plus d’informations, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Exécutez la commande `CREATE EXTENSION pg_cron;` à l’aide d’un compte disposant des autorisations `rds_superuser`. Cela permet d’activer l’extension `pg_cron`. Pour plus d’informations, consultez [Planification de la maintenance avec l’extension PostgreSQL pg\$1cron](PostgreSQL_pg_cron.md).
1. Exécutez la commande `UPDATE partman.part_config` pour ajuster les paramètres `pg_partman` de la table `data_mart.events`.
1. Exécutez la commande `SET` . . . pour configurer la table `data_mart.events` avec les clauses suivantes :
1. `infinite_time_partitions = true,` – Configure la table pour créer automatiquement de nouvelles partitions sans aucune limite.
1. `retention = '3 months',` – Configure la table pour présenter une rétention maximale de trois mois.
1. `retention_keep_table=true ` : configure la table de telle sorte qu’au terme de la période de rétention, la table ne soit pas supprimée automatiquement. Les partitions antérieures à la période de rétention sont uniquement détachées de la table parent.
1. Exécutez la commande `SELECT cron.schedule` . . . pour faire un appel de fonction `pg_cron`. Cet appel définit la fréquence à laquelle le planificateur exécute la procédure de maintenance `pg_partman`, `partman.run_maintenance_proc`. Pour cet exemple, la procédure s’exécute toutes les heures.
Pour une description complète de la fonction `run_maintenance_proc`, consultez [Fonctions de maintenance](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#maintenance-functions) dans la documentation `pg_partman`.
# Utilisation de pgAudit pour journaliser l'activité de la base de données
Les institutions financières, les agences gouvernementales et de nombreux secteurs doivent tenir des *journaux d'audit* pour se conformer aux exigences réglementaires. En utilisant l'extension d'audit PostgreSQL (pgAudit) avec votre instance de base de données RDS for PostgreSQL, vous pouvez capturer les enregistrements détaillés généralement utiles aux auditeurs ou pour répondre aux exigences réglementaires. Par exemple, vous pouvez configurer l'extension pgAudit pour suivre les modifications apportées à des bases de données et à des tables spécifiques, pour enregistrer l'utilisateur qui a effectué la modification et de nombreux autres détails.
L'extension pgAudit s'appuie sur les fonctionnalités de l'infrastructure de journalisation PostgreSQL native en étendant les messages de journal de manière plus détaillée. En d'autres termes, vous utilisez la même approche pour consulter votre journal d'audit que pour consulter les messages du journal. Pour plus d'informations sur la journalisation PostgreSQL, consultez [Fichiers journaux de base de données RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md).
L'extension pgAudit supprime les données sensibles, telles que les mots de passe en texte clair, des journaux. Si votre instance de base de données RDS for PostgreSQL est configuré(e) pour enregistrer les instructions du langage de manipulation de données (DML) comme indiqué dans [Activation de la journalisation des requêtes pour votre RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md), vous pouvez éviter le problème de mot de passe en texte clair en utilisant l'extension PostgreSQL Audit.
Vous pouvez configurer l'audit sur vos instances de base de données avec une grande précision. Vous pouvez auditer toutes les bases de données et tous les utilisateurs. Vous pouvez également choisir de n'auditer que certaines bases de données, certains utilisateurs et d'autres objets. Vous pouvez également exclure explicitement certains utilisateurs et certaines bases de données de l'audit. Pour de plus amples informations, consultez [Exclusion d'utilisateurs ou de bases de données de la journalisation d'audit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md).
Compte tenu de la quantité de détails qui peuvent être capturés, nous vous recommandons, si vous utilisez pgAudit, de surveiller votre consommation de stockage.
L'extension pgAudit est prise en charge sur toutes les Versions RDS for PostgreSQL. Pour la liste des versions de pgAudit prises en charge par les versions RDS for PostgreSQL disponibles, consultez [Versions d'extension pour Amazon RDS for PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) dans les *Notes de mise à jour de Amazon RDS for PostgreSQL.*
**Topics**
+ [
# Configuration de l’extension pgAudit
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)
+ [
# Audit d'objets de base de données
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.auditing.md)
+ [
# Exclusion d'utilisateurs ou de bases de données de la journalisation d'audit
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md)
+ [
# Référence pour l'extension pgAudit
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md)
# Configuration de l’extension pgAudit
Pour configurer l’extension pgAudit sur votre instance de base de données RDS pour PostgreSQL , vous devez d’abord ajouter pgAudit aux bibliothèques partagées sur le groupe de paramètres de base de données personnalisé pour votre instance de base de données RDS pour PostgreSQL. Pour plus d'informations sur la création d'un groupe de paramètres de cluster de bases de données, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md). Ensuite, vous installez l'extension pgAudit. Enfin, vous spécifiez les bases de données et les objets que vous souhaitez auditer. Les procédures de cette section vous guident. Pour ce faire, vous pouvez utiliser la AWS Management Console ou la AWS CLI.
Vous devez disposer d’autorisations en tant que rôle `rds_superuser` pour effectuer toutes ces tâches.
Les étapes suivantes supposent que votre instance de base de données RDS pour PostgreSQL est associé(e) à un groupe de paramètres de bases de données personnalisé.
## Console
**Configurer l'extension pgAudit**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez l’instance de base de données RDS pour PostgreSQL.
1. Ouvrez l’onglet **Configuration** de Instance de base de données RDS pour PostgreSQL. Parmi les détails de l’instance, trouvez le lien **Groupe de paramètres**.
1. Cliquez sur le lien pour ouvrir les paramètres personnalisés associés à votre Instance de base de données RDS pour PostgreSQL.
1. Dans le champ de recherche **Parameters** (Paramètres), tapez `shared_pre` pour trouver le paramètre `shared_preload_libraries`.
1. Choisissez **Edit parameters** (Modifier les paramètres) pour accéder aux valeurs des propriétés.
1. Ajoutez `pgaudit` à la liste dans le champ **Values** (Valeurs). Utilisez une virgule pour séparer les éléments de la liste de valeurs.
![\[Image du paramètre shared_preload_libaries avec pgAudit ajouté.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pgaudit.png)
1. Redémarrez l’instance de base de données RDS pour PostgreSQL afin que vos modifications du paramètre `shared_preload_libraries` prennent effet.
1. Lorsque l'instance est disponible, vérifiez que pgAudit a été initialisé. Utilisez `psql` pour vous connecter à l’instance de base de données RDS pour PostgreSQL, puis exécutez la commande suivante.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
1. Une fois pgAudit initialisé, vous pouvez maintenant créer l’extension. Vous devez créer l'extension après avoir initialisé la bibliothèque, car l'extension `pgaudit` installe des déclencheurs d'événements pour auditer les instructions du langage de définition des données (DDL).
```
CREATE EXTENSION pgaudit;
```
1. Fermez la session `psql`.
```
labdb=> \q
```
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Trouvez le paramètre `pgaudit.log` dans la liste et définissez la valeur appropriée pour votre cas d'utilisation. Par exemple, la définition du paramètre `pgaudit.log` en `write` comme indiqué dans l'image suivante permet de capturer des insertions, des mises à jour, des suppressions et d'autres types de modifications dans le journal.
![\[Image du paramètre pgaudit.log avec la définition.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rpg_set_pgaudit-log-level.png)
Vous pouvez également choisir l’une des valeurs suivantes pour le paramètre `pgaudit.log`.
+ none – La valeur par défaut. Aucune modification de base de données n’est journalisée.
+ all – Journalise tout (lecture, écriture, fonction, rôle, ddl, divers).
+ ddl – Journalise toutes les instructions en langage de définition de données (DDL) qui ne sont pas incluses dans la classe `ROLE`.
+ function – Journalise les appels de fonction et les blocs `DO`.
+ misc – Journalise diverses commandes, telles que `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` et `SET`.
+ read – Journalise `SELECT` et `COPY` lorsque la source est une relation (comme une table) ou une requête.
+ role – Journalise les instructions relatives aux rôles et privilèges, telles que `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` et `DROP ROLE`.
+ write – Journalise `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` et `COPY` lorsque la destination est une relation (table).
1. Sélectionnez **Enregistrer les modifications**.
1. Ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Choisissez l’instance de base de données RDS pour PostgreSQL dans la liste des bases de données.
## AWS CLI
**Configurer pgAudit**
Pour configurer pgAudit à l'aide de l'AWS CLI, vous devez appeler l'opération [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) afin de modifier les paramètres du journal d'audit dans votre groupe de paramètres personnalisé, comme indiqué dans la procédure suivante.
1. Utilisez la commande AWS CLI suivante pour ajouter `pgaudit` au paramètre `shared_preload_libraries`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilisez la commande AWS CLI suivante pour redémarrer l’instance de base de données RDS pour PostgreSQL afin que la bibliothèque pgAudit soit initialisée.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Lorsque l’instance est disponible, vous pouvez vérifier que `pgaudit` a été initialisé. Utilisez `psql` pour vous connecter à l’instance de base de données RDS pour PostgreSQL, puis exécutez la commande suivante.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
Une fois pgAudit initialisé, vous pouvez maintenant créer l’extension.
```
CREATE EXTENSION pgaudit;
```
1. Fermez la session `psql` afin de pouvoir utiliser l’AWS CLI.
```
labdb=> \q
```
1. Utilisez la commande AWS CLI suivante pour spécifier les classes d'instructions qui doivent être journalisées par journalisation des audits de session. L'exemple définit le paramètre `pgaudit.log` sur `write`, qui capture les insertions, les mises à jour et les suppressions dans le journal.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.log,ParameterValue=write,ApplyMethod=pending-reboot" \
--region aws-region
```
Vous pouvez également choisir l’une des valeurs suivantes pour le paramètre `pgaudit.log`.
+ none – La valeur par défaut. Aucune modification de base de données n’est journalisée.
+ all – Journalise tout (lecture, écriture, fonction, rôle, ddl, divers).
+ ddl – Journalise toutes les instructions en langage de définition de données (DDL) qui ne sont pas incluses dans la classe `ROLE`.
+ function – Journalise les appels de fonction et les blocs `DO`.
+ misc – Journalise diverses commandes, telles que `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` et `SET`.
+ read – Journalise `SELECT` et `COPY` lorsque la source est une relation (comme une table) ou une requête.
+ role – Journalise les instructions relatives aux rôles et privilèges, telles que `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` et `DROP ROLE`.
+ write – Journalise `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` et `COPY` lorsque la destination est une relation (table).
Redémarrez l’instance de base de données RDS pour PostgreSQL, à l’aide de la commande AWS CLI suivante.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# Audit d'objets de base de données
Une fois que pgAudit est défini sur votre instance de base de données RDS for PostgreSQL et qu'il est configuré en fonction de vos besoins, des informations plus détaillées sont capturées dans le journal PostgreSQL. Par exemple, alors que la configuration de journalisation PostgreSQL par défaut identifie la date et l'heure auxquelles une modification a été apportée à une table de base de données, avec l'extension pgAudit, l'entrée du journal peut inclure le schéma, l'utilisateur qui a effectué la modification et d'autres détails en fonction de la manière dont les paramètres de l'extension sont configurés. Vous pouvez configurer l'audit pour suivre les modifications de différentes manières.
+ Pour chaque session, par utilisateur. Au niveau de la session, vous pouvez capturer le texte de commande complet.
+ Pour chaque objet, par utilisateur et par base de données.
La fonctionnalité d'audit des objets est activée lorsque vous créez le rôle `rds_pgaudit` sur votre système, puis que vous ajoutez ce rôle au paramètre `pgaudit.role` dans votre groupe de paramètres personnalisé. Par défaut, le paramètre `pgaudit.role` n'est pas défini et la seule valeur autorisée est `rds_pgaudit`. Les étapes suivantes supposent que `pgaudit` a été initialisé et que vous avez créé l'extension `pgaudit` en suivant la procédure décrite dans [Configuration de l’extension pgAudit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md).
![\[Image du fichier journal PostgreSQL après la configuration de pgAudit.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/pgaudit-log-example.png)
Comme le montre cet exemple, la ligne « LOG: AUDIT: SESSION » fournit des informations sur la table et son schéma, entre autres détails.
**Configurer l'audit d'objets**
1. Utilisez `psql` pour vous connecter à l'instance de base de données RDS for PostgreSQL..
```
psql --host=your-instance-name.aws-region.rds.amazonaws.com --port=5432 --username=postgrespostgres --password --dbname=labdb
```
1. Créez un rôle de base de données appelé `rds_pgaudit` à l'aide de la commande suivante.
```
labdb=> CREATE ROLE rds_pgaudit;
CREATE ROLE
labdb=>
```
1. Fermez la session `psql`.
```
labdb=> \q
```
Dans les étapes suivantes, utilisez l'AWS CLI pour modifier les paramètres du journal d'audit dans votre groupe de paramètres personnalisé.
1. Utilisez la commande AWS CLI suivante pour définir le paramètre `pgaudit.role` à `rds_pgaudit`. Par défaut, ce paramètre est vide et `rds_pgaudit` est la seule valeur autorisée.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.role,ParameterValue=rds_pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilisez la commande AWS CLI suivante pour redémarrer l'instance de base de données RDS for PostgreSQL afin que les modifications apportées aux paramètres prennent effet.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Exécutez la commande suivante pour confirmer que `pgaudit.role` est défini sur `rds_pgaudit`.
```
SHOW pgaudit.role;
pgaudit.role
------------------
rds_pgaudit
```
Pour tester la journalisation pgAudit, vous pouvez exécuter plusieurs exemples de commandes que vous souhaitez auditer. Par exemple, vous pouvez exécuter les commandes suivantes.
```
CREATE TABLE t1 (id int);
GRANT SELECT ON t1 TO rds_pgaudit;
SELECT * FROM t1;
id
----
(0 rows)
```
Les journaux de base de données doivent contenir une entrée similaire à ce qui suit.
```
...
2017-06-12 19:09:49 UTC:...:rds_test@postgres:[11701]:LOG: AUDIT:
OBJECT,1,1,READ,SELECT,TABLE,public.t1,select * from t1;
...
```
Pour obtenir des informations sur l'affichage des journaux, veuillez consulter [Surveillance des fichiers journaux Amazon RDS](USER_LogAccess.md).
Pour en savoir plus sur l'extension pgAudit, veuillez consulter [pgAudit](https://github.com/pgaudit/pgaudit/blob/master/README.md) sur GitHub.
# Exclusion d'utilisateurs ou de bases de données de la journalisation d'audit
Comme indiqué dans [Fichiers journaux de base de données RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md), les journaux PostgreSQL consomment de l'espace de stockage. L'utilisation de l'extension pgAudit augmente le volume de données collectées dans vos journaux à des degrés divers, en fonction des modifications que vous suivez. Vous n'avez peut-être pas besoin d'auditer chaque utilisateur ou base de données de votre Instance de base de données RDS for PostgreSQL.
Pour minimiser les impacts sur votre stockage et éviter de capturer inutilement des enregistrements d'audit, vous pouvez exclure les utilisateurs et les bases de données de l'audit. Vous pouvez également modifier la journalisation au cours d'une session donnée. Les exemples suivants montrent comment procéder.
**Note**
Les paramètres au niveau de la session ont priorité sur les paramètres du groupe de paramètres de la base de données personnalisé pour l'instance de base de données RDS for PostgreSQL. Si vous ne souhaitez pas que les utilisateurs de base de données contournent vos paramètres de configuration de journalisation des audits, veillez à modifier leurs autorisations.
Supposons que votre instance de base de données RDS for PostgreSQL soit configuré(e) pour auditer le même niveau d'activité pour tous les utilisateurs et bases de données. Vous pouvez ensuite décider de ne pas auditer l'utilisateur `myuser`. Vous pouvez désactiver l'audit pour `myuser` à l'aide de la commande SQL suivante.
```
ALTER USER myuser SET pgaudit.log TO 'NONE';
```
Vous pouvez ensuite utiliser la requête suivante pour vérifier la colonne `user_specific_settings` pour `pgaudit.log` afin de confirmer que le paramètre est défini sur `NONE`.
```
SELECT
usename AS user_name,
useconfig AS user_specific_settings
FROM
pg_user
WHERE
usename = 'myuser';
```
Vous devez voir la sortie suivante.
```
user_name | user_specific_settings
-----------+------------------------
myuser | {pgaudit.log=NONE}
(1 row)
```
Vous pouvez désactiver la journalisation pour un utilisateur donné au cours de sa session avec la base de données à l'aide de la commande suivante.
```
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'none';
```
Utilisez la requête suivante pour vérifier la colonne des paramètres du fichier pgaudit.log pour une combinaison utilisateur et base de données spécifique.
```
SELECT
usename AS "user_name",
datname AS "database_name",
pg_catalog.array_to_string(setconfig, E'\n') AS "settings"
FROM
pg_catalog.pg_db_role_setting s
LEFT JOIN pg_catalog.pg_database d ON d.oid = setdatabase
LEFT JOIN pg_catalog.pg_user r ON r.usesysid = setrole
WHERE
usename = 'myuser'
AND datname = 'mydatabase'
ORDER BY
1,
2;
```
Vous voyez des résultats similaires à ce qui suit.
```
user_name | database_name | settings
-----------+---------------+------------------
myuser | mydatabase | pgaudit.log=none
(1 row)
```
Après avoir désactivé l'audit pour `myuser`, vous décidez de ne pas suivre les modifications apportées à `mydatabase`. Vous pouvez désactiver l'audit pour cette base de données spécifique à l'aide de la commande suivante.
```
ALTER DATABASE mydatabase SET pgaudit.log to 'NONE';
```
Utilisez ensuite la requête suivante pour vérifier la colonne database\$1specific\$1settings afin de confirmer que le fichier pgaudit.log est défini sur NONE.
```
SELECT
a.datname AS database_name,
b.setconfig AS database_specific_settings
FROM
pg_database a
FULL JOIN pg_db_role_setting b ON a.oid = b.setdatabase
WHERE
a.datname = 'mydatabase';
```
Vous devez voir la sortie suivante.
```
database_name | database_specific_settings
---------------+----------------------------
mydatabase | {pgaudit.log=NONE}
(1 row)
```
Pour rétablir les paramètres par défaut pour myuser, utilisez la commande suivante :
```
ALTER USER myuser RESET pgaudit.log;
```
Pour rétablir les paramètres par défaut pour une base de données, utilisez la commande suivante.
```
ALTER DATABASE mydatabase RESET pgaudit.log;
```
Pour rétablir les paramètres par défaut pour l'utilisateur et la base de données, utilisez la commande suivante.
```
ALTER USER myuser IN DATABASE mydatabase RESET pgaudit.log;
```
Vous pouvez également capturer des événements spécifiques dans le journal en définissant `pgaudit.log` pour l'une des autres valeurs autorisées pour le paramètre `pgaudit.log`. Pour de plus amples informations, consultez [Liste des paramètres autorisés pour le paramètre `pgaudit.log`](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings).
```
ALTER USER myuser SET pgaudit.log TO 'read';
ALTER DATABASE mydatabase SET pgaudit.log TO 'function';
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'read,function'
```
# Référence pour l'extension pgAudit
Vous pouvez spécifier le niveau de détail que vous souhaitez pour votre journal d'audit en modifiant un ou plusieurs des paramètres répertoriés dans cette section.
## Contrôle du comportement de pgAudit
Vous pouvez contrôler la journalisation d'audit en modifiant un ou plusieurs des paramètres répertoriés dans la table suivante.
| Paramètre | Description |
| --- | --- |
| `pgaudit.log` | Spécifie quelles classes d'instructions seront journalisées par la journalisation de l'audit de session. Les valeurs autorisées incluent ddl, function, misc, read, role, write, none, all. Pour de plus amples informations, veuillez consulter [Liste des paramètres autorisés pour le paramètre `pgaudit.log`](#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings). |
| `pgaudit.log_catalog` | Lorsque cette option est activée (définie sur 1), cela ajoute des instructions à la piste d'audit si toutes les relations d'une instruction se trouvent dans pg\$1catalog. |
| `pgaudit.log_level` | Spécifie le niveau de journal qui sera utilisé pour les entrées de journal. Valeurs autorisées : debug5, debug4, debug3, debug2, debug1, info, notice, warning, log |
| `pgaudit.log_parameter` | Lorsque cette option est activée (définie sur 1), les paramètres transmis avec l'instruction sont capturés dans le journal d'audit. |
| `pgaudit.log_relation` | Lorsque cette option est activée (définie sur 1), le journal d'audit de session crée une entrée de journal distincte pour chaque relation (TABLE, VIEW, etc.) référencée dans une instruction SELECT ou DML. |
| `pgaudit.log_statement_once` | Spécifie si la journalisation inclura le texte de l'instruction et les paramètres avec la première entrée de journal d'une statement/substatement combinaison ou avec chaque entrée. |
| `pgaudit.role` | Spécifie le rôle principal à utiliser pour la journalisation de l’audit des objets. La seule entrée autorisée est `rds_pgaudit`. |
## Liste des paramètres autorisés pour le paramètre `pgaudit.log`
| Value | Description |
| --- | --- |
| Aucune | Il s’agit de l’option par défaut. Aucune modification de base de données n'est journalisée. |
| tout | Journalise tout (lecture, écriture, fonction, rôle, ddl, divers). |
| ddl | Journalise toutes les instructions en langage de définition de données (DDL) qui ne sont pas incluses dans la classe `ROLE`. |
| fonction | Journalise les appels de fonction et les blocs `DO`. |
| Misc | Journalise diverses commandes, telles que `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` et `SET`. |
| lire | Journalise `SELECT` et `COPY` lorsque la source est une relation (comme une table) ou une requête. |
| rôle | Journalise les instructions relatives aux rôles et privilèges, telles que `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` et `DROP ROLE`. |
| write | Journalise `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` et `COPY` lorsque la destination est une relation (table). |
Pour journaliser plusieurs types d'événements avec l'audit de session, utilisez une liste séparée par des virgules. Pour journaliser tous les types d'événements, définissez `pgaudit.log` à la valeur `ALL`. Redémarrez l'instance de base de données pour appliquer les modifications.
Avec les audits d'objet, vous pouvez affiner la journalisation d'audit pour que celle-ci fonctionne avec des relations spécifiques. Par exemple, vous pouvez spécifier que vous souhaitez une journalisation d'audit pour les opérations `READ` sur une ou plusieurs tables.
# Planification de la maintenance avec l’extension PostgreSQL pg\$1cron
Vous pouvez utiliser l’extension `pg_cron` PostgreSQL pour planifier des commandes de maintenance dans une base de données PostgreSQL. Pour plus d’informations concernant l’extension, consultez [What is pg\$1cron?](https://github.com/citusdata/pg_cron) (Qu’est-ce que pg\$1cron ?) dans la documentation pg\$1cron.
L’extension `pg_cron` est prise en charge sur RDS pour PostgreSQL versions 12.5 et ultérieures du moteur.
Pour en savoir plus sur l’utilisation de `pg_cron`, consultez [Schedule jobs with pg\$1cron on your RDS pour PostgreSQL or your Aurora PostgreSQL-Compatible Edition databases](https://aws.amazon.com/blogs/database/schedule-jobs-with-pg_cron-on-your-amazon-rds-for-postgresql-or-amazon-aurora-for-postgresql-databases/) (Planifier des tâches avec pg\$1cron sur votre RDS pour PostgreSQL ou sur vos bases de données Aurora Édition compatible avec PostgreSQL).
**Note**
La version d’extension `pg_cron` est affichée sous forme de version à deux chiffres, par exemple 1.6, dans la vue pg\$1available\$1extensions. Bien que des versions à trois chiffres, comme 1.6.4 ou 1.6.5, puissent apparaître dans certains contextes, il est nécessaire d’indiquer la version à deux chiffres lors de la mise à niveau d’une extension.
**Topics**
+ [
## Configuration de l’extension pg\$1cron
](#PostgreSQL_pg_cron.enable)
+ [
## Octroi d’autorisations utilisateurs de la base de données pour l’utilisation de pg\$1cron
](#PostgreSQL_pg_cron.permissions)
+ [
## Planification des tâches pg\$1cron
](#PostgreSQL_pg_cron.examples)
+ [
## Référence pour l’extension pg\$1cron
](#PostgreSQL_pg_cron.reference)
## Configuration de l’extension pg\$1cron
Configurez l’extension `pg_cron` comme suit :
1. Modifiez le groupe de paramètres personnalisé employé avec votre instance de base de données PostgreSQL en ajoutant `pg_cron` à la valeur du paramètre `shared_preload_libraries`.
+ Si votre instance de base de données RDS pour PostgreSQL utilise le paramètre `rds.allowed_extensions` pour lister explicitement les extensions qui peuvent être installées, vous devez ajouter l’extension `pg_cron` à la liste. Seules certaines versions de RDS pour PostgreSQL prennent en charge le paramètre `rds.allowed_extensions`. Par défaut, toutes les extensions disponibles sont autorisées. Pour plus d’informations, consultez [Restriction de l'installation des extensions PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Redémarrez l’instance de la base de données PostgreSQL pour que les modifications du groupe de paramètres prennent effet. Pour en savoir plus sur l’utilisation des groupes de paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Après le redémarrage de l’instance de base de données PostgreSQL, exécutez la commande suivante à l’aide d’un compte disposant d’autorisations `rds_superuser`. Par exemple, si vous avez utilisé les paramètres par défaut lors de la création de votre instance de base de données RDS pour PostgreSQL, connectez-vous en tant qu’utilisateur `postgres` et créez l’extension.
```
CREATE EXTENSION pg_cron;
```
Le planificateur `pg_cron` est défini dans la base de données PostgreSQL par défaut nommée `postgres`. Les objets `pg_cron` sont créés dans cette base de données `postgres` et toutes les actions de planification s’y exécutent.
1. Vous pouvez utiliser les paramètres par défaut ou planifier des tâches à exécuter dans d’autres bases de données de votre instance de base de données PostgreSQL. Pour planifier des tâches dans d’autres bases de données de votre instance de base de données PostgreSQL, consultez l’exemple disponible dans [Planification d’une tâche cron pour une base de données autre que la base de données par défaut](#PostgreSQL_pg_cron.otherDB).
## Octroi d’autorisations utilisateurs de la base de données pour l’utilisation de pg\$1cron
L’installation de l’extension `pg_cron` requiert les privilèges `rds_superuser`. Toutefois, les autorisations d’utiliser le `pg_cron` peuvent être accordées (par un membre du groupe/rôle `rds_superuser`) à d’autres utilisateurs de la base de données, afin qu’ils puissent planifier leurs propres tâches. Nous vous recommandons de n’accorder des autorisations au schéma `cron` qu’en cas de besoin, si cela améliore les opérations dans votre environnement de production.
Pour accorder à un utilisateur de base de données des autorisations dans le schéma `cron`, exécutez la commande suivante :
```
postgres=> GRANT USAGE ON SCHEMA cron TO db-user;
```
Cela donne *db-user* l'autorisation d'accéder au `cron` schéma pour planifier des tâches cron pour les objets auxquels ils sont autorisés à accéder. Si l’utilisateur de la base de données ne dispose pas des autorisations nécessaires, la tâche échoue après avoir validé le message d’erreur dans le fichier `postgresql.log`, comme indiqué ci-dessous :
```
2020-12-08 16:41:00 UTC::@:[30647]:ERROR: permission denied for table table-name
2020-12-08 16:41:00 UTC::@:[27071]:LOG: background worker "pg_cron" (PID 30647) exited with exit code 1
```
En d’autres termes, assurez-vous que les utilisateurs de la base de données disposant d’autorisations sur le schéma `cron` ont également des autorisations sur les objets (tables, schémas, etc.) qu’ils prévoient de planifier.
Les détails de la tâche cron et sa réussite ou son échec sont également saisis dans la table `cron.job_run_details`. Pour plus d’informations, consultez [Tableaux pour planifier les tâches et capturer leur statut](#PostgreSQL_pg_cron.tables).
## Planification des tâches pg\$1cron
Les sections suivantes montrent comment vous pouvez planifier diverses tâches de gestion à l’aide de tâches `pg_cron`.
**Note**
Lorsque vous créez des tâches `pg_cron`, vérifiez que le paramètre `max_worker_processes` est supérieur au nombre de `cron.max_running_jobs`. Une tâche `pg_cron` échoue si elle manque de processus de travail en arrière-plan. Le nombre de tâches `pg_cron` par défaut est de `5`. Pour plus d’informations, consultez [Paramètres de gestion de l’extension pg\$1cron](#PostgreSQL_pg_cron.parameters).
**Topics**
+ [
### Vidage d’une table
](#PostgreSQL_pg_cron.vacuum)
+ [
### Purge de la table Historique pg\$1cron
](#PostgreSQL_pg_cron.job_run_details)
+ [
### Journalisation des erreurs dans le fichier postgresql.log uniquement
](#PostgreSQL_pg_cron.log_run)
+ [
### Planification d’une tâche cron pour une base de données autre que la base de données par défaut
](#PostgreSQL_pg_cron.otherDB)
### Vidage d’une table
Autovacuum gère la maintenance dans la plupart des cas. Toutefois, vous pouvez vider une table spécifique quand bon vous semble.
Consultez également [Utilisation de la fonction autovacuum de PostgreSQL sur Amazon RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md).
L’exemple suivant montre comment utiliser la fonction `cron.schedule` pour configurer une tâche de manière à ce qu’elle utilise `VACUUM FREEZE` sur une table spécifique tous les jours à 22:00 (GMT).
```
SELECT cron.schedule('manual vacuum', '0 22 * * *', 'VACUUM FREEZE pgbench_accounts');
schedule
----------
1
(1 row)
```
Une fois l’exemple précédent exécuté, vous pouvez vérifier l’historique dans la table `cron.job_run_details` comme suit.
```
postgres=> SELECT * FROM cron.job_run_details;
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
-------+-------+---------+----------+----------+--------------------------------+-----------+----------------+-------------------------------+-------------------------------
1 | 1 | 3395 | postgres | adminuser| vacuum freeze pgbench_accounts | succeeded | VACUUM | 2020-12-04 21:10:00.050386+00 | 2020-12-04 21:10:00.072028+00
(1 row)
```
Voici une requête de la table `cron.job_run_details` permettant d’afficher les tâches qui ont échoué.
```
postgres=> SELECT * FROM cron.job_run_details WHERE status = 'failed';
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
------+-------+---------+----------+----------+-------------------------------+--------+--------------------------------------------------+-------------------------------+------------------------------
5 | 4 | 30339 | postgres | adminuser| vacuum freeze pgbench_account | failed | ERROR: relation "pgbench_account" does not exist | 2020-12-04 21:48:00.015145+00 | 2020-12-04 21:48:00.029567+00
(1 row)
```
Pour plus d’informations, consultez [Tableaux pour planifier les tâches et capturer leur statut](#PostgreSQL_pg_cron.tables).
### Purge de la table Historique pg\$1cron
La table `cron.job_run_details` contient un historique des tâches cron et celui-ci peut considérablement s’étoffer au fil du temps. Nous vous recommandons de planifier une tâche afin de purger cette table. Par exemple, conserver les entrées d’une semaine peut s’avérer suffisant à des fins de dépannage.
L’exemple suivant utilise la fonction [cron.schedule](#PostgreSQL_pg_cron.schedule) pour planifier une tâche qui s’exécute tous les jours à minuit afin de purger la table `cron.job_run_details`. Cette tâche ne conserve que les entrées des sept derniers jours. Utilisez votre compte `rds_superuser` pour planifier la tâche comme suit :
```
SELECT cron.schedule('0 0 * * *', $$DELETE
FROM cron.job_run_details
WHERE end_time < now() - interval '7 days'$$);
```
Pour plus d’informations, consultez [Tableaux pour planifier les tâches et capturer leur statut](#PostgreSQL_pg_cron.tables).
### Journalisation des erreurs dans le fichier postgresql.log uniquement
Pour empêcher les écritures dans la table `cron.job_run_details`, modifiez le groupe de paramètres associé à l’instance de base de données PostgreSQL et désactivez le paramètre `cron.log_run`. L’extension `pg_cron` n’écrit plus dans la table et consigne uniquement des erreurs dans le fichier `postgresql.log`. Pour plus d’informations, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
Utilisez la commande suivante pour vérifier la valeur du paramètre `cron.log_run`.
```
postgres=> SHOW cron.log_run;
```
Pour plus d’informations, consultez [Paramètres de gestion de l’extension pg\$1cron](#PostgreSQL_pg_cron.parameters).
### Planification d’une tâche cron pour une base de données autre que la base de données par défaut
Toutes les métadonnées de `pg_cron` sont conservées dans la base de données par défaut PostgreSQL nommée `postgres`. Des exécutants étant utilisés en arrière-plan pour exécuter les tâches de maintenance cron, vous pouvez planifier une tâche dans n’importe quelle base de données de l’instance de base de données PostgreSQL.
**Note**
Seuls les utilisateurs disposant du rôle `rds_superuser` ou de privilèges `rds_superuser` peuvent répertorier toutes les tâches cron de la base de données. Les autres utilisateurs peuvent uniquement consulter leurs propres tâches dans la table `cron.job`.
1. Dans la base de données cron, planifiez la tâche comme vous le faites normalement à l’aide de la fonction [cron.schedule](#PostgreSQL_pg_cron.schedule).
```
postgres=> SELECT cron.schedule('database1 manual vacuum', '29 03 * * *', 'vacuum freeze test_table');
```
1. En tant qu’utilisateur ayant le rôle `rds_superuser`, mettez à jour la colonne de base de données correspondant à la tâche que vous venez de créer de manière à l’exécuter dans une autre base de données de votre instance de base de données PostgreSQL.
```
postgres=> UPDATE cron.job SET database = 'database1' WHERE jobid = 106;
```
1. Procédez à une vérification en interrogeant la table `cron.job`.
```
postgres=> SELECT * FROM cron.job;
jobid | schedule | command | nodename | nodeport | database | username | active | jobname
------+-------------+--------------------------------+-----------+----------+----------+-----------+--------+-------------------------
106 | 29 03 * * * | vacuum freeze test_table | localhost | 8192 | database1| adminuser | t | database1 manual vacuum
1 | 59 23 * * * | vacuum freeze pgbench_accounts | localhost | 8192 | postgres | adminuser | t | manual vacuum
(2 rows)
```
**Note**
Dans certains cas, vous pouvez ajouter une tâche cron que vous avez l’intention d’exécuter sur une base de données différente. Dans de tels cas, le tâche peut essayer de s’exécuter dans la base de données par défaut (`postgres`) avant la mise à jour de la colonne de base de données correcte. Si le nom d’utilisateur dispose d’autorisations, la tâche s’exécute correctement dans la base de données par défaut.
## Référence pour l’extension pg\$1cron
Vous pouvez utiliser les paramètres, fonctions et tables suivants avec l’extension `pg_cron`. Pour plus d’informations, consultez [Qu’est-ce que pg\$1cron](https://github.com/citusdata/pg_cron) dans la documentation pg\$1cron.
**Topics**
+ [
### Paramètres de gestion de l’extension pg\$1cron
](#PostgreSQL_pg_cron.parameters)
+ [
### Référence de fonction : cron.schedule
](#PostgreSQL_pg_cron.schedule)
+ [
### Référence de fonction : cron.unschedule
](#PostgreSQL_pg_cron.unschedule)
+ [
### Tableaux pour planifier les tâches et capturer leur statut
](#PostgreSQL_pg_cron.tables)
### Paramètres de gestion de l’extension pg\$1cron
La liste ci-dessous répertorie les paramètres permettant de contrôler le comportement de l’extension `pg_cron`.
| Paramètre | Description |
| --- | --- |
| cron.database\$1name | Base de données dans laquelle les métadonnées `pg_cron` sont conservées. |
| cron.host | Nom d’hôte permettant de se connecter à PostgreSQL. Vous ne pouvez pas modifier cette valeur. |
| cron.log\$1run | Enregistrez chaque tâche qui s’exécute dans la table `job_run_details`. Les valeurs sont `on` ou `off`. Pour plus d’informations, consultez [Tableaux pour planifier les tâches et capturer leur statut](#PostgreSQL_pg_cron.tables). |
| cron.log\$1statement | Enregistre toutes les instructions cron avant leur exécution. Les valeurs sont `on` ou `off`. |
| cron.max\$1running\$1jobs | Nombre maximal de tâches pouvant être exécutées simultanément. |
| cron.use\$1background\$1workers | Utilisez des exécutants en arrière-plan plutôt que des sessions client. Vous ne pouvez pas modifier cette valeur. |
Utilisez la commande SQL suivante pour afficher ces paramètres et leurs valeurs.
```
postgres=> SELECT name, setting, short_desc FROM pg_settings WHERE name LIKE 'cron.%' ORDER BY name;
```
### Référence de fonction : cron.schedule
Cette fonction planifie une tâche cron. Cette tâche est initialement planifiée dans la base de données `postgres` par défaut. La fonction renvoie une valeur `bigint` correspondant à l’identifiant de la tâche. Pour planifier l’exécution de tâches dans d’autres bases de données de votre instance de base de données PostgreSQL, consultez l’exemple disponible dans [Planification d’une tâche cron pour une base de données autre que la base de données par défaut](#PostgreSQL_pg_cron.otherDB).
La fonction présente deux formats de syntaxe.
**Syntaxe**
```
cron.schedule (job_name,
schedule,
command
);
cron.schedule (schedule,
command
);
```
**Paramètres**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**Exemples**
```
postgres=> SELECT cron.schedule ('test','0 10 * * *', 'VACUUM pgbench_history');
schedule
----------
145
(1 row)
postgres=> SELECT cron.schedule ('0 15 * * *', 'VACUUM pgbench_accounts');
schedule
----------
146
(1 row)
```
### Référence de fonction : cron.unschedule
Cette fonction supprime une tâche cron. Vous pouvez spécifier soit le `job_name` ou le `job_id`. Une politique assure que vous soyez le propriétaire pouvant supprimer la planification de la tâche. La fonction renvoie une valeur booléenne indiquant la réussite ou l’échec.
La fonction a les formats de syntaxe suivants.
**Syntaxe**
```
cron.unschedule (job_id);
cron.unschedule (job_name);
```
**Paramètres**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**Exemples**
```
postgres=> SELECT cron.unschedule(108);
unschedule
------------
t
(1 row)
postgres=> SELECT cron.unschedule('test');
unschedule
------------
t
(1 row)
```
### Tableaux pour planifier les tâches et capturer leur statut
Les tables suivantes sont utilisées pour planifier les tâches cron et enregistrer la façon dont elles ont été accomplies.
| Tableau | Description |
| --- | --- |
| cron.job | Contient les métadonnées relatives à chaque tâche planifiée. La plupart des interactions avec cette table doivent être effectuées à l’aide des fonctions `cron.schedule` et `cron.unschedule`. Nous vous recommandons de ne pas accorder de privilèges de mise à jour ou d’insertion directement à cette table. Ce faisant, l’utilisateur pourrait mettre à jour la colonne `username` à exécuter en tant que `rds-superuser`. |
| cron.job\$1run\$1details | Contient des informations historiques sur l’exécution de tâches planifiées antérieures. Ces informations sont utiles pour examiner l’état, les messages renvoyés et les heures de début et de fin d’exécution de la tâche. Pour éviter que cette table évolue indéfiniment, purgez-la de manière régulière. Pour obtenir un exemple, consultez [Purge de la table Historique pg\$1cron](#PostgreSQL_pg_cron.job_run_details). |
# Utilisation de pglogical pour synchroniser les données entre les instances
Toutes les versions RDS pour PostgreSQL actuellement disponibles prennent en charge l’extension `pglogical`. L’extension pglogical est antérieure à la fonction de réplication logique qui fonctionne de la même manière et qui a été introduite par PostgreSQL dans la version 10. Pour plus d’informations, consultez [Réplication logique pour Amazon RDS pour PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md).
L’extension `pglogical` prend en charge la réplication logique entre deux ou plusieurs instances de base de données RDS pour PostgreSQL. Elle prend également en charge la réplication entre différentes versions de PostgreSQL, ainsi qu’entre des bases de données fonctionnant sur RDS pour les instances de base de données PostgreSQL et les clusters de bases de données Aurora PostgreSQL. L’extension `pglogical` utilise un modèle de publication et d’abonnement pour répliquer les changements apportés aux tables et aux autres objets, tels que les séquences, d’un serveur de publication à un abonné. Elle s’appuie sur un emplacement de réplication pour assurer la synchronisation des changements d’un nœud de serveur de publication à un nœud abonné, défini comme suit.
+ Le *nœud de serveur de publication* est l’instance de base de données RDS pour PostgreSQL qui est la source des données à répliquer vers les autres nœuds. Le nœud de serveur de publication définit les tables à répliquer dans un ensemble de publication.
+ Le *nœud abonné* est l’instance de base de données RDS pour PostgreSQL qui reçoit les mises à jour WAL du serveur de publication. L’abonné crée un abonnement pour se connecter au serveur de publication et obtenir les données WAL décodées. Lorsque l’abonné crée l’abonnement, l’emplacement de réplication est créé sur le nœud de serveur de publication.
Vous trouverez ci-après des informations sur la configuration de l’extension `pglogical`.
**Topics**
+ [
## Exigences et limites de l’extension pglogique
](#Appendix.PostgreSQL.CommonDBATasks.pglogical.requirements-limitations)
+ [
# Configuration de l'extension pglogical
](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md)
+ [
# Configuration de la réplication logique pour l’instance de base de données RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.pglogical.setup-replication.md)
+ [
# Rétablissement de la réplication logique après une mise à niveau majeure
](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md)
+ [
# Gestion des emplacements de réplication logiques pour pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md)
+ [
# Référence des paramètres de l'extension pglogical
](Appendix.PostgreSQL.CommonDBATasks.pglogical.reference.md)
## Exigences et limites de l’extension pglogique
Toutes les versions actuellement disponibles de RDS pour PostgreSQL prennent en charge l’extension `pglogical`.
Le nœud de serveur de publication et le nœud abonné doivent tous deux être configurés pour la réplication logique.
Les tables que vous voulez répliquer d’un diffuseur de publication à un abonné doivent avoir les mêmes noms et le même schéma. Ces tables doivent également contenir les mêmes colonnes, et les colonnes doivent utiliser les mêmes types de données. Les tables des serveurs de publication et des abonnés doivent avoir les mêmes clés primaires. Nous vous recommandons d’utiliser uniquement PRIMARY KEY comme contrainte unique.
Les tables du nœud abonné peuvent avoir des contraintes plus permissives que celles du nœud de serveur de publication pour les contraintes CHECK et NOT NULL.
L’extension `pglogical` fournit des fonctionnalités telles que la réplication bidirectionnelle qui ne sont pas prises en charge par la fonctionnalité de réplication logique intégrée à PostgreSQL (versions 10 et ultérieures). Pour plus d’informations, consultez [PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/) (Réplication bidirectionnelle PostgreSQL utilisant pglogical).
# Configuration de l'extension pglogical
Pour configurer l'extension `pglogical` sur votre instance de base de données RDS for PostgreSQL, vous ajoutez `pglogical` aux bibliothèques partagées sur le groupe de paramètres de base de données personnalisé pour votre instance de base de données RDS for PostgreSQL. Vous devez également définir la valeur du paramètre `rds.logical_replication` sur `1`, pour activer le décodage logique. Enfin, vous créez l'extension dans la base de données. Vous pouvez utiliser le AWS Management Console ou AWS CLI pour ces tâches.
Vous devez disposer d'autorisations en tant que rôle `rds_superuser` pour effectuer ces tâches.
Les étapes suivantes supposent que votre instance de base de données RDS pour PostgreSQL est associé(e) à un groupe de paramètres de bases de données personnalisé. Pour plus d’informations sur la création d’un groupe de paramètres de cluster de bases de données, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
## Console
**Pour configurer l'extension pglogical**
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 l’instance de base de données RDS pour PostgreSQL.
1. Ouvrez l’onglet **Configuration** de Instance de base de données RDS pour PostgreSQL. Parmi les détails de l’instance, trouvez le lien **Groupe de paramètres**.
1. Cliquez sur le lien pour ouvrir les paramètres personnalisés associés à votre Instance de base de données RDS pour PostgreSQL.
1. Dans le champ de recherche **Parameters** (Paramètres), tapez `shared_pre` pour trouver le paramètre `shared_preload_libraries`.
1. Choisissez **Edit parameters** (Modifier les paramètres) pour accéder aux valeurs des propriétés.
1. Ajoutez `pglogical` à la liste dans le champ **Values** (Valeurs). Utilisez une virgule pour séparer les éléments de la liste de valeurs.
![\[Image du paramètre shared_preload_libraries avec pglogical ajouté.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pglogical.png)
1. Recherchez le paramètre `rds.logical_replication` et définissez-le sur `1`, pour activer la réplication logique.
1. Redémarrez l'instance de base de données RDS for PostgreSQL pour que vos modifications soient prises en compte.
1. Lorsque l'instance est disponible, vous pouvez utiliser `psql` (ou pgAdmin) pour vous connecter à l'instance de base de données RDS for PostgreSQL.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Pour vérifier que pglogical est initialisé, exécutez la commande suivante.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pglogical
(1 row)
```
1. Vérifiez le paramètre qui active le décodage logique, comme suit.
```
SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
1. Créez l'extension, comme suit.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Sélectionnez **Enregistrer les modifications**.
1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Sélectionnez votre instance de base de données RDS for PostgreSQL dans la liste des bases de données, puis choisissez **Reboot** (Redémarrer) dans le menu Actions.
## AWS CLI
**Pour configurer l'extension pglogical**
Pour configurer pglogical à l'aide de AWS CLI, vous devez appeler l'[modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html)opération pour modifier certains paramètres de votre groupe de paramètres personnalisé, comme indiqué dans la procédure suivante.
1. Utilisez la AWS CLI commande suivante pour ajouter des éléments `pglogical` au `shared_preload_libraries` paramètre.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pglogical,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilisez la AWS CLI commande suivante pour définir sur `rds.logical_replication` `1` afin d'activer la fonctionnalité de décodage logique pour l'. Instance de base de données RDS pour PostgreSQL.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilisez la AWS CLI commande suivante pour redémarrer l'instance d' RDS pour PostgreSQL afin que la bibliothèque pglogical soit initialisée.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Lorsque l'instance est disponible, utilisez `psql` pour vous connecter à l'instance de base de données RDS for PostgreSQL.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Créez l'extension, comme suit.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Redémarrez l' RDS pour PostgreSQL à l'aide de la commande suivante. AWS CLI
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# Configuration de la réplication logique pour l’instance de base de données RDS pour PostgreSQL
La procédure suivante vous montre comment démarrer la réplication logique entre deux instances de base de données RDS pour PostgreSQL. Les étapes supposent que la source (serveur de publication) et la cible (abonné) ont toutes deux l’extension `pglogical` configurée comme indiqué dans le document [Configuration de l'extension pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
**Note**
Le `node_name` du nœud d’un abonné ne peut pas commencer par `rds`.
**Pour créer le nœud de serveur de publication et définir les tables à répliquer**
Ces étapes supposent que votre instance de base de données RDS pour PostgreSQL possède une base de données qui contient une ou plusieurs tables que vous voulez répliquer vers un autre nœud. Vous devez recréer la structure de la table du serveur de publication sur l’abonné, donc d’abord, récupérer la structure de la table si nécessaire. Vous pouvez le faire en utilisant la métacommande `psql` `\d tablename` et en créant ensuite la même table sur l’instance de l’abonné. La procédure suivante crée un exemple de table sur le serveur de publication (source) à des fins de démonstration.
1. Utilisez `psql` pour vous connecter à l’instance qui possède la table que vous voulez utiliser comme source pour les abonnés.
```
psql --host=source-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
Si vous ne disposez pas d’une table existante que vous souhaitez répliquer, vous pouvez créer un exemple de table comme suit.
1. Créez un exemple de table en utilisant l’instruction SQL suivante.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Remplissez la table avec les données générées en utilisant l’instruction SQL suivante.
```
INSERT INTO docs_lab_table VALUES (generate_series(1,5000));
INSERT 0 5000
```
1. Vérifiez que les données existent dans la table à l’aide de l’instruction SQL suivante.
```
SELECT count(*) FROM docs_lab_table;
```
1. Identifiez cette instance de base de données RDS pour PostgreSQL comme le nœud de serveur de publication, comme suit.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_provider',
dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 dbname=labdb');
create_node
-------------
3410995529
(1 row)
```
1. Ajoutez la table que vous souhaitez répliquer à l’ensemble de réplication par défaut. Pour plus d’informations sur les ensembles de réplication, consultez [Replication sets](https://github.com/2ndQuadrant/pglogical/tree/REL2_x_STABLE/docs#replication-sets) (Ensembles de réplication) dans la documentation pglogical.
```
SELECT pglogical.replication_set_add_table('default', 'docs_lab_table', 'true', NULL, NULL);
replication_set_add_table
---------------------------
t
(1 row)
```
La configuration du nœud de diffuseur de publication est terminée. Vous pouvez maintenant configurer le nœud abonné pour recevoir les mises à jour du serveur de publication.
**Pour configurer le nœud abonné et créer un abonnement pour recevoir des mises à jour**
Ces étapes supposent que l’instance de base de données RDS pour PostgreSQL a été configurée avec l’extension `pglogical`. Pour plus d’informations, consultez [Configuration de l'extension pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
1. Utilisez `psql` pour vous connecter à l’instance qui doit recevoir les mises à jour du serveur de publication.
```
psql --host=target-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Sur l’instance de base de données RDS pour PostgreSQL de l’abonné, créez la même table que celle qui existe sur le serveur de publication. Pour cet exemple, la table est `docs_lab_table`. Vous pouvez créer la table comme suit.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Vérifiez que cette table est vide.
```
SELECT count(*) FROM docs_lab_table;
count
-------
0
(1 row)
```
1. Identifiez cette instance de base de données RDS pour PostgreSQL comme le nœud abonné, comme suit.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_target',
dsn := 'host=target-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=********');
create_node
-------------
2182738256
(1 row)
```
1. Créez l’abonnement.
```
SELECT pglogical.create_subscription(
subscription_name := 'docs_lab_subscription',
provider_dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=*******',
replication_sets := ARRAY['default'],
synchronize_data := true,
forward_origins := '{}' );
create_subscription
---------------------
1038357190
(1 row)
```
Lorsque vous terminez cette étape, les données de la table du serveur de publication sont créées dans la table de l’abonné. Vous pouvez le vérifier en utilisant la requête SQL suivante.
```
SELECT count(*) FROM docs_lab_table;
count
-------
5000
(1 row)
```
À partir de ce moment, les modifications apportées à la table sur le serveur de publication sont répliquées sur la table sur l’abonné.
# Rétablissement de la réplication logique après une mise à niveau majeure
Avant de pouvoir effectuer une mise à niveau majeure d'une instance de base de données RDS for PostgreSQL qui est configurée comme un nœud d'édition pour la réplication logique, vous devez supprimer tous les emplacements de réplication, même ceux qui ne sont pas actifs. Nous vous recommandons de détourner temporairement les transactions de base de données du nœud d'édition, de supprimer les emplacements de réplication, de mettre à niveau l'instance de base de données RDS for PostgreSQL, puis de rétablir et de relancer la réplication.
Les emplacements de réplication sont hébergés uniquement sur le nœud de serveur de publication. Le nœud abonné RDS for PostgreSQL dans un scénario de réplication logique n'a pas d'emplacements à supprimer, mais il ne peut pas être mis à niveau vers une version majeure tant qu'il est désigné comme nœud abonné avec un abonnement au serveur de publication. Avant de mettre à niveau le nœud abonné RDS for PostgreSQL, supprimez l'abonnement et le nœud. Pour de plus amples informations, veuillez consulter [Gestion des emplacements de réplication logiques pour pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md).
## Détermination de la perturbation de la réplication logique
Vous pouvez déterminer que le processus de réplication a été interrompu en interrogeant le nœud de serveur de publication ou le nœud abonné, comme suit.
**Pour vérifier le nœud de serveur de publication**
+ Utilisez `psql` pour vous connecter au nœud de serveur de publication, puis interrogez la fonction `pg_replication_slots`. Notez la valeur dans la colonne active. Normalement, cela renvoie la valeur `t` (true), ce qui montre que la réplication est active. Si la requête renvoie la valeur `f` (false), cela indique que la réplication vers l'abonné a cessé.
```
SELECT slot_name,plugin,slot_type,active FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_labcb4fa94_docs_lab3de412c | pglogical_output | logical | f
(1 row)
```
**Pour vérifier le nœud abonné**
Sur le nœud abonné, vous pouvez vérifier l'état de la réplication de trois manières différentes.
+ Consultez les journaux PostgreSQL sur le nœud abonné pour trouver des messages d'échec. Le journal identifie l'échec avec des messages qui incluent le code de sortie 1, comme indiqué ci-dessous.
```
2022-07-06 16:17:03 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 14610) exited with exit code 1
2022-07-06 16:19:44 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 21783) exited with exit code 1
```
+ Interrogez la fonction `pg_replication_origin`. Connectez-vous à la base de données sur le nœud abonné en utilisant `psql` et interrogez la fonction `pg_replication_origin`, comme suit.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+--------
(0 rows)
```
L'ensemble de résultats vide signifie que la réplication a été perturbée. Normalement, vous obtenez un résultat qui ressemble au suivant.
```
roident | roname
---------+----------------------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
+ Interrogez la fonction `pglogical.show_subscription_status` comme indiqué dans l'exemple suivant.
```
SELECT subscription_name,status,slot_name FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
---====----------------+--------+-------------------------------------
docs_lab_subscription | down | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
Cette sortie montre que la réplication a été perturbée. Son statut est `down`. Normalement, la sortie indique le statut `replicating`.
Si votre processus de réplication logique a été perturbé, vous pouvez rétablir la réplication en suivant les étapes suivantes.
**Pour rétablir la réplication logique entre les nœuds de serveur de publication et abonné.**
Pour rétablir la réplication, vous devez d'abord déconnecter l'abonné du nœud de serveur de publication, puis rétablir l'abonnement, comme indiqué dans les étapes suivantes.
1. Connectez-vous au nœud abonné à l'aide de `psql`, comme suit.
```
psql --host=222222222222.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Désactivez l'abonnement en utilisant la fonction `pglogical.alter_subscription_disable`.
```
SELECT pglogical.alter_subscription_disable('docs_lab_subscription',true);
alter_subscription_disable
----------------------------
t
(1 row)
```
1. Obtenez l'identifiant du nœud de serveur de publication en interrogeant `pg_replication_origin`, comme suit.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+-------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
1. Utilisez la réponse de l'étape précédente avec la commande `pg_replication_origin_create` pour attribuer l'identifiant qui peut être utilisé par l'abonnement lorsqu'il est rétabli.
```
SELECT pg_replication_origin_create('pgl_labdb_docs_labcb4fa94_docs_lab3de412c');
pg_replication_origin_create
------------------------------
1
(1 row)
```
1. Activez l'abonnement en transmettant son nom avec un statut `true`, comme indiqué dans l'exemple suivant.
```
SELECT pglogical.alter_subscription_enable('docs_lab_subscription',true);
alter_subscription_enable
---------------------------
t
(1 row)
```
Vérifiez le statut du nœud. Son statut doit être `replicating`, tel qu'indiqué dans cet exemple.
```
SELECT subscription_name,status,slot_name
FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
-------------------------------+-------------+-------------------------------------
docs_lab_subscription | replicating | pgl_labdb_docs_lab98f517b_docs_lab3de412c
(1 row)
```
Vérifiez le statut de l'emplacement de réplication de l'abonné sur le nœud de serveur de publication. La colonne `active` de l'emplacement doit retourner `t` (true), indiquant que la réplication a été rétablie.
```
SELECT slot_name,plugin,slot_type,active
FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_lab98f517b_docs_lab3de412c | pglogical_output | logical | t
(1 row)
```
# Gestion des emplacements de réplication logiques pour pour PostgreSQL
Avant de pouvoir effectuer une mise à niveau de version majeure sur un cluster de bases de données Aurora PostgreSQL qui sert de nœud de serveur de publication dans un scénario de réplication logique, vous devez supprimer les emplacements de réplication sur l'instance. Le processus de pré-vérification des mises à niveau de versions majeures vous informe que la mise à niveau ne peut pas avoir lieu tant que les emplacements ne sont pas supprimés.
Pour supprimer des emplacements de votre instance de base de données RDS for PostgreSQL, vous devez d'abord supprimer l'abonnement, puis supprimer l'emplacement.
Pour identifier les emplacements de réplication qui ont été créés à l'aide de l'extension `pglogical`, connectez-vous à chaque base de données et obtenez le nom des nœuds. Lorsque vous interrogez le nœud abonné, vous obtenez à la fois le nœud de serveur de publication et le nœud abonné dans la sortie, comme le montre cet exemple.
```
SELECT * FROM pglogical.node;
node_id | node_name
------------+-------------------
2182738256 | docs_lab_target
3410995529 | docs_lab_provider
(2 rows)
```
Vous pouvez obtenir les détails de l'abonnement avec la requête suivante.
```
SELECT sub_name,sub_slot_name,sub_target
FROM pglogical.subscription;
sub_name | sub_slot_name | sub_target
----------+--------------------------------+------------
docs_lab_subscription | pgl_labdb_docs_labcb4fa94_docs_lab3de412c | 2182738256
(1 row)
```
Vous pouvez maintenant supprimer l'abonnement, comme suit.
```
SELECT pglogical.drop_subscription(subscription_name := 'docs_lab_subscription');
drop_subscription
-------------------
1
(1 row)
```
Après avoir supprimé l'abonnement, vous pouvez supprimer le nœud.
```
SELECT pglogical.drop_node(node_name := 'docs-lab-subscriber');
drop_node
-----------
t
(1 row)
```
Vous pouvez vérifier que le nœud n'existe plus, comme suit.
```
SELECT * FROM pglogical.node;
node_id | node_name
---------+-----------
(0 rows)
```
# Référence des paramètres de l'extension pglogical
Dans le tableau, vous pouvez trouver les paramètres associés à l'extension `pglogical`. Les paramètres tels que `pglogical.conflict_log_level` et `pglogical.conflict_resolution` sont utilisés pour gérer les conflits de mise à jour. Des conflits peuvent survenir lorsque des modifications sont apportées localement aux mêmes tables qui sont abonnées aux modifications du serveur de publication. Des conflits peuvent également se produire au cours de divers scénarios, tels que la réplication bidirectionnelle ou lorsque plusieurs abonnés se répliquent à partir du même serveur de publication. Pour plus d'informations, consultez [PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/) (Réplication bidirectionnelle PostgreSQL utilisant pglogical).
| Paramètre | Description |
| --- | --- |
| pglogical.batch\$1inserts | Insertions de lots si possible Non défini par défaut. Remplacez par « 1 » pour activer, par « 0 » pour désactiver. |
| pglogical.conflict\$1log\$1level | Définit le niveau de journalisation à utiliser pour la journalisation des conflits résolus. Les valeurs de chaîne prises en charge sont debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. |
| pglogical.conflict\$1resolution | Définit la méthode à utiliser pour résoudre les conflits lorsque ceux-ci sont résolubles. Les valeurs de chaîne prises en charge sont error, apply\$1remote, keep\$1local, last\$1update\$1wins, first\$1update\$1wins. |
| pglogical.extra\$1connection\$1options | Options de connexion à ajouter à toutes les connexions de nœuds de pairs. |
| pglogical.synchronous\$1commit | valeur de validation synchrone spécifique pglogical |
| pglogical.use\$1spi | Utilisez l'interface de programmation du serveur (SPI) au lieu de l'API de bas niveau pour appliquer les modifications. Définissez sur « 1 » pour activer, sur « 0 » pour désactiver. Pour plus d'informations sur SPI, consultez [Server Programming Interface](https://www.postgresql.org/docs/current/spi.html) (Interface de programmation du serveur) dans la documentation PostgreSQL. |
# Utilisation de pgactive pour prendre en charge la réplication active-active
L’extension `pgactive` utilise la réplication active-active pour prendre en charge et coordonner les opérations d’écriture sur plusieurs bases de données RDS pour PostgreSQL. Amazon RDS pour PostgreSQL prend en charge l’extension `pgactive` sur les versions suivantes.
+ RDS pour PostgreSQL 17.0 et toutes les versions ultérieures
+ RDS pour PostgreSQL 16.1 et versions 16 ultérieures
+ RDS pour PostgreSQL 15.4-R2 et versions 15 ultérieures
+ RDS pour PostgreSQL 14.10 et versions 14 ultérieures
+ RDS pour PostgreSQL 13.13 et versions 13 ultérieures
+ RDS pour PostgreSQL 12.17 et versions 12 ultérieures
+ RDS pour PostgreSQL 11.22
**Note**
Lorsque des opérations d'écriture se produisent sur plusieurs bases de données dans une configuration de réplication, des conflits peuvent survenir. Pour de plus amples informations, consultez [Gestion des conflits de la réplication active-active](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md).
**Topics**
+ [
## Limitations liées à l'extension pgactive
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.requirements-limitations)
+ [
# Initialisation de la capacité d'extension pgactive
](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md)
+ [
# Configuration de la réplication active-active pour des instances de base de données RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.pgactive.setup-replication.md)
+ [
# Mesure du retard de réplication entre les membres pgactive
](Appendix.PostgreSQL.CommonDBATasks.pgactive.replicationlag.md)
+ [
# Configuration des paramètres de l’extension pgactive
](Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.md)
+ [
# Comprendre les conflits active-active
](Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.replication.md)
+ [
# Présentation des schémas pgactive
](Appendix.PostgreSQL.CommonDBATasks.pgactive.schema.md)
+ [
# Référence des fonctions pgactive
](pgactive-functions-reference.md)
+ [
# Gestion des conflits de la réplication active-active
](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
+ [
# Gestion des séquences dans une réplication active-active
](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md)
## Limitations liées à l'extension pgactive
+ Toutes les tables nécessitent une clé primaire, faute de quoi, les mises à jour et les suppressions ne sont pas autorisées. Les valeurs de la colonne Primary Key (Clé primaire) ne doivent pas être mises à jour.
+ Les séquences peuvent présenter des écarts et parfois ne suivre aucun ordre. Les séquences ne sont pas répliquées. Pour de plus amples informations, veuillez consulter [Gestion des séquences dans une réplication active-active](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md).
+ Les objets volumineux et DDL ne sont pas répliqués.
+ Les index uniques secondaires peuvent causer des divergences de données.
+ Le classement doit être identique sur tous les nœuds du groupe.
+ L'équilibrage de charge entre les nœuds est un anti-modèle.
+ Les transactions volumineuses peuvent occasionner un retard de réplication.
# Initialisation de la capacité d'extension pgactive
Pour initialiser la capacité d'extension `pgactive` sur votre instance de base de données RDS for PostgreSQL, définissez la valeur du paramètre `rds.enable_pgactive` sur `1`, puis créez l'extension dans la base de données. Les paramètres `rds.logical_replication` et `track_commit_timestamp` sont alors automatiquement activés et la valeur de `wal_level` est définie sur `logical`.
Vous devez disposer d'autorisations en tant que rôle `rds_superuser` pour effectuer ces tâches.
Vous pouvez utiliser le AWS Management Console ou le AWS CLI pour créer le RDS requis pour les instances de base de données PostgreSQL. Les étapes suivantes partent du principe que votre instance de base de données RDS for PostgreSQL est associée à un groupe de paramètres de base de données personnalisés. Pour obtenir des informations sur la création d'un groupe de paramètres de base de données personnalisé, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
## Console
**Pour initialiser la capacité d'extension pgactive**
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 volet de navigation, sélectionnez votre instance de base de données RDS for PostgreSQL.
1. Ouvrez l'onglet **Configuration** pour votre instance de base de données RDS for PostgreSQL. Dans les détails de l'instance, recherchez le lien **Groupe de paramètres d'instance de base de données**.
1. Cliquez sur le lien pour ouvrir les paramètres personnalisés associés à votre instance de base de données RDS for PostgreSQL.
1. Recherchez le paramètre `rds.enable_pgactive` et définissez-le sur `1` pour initialiser la fonctionnalité `pgactive`.
1. Sélectionnez **Enregistrer les modifications**.
1. Dans le panneau de navigation de la console Amazon RDS, sélectionnez **Bases de données**.
1. Sélectionnez votre instance de base de données RDS for PostgreSQL, puis choisissez **Redémarrer** dans le menu **Actions**.
1. Confirmez le redémarrage de l'instance de base de données pour que vos modifications prennent effet.
1. Une fois l'instance de base de données disponible, vous pouvez utiliser `psql` ou tout autre client PostgreSQL pour vous connecter à l'instance de base de données RDS for PostgreSQL.
L'exemple suivant suppose que votre instance de base de données RDS pour PostgreSQL possède une base de données par défaut nommée. *postgres*
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Pour vérifier que pgactive est initialisé, exécutez la commande suivante.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Si `pgactive` se trouve dans `shared_preload_libraries`, la commande précédente renvoie ceci :
```
?column?
----------
t
```
## AWS CLI
**Pour initialiser la capacité d'extension pgactive**
Pour initialiser l'`pgactive`utilisation de AWS CLI, appelez l'[modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html)opération pour modifier certains paramètres de votre groupe de paramètres personnalisé, comme indiqué dans la procédure suivante.
1. Utilisez la AWS CLI commande suivante pour définir sur afin `rds.enable_pgactive` d'`1`initialiser la `pgactive` fonctionnalité de l'instance de base de données RDS pour PostgreSQL.
```
postgres=>aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.enable_pgactive,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilisez la AWS CLI commande suivante pour redémarrer l'instance de base de données RDS pour PostgreSQL afin que `pgactive` la bibliothèque soit initialisée.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Lorsque l'instance est disponible, utilisez `psql` pour vous connecter à l'instance de base de données RDS for PostgreSQL.
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=master user --password=PASSWORD --dbname=postgres
```
1. Pour vérifier que pgactive est initialisé, exécutez la commande suivante.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Si `pgactive` se trouve dans `shared_preload_libraries`, la commande précédente renvoie ceci :
```
?column?
----------
t
```
# Configuration de la réplication active-active pour des instances de base de données RDS pour PostgreSQL
La procédure suivante vous montre comment démarrer la réplication active-active entre deux instances de base de données RDS pour PostgreSQL où `pgactive` est disponible. Pour suivre l’exemple de haute disponibilité multirégionale, vous devez déployer des instances Amazon RDS pour PostgreSQL dans deux régions différentes et configurer l’appairage de VPC. Pour en savoir plus, consultez [Appairage de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html).
**Note**
L'envoi de trafic entre plusieurs régions peut induire des coûts supplémentaires.
Ces étapes partent du principe que l’instance de base de données RDS pour PostgreSQL a été configurée avec l’extension `pgactive`. Pour de plus amples informations, veuillez consulter [Initialisation de la capacité d'extension pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
**Pour configurer la première instance de base de données RDS pour PostgreSQL avec l’extension `pgactive`**
L’exemple suivant illustre la façon dont le groupe `pgactive` est créé et présente les autres étapes nécessaires à la création de l’extension `pgactive` sur l’instance de base de données RDS pour PostgreSQL.
1. Utilisez `psql` ou un autre outil client pour vous connecter à votre première instance de base de données RDS pour PostgreSQL.
```
psql --host=firstinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Créez une base de données sur l’instance RDS pour PostgreSQL à l’aide de la commande suivante :
```
postgres=> CREATE DATABASE app;
```
1. Faites basculer la connexion sur la nouvelle base de données à l'aide de la commande suivante :
```
\c app
```
1. Créez et remplissez une table d'exemple à l'aide des instructions SQL suivantes :
1. Créez un exemple de table en utilisant l’instruction SQL suivante.
```
app=> CREATE SCHEMA inventory;
CREATE TABLE inventory.products (
id int PRIMARY KEY, product_name text NOT NULL,
created_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP);
```
1. Remplissez la table avec des données d'exemple à l'aide de l'instruction SQL suivante.
```
app=> INSERT INTO inventory.products (id, product_name)
VALUES (1, 'soap'), (2, 'shampoo'), (3, 'conditioner');
```
1. Vérifiez que les données existent dans la table à l’aide de l’instruction SQL suivante.
```
app=>SELECT count(*) FROM inventory.products;
count
-------
3
```
1. Créez l'extension `pgactive` sur la base de données existante.
```
app=> CREATE EXTENSION pgactive;
```
1. Pour créer et initialiser le groupe pgactive en toute sécurité, utilisez les commandes suivantes :
```
app=>
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
Vous pouvez maintenant initialiser le groupe de réplication et ajouter cette première instance :
```
SELECT pgactive.pgactive_create_group(
node_name := 'endpoint1-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Utilisez les commandes suivantes comme méthode alternative mais moins sécurisée pour créer et initialiser le groupe pgactive :
```
app=> SELECT pgactive.pgactive_create_group(
node_name := 'node1-app',
node_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node1-app est le nom que vous attribuez pour identifier de manière unique un nœud dans le groupe `pgactive`.
**Note**
Pour pouvoir effectuer cette étape sur une instance de base de données accessible au public, vous devez activer le paramètre `rds.custom_dns_resolution` en le définissant sur `1`.
1. Pour vérifier si l'instance de base de données est prête, utilisez la commande suivante :
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Si la commande aboutit, vous obtenez la sortie suivante :
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
**Pour configurer la deuxième instance RDS pour PostgreSQL et la joindre au groupe `pgactive`**
L’exemple suivant illustre la façon dont une instance de base de données RDS pour PostgreSQL est jointe au groupe `pgactive` et présente les autres étapes nécessaires à la création de l’extension `pgactive` sur l’instance de base de données.
Ces étapes partent du principe que d’autres instances de base de données RDS pour PostgreSQL ont été configurées avec l’extension `pgactive`. Pour de plus amples informations, veuillez consulter [Initialisation de la capacité d'extension pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
1. Utilisez `psql` pour vous connecter à l’instance qui doit recevoir les mises à jour du serveur de publication.
```
psql --host=secondinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Créez une base de données sur la deuxième instance de base de données RDS pour PostgreSQL à l’aide de la commande suivante :
```
postgres=> CREATE DATABASE app;
```
1. Faites basculer la connexion sur la nouvelle base de données à l'aide de la commande suivante :
```
\c app
```
1. Créez l'extension `pgactive` sur la base de données existante.
```
app=> CREATE EXTENSION pgactive;
```
1. Joignez la deuxième instance de base de données RDS pour PostgreSQL au groupe `pgactive` dans une méthode pus sécurisée utilisant les commandes suivantes :
```
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
```
SELECT pgactive.pgactive_join_group(
node_name := 'endpoint2-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint2',
join_using_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Utilisation des commandes suivantes comme méthode alternative mais moins sécurisée pour joindre la deuxième instance de base de données RDS pour PostgreSQL au groupe `pgactive`
```
app=> SELECT pgactive.pgactive_join_group(
node_name := 'node2-app',
node_dsn := 'dbname=app host=secondinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD',
join_using_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node2-app est le nom que vous attribuez pour identifier de manière unique un nœud dans le groupe `pgactive`.
1. Pour vérifier si l'instance de base de données est prête, utilisez la commande suivante :
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Si la commande aboutit, vous obtenez la sortie suivante :
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
Si la première base de données RDS pour PostgreSQL est relativement volumineuse, `pgactive.pgactive_wait_for_node_ready()` émet le rapport de progression de l’opération de restauration. La sortie ressemble à ce qui suit:
```
NOTICE: restoring database 'app', 6% of 7483 MB complete
NOTICE: restoring database 'app', 42% of 7483 MB complete
NOTICE: restoring database 'app', 77% of 7483 MB complete
NOTICE: restoring database 'app', 98% of 7483 MB complete
NOTICE: successfully restored database 'app' from node node1-app in 00:04:12.274956
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
À partir de cet instant, `pgactive` synchronise les données entre les deux instances de base de données.
1. Vous pouvez utiliser la commande suivante pour vérifier si la base de données de la deuxième instance de base de données contient les données :
```
app=> SELECT count(*) FROM inventory.products;
```
Si les données ont bien été synchronisées, vous obtenez la sortie suivante :
```
count
-------
3
```
1. Exécutez la commande suivante pour insérer de nouvelles valeurs :
```
app=> INSERT INTO inventory.products (id, product_name) VALUES (4, 'lotion');
```
1. Connectez-vous à la base de données de la première instance de base de données et exécutez la requête suivante :
```
app=> SELECT count(*) FROM inventory.products;
```
Si la réplication active-active est initialisée, vous obtenez une sortie de ce type :
```
count
-------
4
```
**Pour détacher et supprimer une instance de base de données du groupe `pgactive`**
Vous pouvez détacher et supprimer une instance de base de données du groupe `pgactive` en suivant ces étapes :
1. Vous pouvez détacher la deuxième instance de base de données de la première à l'aide de la commande suivante :
```
app=> SELECT * FROM pgactive.pgactive_detach_nodes(ARRAY[‘node2-app']);
```
1. Supprimez l'extension `pgactive` de la deuxième instance de base de données à l'aide de la commande suivante :
```
app=> SELECT * FROM pgactive.pgactive_remove();
```
Pour supprimer l'extension de force :
```
app=> SELECT * FROM pgactive.pgactive_remove(true);
```
1. Supprimez l'extension à l'aide de la commande suivante :
```
app=> DROP EXTENSION pgactive;
```
# Mesure du retard de réplication entre les membres pgactive
Vous pouvez utiliser la requête suivante pour afficher le retard de réplication entre les membres `pgactive`. Exécutez cette requête sur chaque nœud `pgactive` pour obtenir une vue d’ensemble complète.
```
app=> SELECT * FROM pgactive.pgactive_get_replication_lag_info();
│-[ RECORD 1 ]--------+---------------------------------------------
│node_name | node2-app
│node_sysid | 7481018224801653637
│application_name | pgactive:7481018224801653637:send
│slot_name | pgactive_16385_7481018224801653637_0_16385__
│active | t
│active_pid | 783486
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/2108150
│confirmed_flush_lsn | 0/2154690
│sent_lsn | 0/2154690
│write_lsn | 0/2154690
│flush_lsn | 0/2154690
│replay_lsn | 0/2154690
│-[ RECORD 2 ]--------+---------------------------------------------
│node_name | node1-app
│node_sysid | 7481018033434600853
│application_name | pgactive:7481018033434600853:send
│slot_name | pgactive_16385_7481018033434600853_0_16385__
│active | t
│active_pid | 783488
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/20F5AD0
│confirmed_flush_lsn | 0/214EF68
│sent_lsn | 0/214EF68
│write_lsn | 0/214EF68
│flush_lsn | 0/214EF68
│replay_lsn | 0/214EF68
```
Surveillez au minimum les diagnostics suivants :
actif
Configurer des alertes lorsqu’actif a la valeur false, ce qui indique que l’emplacement n’est pas actuellement utilisé (l’instance d’abonné s’est déconnectée du diffuseur de publication).
pending\$1wal\$1decoding
Dans la réplication logique de PostgreSQL, les fichiers WAL sont stockés au format binaire. Le diffuseur de publication doit décoder ces modifications WAL et les convertir en modifications logiques (telles que des opérations d’insertion, de mise à jour ou de suppression).
La métrique pending\$1wal\$1decoding indique le nombre de fichiers WAL en attente de décodage côté diffuseur de publication.
Ce nombre peut augmenter en raison des facteurs suivants :
+ Lorsque l’abonné n’est pas connecté, le statut actif a la valeur false et le paramètre pending\$1wal\$1decoding augmente
+ L’emplacement est actif, mais le diffuseur de publication ne parvient pas à suivre le volume de modifications du WAL
pending\$1wal\$1to\$1apply
La métrique pending\$1wal\$1apply indique le nombre de fichiers WAL en attente d’être appliqués côté abonné.
Plusieurs facteurs peuvent empêcher l’abonné d’appliquer les modifications et provoquer un scénario de saturation du disque :
+ Différences de schéma : par exemple, lorsque vous modifiez le flux WAL pour une table nommée échantillon, mais que cette table n’existe pas du côté abonné
+ Les valeurs des colonnes de clé primaire ont été mises à jour
+ Les index uniques secondaires peuvent causer des divergences de données.
# Configuration des paramètres de l’extension pgactive
Vous pouvez utiliser la requête suivante pour afficher tous les paramètres associés à l'extension `pgactive`.
```
app=> SELECT * FROM pg_settings WHERE name LIKE 'pgactive.%';
```
Vous pouvez configurer l’extension `pgactive` à l’aide de différents paramètres. Ces paramètres peuvent être définis par le biais de l'interface CLI AWS Management Console ou de l'interface AWS CLI.
## Principaux paramètres de l’extension pgactive
Le tableau suivant fournit une référence pour les principaux paramètres de l’extension `pgactive` :
| Paramètre | Unit | Par défaut | Description |
| --- | --- | --- | --- |
| pgactive.conflict\$1logging\$1include\$1tuples | `boolean` | – | Journalise les informations complètes du tuple pour l’extension `pgactive`. Un redémarrage du serveur est nécessaire pour que les modifications prennent effet. |
| pgactive.log\$1conflicts\$1to\$1table | `boolean` | – | Détermine si l’extension `pgactive` journalise les conflits détectés dans la table `pgactive.pgactive_conflict_history`. Pour plus d’informations, consultez Journalisation des conflits. Un redémarrage du serveur est nécessaire pour que les modifications prennent effet. |
| pgactive.log\$1conflicts\$1to\$1logfile | `boolean` | – | Détermine si l’extension `pgactive` journalise les conflits détectés dans le fichier journal PostgreSQL. Pour plus d’informations, consultez Journalisation des conflits. Un redémarrage du serveur est nécessaire pour que les modifications prennent effet. |
| pgactive.synchronous\$1commit | `boolean` | off | Détermine le comportement de validation pour les applications de travail d’application pgactive. Lorsque cette option est désactivée (off), les applications de travail d’application effectuent des validations asynchrones, ce qui améliore le débit de PostgreSQL lors des opérations d’application, mais retarde les confirmations de relecture en amont. La paramétrer sur `off` est toujours sûr et n’entraîne pas de perte ni de saut de transaction. Ce paramètre affecte uniquement le calendrier des vidanges de disque sur le nœud en aval et le moment où les confirmations sont envoyées en amont. Le système retarde l’envoi des confirmations de relecture jusqu’à ce que les validations soient vidées sur le disque par le biais d’opérations indépendantes, telles que des points de contrôle ou des tâches périodiques. Toutefois, si l’amont a répertorié l’aval dans `synchronous_standby_names`, si vous définissez ce paramètre sur `off`, les validations synchrones en amont mettent plus de temps à signaler le succès au client. Dans ce cas, définissez le paramètre sur `on`. Même lorsque ce paramètre est défini sur `on`, avec des nœuds répertoriés dans `synchronous_standby_names`, des conflits de réplication peuvent toujours se produire dans les configurations active-active. Cela est dû au fait que le système ne dispose pas de verrouillage entre nœuds ni de gestion globale des instantanés, ce qui permet à des transactions simultanées sur différents nœuds de modifier le même tuple. De plus, les transactions ne commencent la réplication qu’après avoir été validées sur le nœud en amont. L’activation de la validation synchrone ne transforme pas l’extension pgactive en un système toujours cohérent. |
| pgactive.temp\$1dump\$1directory | `string` | – | Définit le chemin de stockage temporaire requis pour les opérations de clonage de base de données lors de la configuration initiale. Ce répertoire doit être accessible en écriture par l’utilisateur postgres et disposer d’un espace de stockage suffisant pour contenir un vidage complet de la base de données. Le système utilise cet emplacement uniquement lors de la configuration initiale de la base de données avec des opérations de copie logique. Ce paramètre n’est pas utilisé par la `pgactive_init_copy command`. |
| pgactive.max\$1ddl\$1lock\$1delay | `milliseconds` | `-1` | Spécifie le temps d’attente maximal pour le verrou DDL avant l’abandon forcé de transactions d’écriture simultanées. La valeur par défaut est `-1`, qui adopte la valeur définie dans `max_standby_streaming_delay`. Ce paramètre accepte les unités de temps. Par exemple, vous pouvez le définir sur 10 s pour 10 secondes. Pendant cette période d’attente, le système tente d’acquérir des verrous DDL en attendant que les transactions d’écriture en cours soient validées ou annulées. Pour plus d’informations, consultez Verrouillage DDL. |
| pgactive.ddl\$1lock\$1timeout | `milliseconds` | `-1` | Spécifie le temps d’attente d’une tentative de verrouillage DDL pour obtenir le verrou. La valeur par défaut est `-1`, qui utilise la valeur spécifiée dans lock\$1timeout. Vous pouvez définir ce paramètre en utilisant des unités de temps telles que 10 s pour 10 secondes. Ce minuteur contrôle uniquement la période d’attente pour obtenir un verrou DDL. Une fois que le système obtient le verrou et commence l’opération DDL, le minuteur s’arrête. Ce paramètre ne limite pas la durée totale pendant laquelle un verrou DDL peut être maintenu ni le temps global de l’opération DDL. Pour contrôler la durée totale de l’opération, utilisez plutôt `statement_timeout`. Pour plus d’informations, consultez Verrouillage DDL. |
| pgactive.debug\$1trace\$1ddl\$1locks\$1level | `boolean` | – | Remplace le niveau de journalisation de débogage par défaut pour les opérations de verrouillage DDL dans l’extension `pgactive`. Lorsqu’il est configuré, ce paramètre entraîne l’émission de messages relatifs aux verrous DDL au niveau de débogage JOURNAL au lieu du niveau par défaut. Utilisez ce paramètre pour surveiller l’activité de verrouillage DDL sans activer les niveaux de journalisation détaillée `DEBUG1` ou `DEBUG2` sur l’ensemble du serveur. Niveaux de journalisation disponibles, par ordre croissant de détail : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Pour plus d’informations sur les options de surveillance, consultez Surveillance des verrous DDL globaux. Les modifications apportées à ce paramètre prennent effet lorsque vous rechargez la configuration. Vous n’avez pas besoin de redémarrer le serveur. |
## Paramètres supplémentaires de l’extension pgactive
Le tableau suivant présente les options de configuration internes moins fréquemment utilisées disponibles pour l’extension `pgactive`.
| Paramètre | Unit | Par défaut | Description |
| --- | --- | --- | --- |
| pgactive.debug\$1apply\$1delay | `integer` | – | Définit un délai d’application (en millisecondes) pour les connexions configurées dont l’entrée `pgactive.pgactive_connections` ne comporte pas de délai d’application explicite. Ce délai est défini lors de la création ou de la jointure d’un nœud, et pgactive ne relit pas une transaction sur des nœuds pairs avant qu’au moins le nombre de millisecondes spécifié ne se soit écoulé depuis sa validation. Principalement utilisé pour simuler des réseaux à latence élevée dans des environnements de test afin de faciliter la création de conflits. Par exemple, avec un délai de 500 ms sur les nœuds A et B, vous disposez d’au moins 500 ms pour effectuer une insertion conflictuelle sur le nœud B après avoir inséré une valeur sur le nœud A. Nécessite le rechargement du serveur ou le redémarrage des applications de travail d’application pour prendre effet. |
| pgactive.connectability\$1check\$1duration | `integer` | – | Spécifie la durée (en secondes) pendant laquelle une application de travail de base de données tente d’établir des connexions en cas de tentative infructueuse. L’application de travail effectue une tentative de connexion par seconde jusqu’à ce qu’elle réussisse ou atteigne ce délai d’expiration. Ce paramètre est utile lorsque le moteur de base de données démarre avant que l’application de travail ne soit prête à établir des connexions. |
| pgactive.skip\$1ddl\$1replication | `boolean` | `on` | Contrôle la manière dont les modifications DDL sont répliquées ou gérées dans Amazon RDS lorsque `pgactive` est activé. Lorsqu’il est défini sur `on`, le nœud traite les modifications DDL comme un nœud non pgactive. Les exigences suivantes s’appliquent lors de l’utilisation de ce paramètre : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Vous pouvez modifier ce paramètre de deux manières avec les privilèges de super utilisateur : globalement, localement (au niveau de la session). Une modification incorrecte de ce paramètre peut corrompre les configurations de réplication. |
| pgactive.do\$1not\$1replicate | `boolean` | – | Ce paramètre est réservé à une utilisation interne. Lorsque vous définissez ce paramètre dans une transaction, les modifications ne sont pas répliquées sur les autres nœuds du cluster de bases de données. Une modification incorrecte de ce paramètre peut corrompre les configurations de réplication. |
| pgactive.discard\$1mismatched\$1row\$1attributes | `boolean` | – | Ce paramètre est réservé à une utilisation par des spécialistes. Nous recommandons d’utiliser ce paramètre uniquement pour résoudre des problèmes de réplication spécifiques. Utilisez ce paramètre lorsque : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Ce paramètre remplace le message d’erreur suivant et permet la divergence de données afin de permettre la poursuite de la réplication : `cannot right-pad mismatched attributes; attno %u is missing in local table and remote row has non-null, non-dropped value for this attribute` Une modification incorrecte de ce paramètre peut corrompre les configurations de réplication. |
| pgactive.debug\$1trace\$1replay | `boolean` | – | Lorsqu’il est défini sur `on`, il émet un message de journal pour chaque action à distance effectuée par les processus de travail d’application en aval. Les journaux incluent : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Les journaux capturent également les commandes DDL en file d’attente et les suppressions de tables.para> Par défaut, les journaux n’incluent pas le contenu des champs de ligne. Pour inclure des valeurs de ligne dans les journaux, vous devez effectuer une recompilation avec les indicateurs suivants activés : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) L’activation de ce paramètre de journalisation peut avoir un impact sur les performances. Nous vous recommandons de l’activer uniquement lorsque c’est nécessaire pour la résolution des problèmes. Les modifications apportées à ce paramètre prennent effet lorsque vous rechargez la configuration. Vous n’avez pas besoin de redémarrer le serveur. |
| pgactive.extra\$1apply\$1connection\$1options | | – | Vous pouvez configurer les paramètres de connexion pour toutes les connexions de nœuds pairs avec des nœuds pgactive. Ces paramètres contrôlent les paramètres tels que les modes keepalives et SSL. Par défaut, pgactive utilise les paramètres de connexion suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Pour remplacer les paramètres par défaut, utilisez la commande similaire suivante : pgactive.extra\$1apply\$1connection\$1options = 'keepalives=0' Les chaînes de connexion des nœuds individuels ont la priorité sur ces paramètres et sur les options de connexion intégrées de pgactive. Pour plus d’informations sur les formats de chaînes de connexion, consultez la rubrique relative aux [chaînes de connexion libpq](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING). Nous vous recommandons de conserver les paramètres keepalive par défaut activés. Désactivez les paramètres keepalive uniquement si vous rencontrez des problèmes lors de transactions importantes effectuées sur des réseaux peu fiables. Nous vous recommandons de conserver les paramètres keepalive par défaut activés. Désactivez les paramètres keepalive uniquement si vous rencontrez des problèmes lors de transactions importantes effectuées sur des réseaux peu fiables. Les modifications apportées à ce paramètre prennent effet lorsque vous rechargez la configuration. Vous n’avez pas besoin de redémarrer le serveur. |
| pgactive.init\$1node\$1parallel\$1jobs (int) | | – | Spécifie le nombre de tâches parallèles que `pg_dump` et `pg_restore` peuvent utiliser lors des jointures de nœuds logiques avec la fonction `pgactive.pgactive_join_group`. Les modifications apportées à ce paramètre prennent effet lorsque vous rechargez la configuration. Vous n’avez pas besoin de redémarrer le serveur. |
| pgactive.max\$1nodes | `int` | 4 | Spécifie le nombre maximal de nœuds autorisés dans un groupe d’extensions pgactive. La valeur par défaut est de 4 nœuds. Vous devez prendre en considération ce qui suit lors de la définition de la valeur de ce paramètre : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Vous pouvez définir ce paramètre de deux manières : dans le fichier de configuration, à l’aide de la commande `ALTER SYSTEM SET` La valeur par défaut de ce paramètre est `4`, ce qui signifie qu’il peut y avoir un maximum de 4 nœuds autorisés dans le groupe d’extensions `pgactive` à tout moment. La modification prend effet après le redémarrage du serveur. |
| pgactive.permit\$1node\$1identifier\$1getter\$1function\$1creation | `boolean` | – | Ce paramètre est réservé à une utilisation interne. Lorsqu’il est activé, l’extension `pgactive` permet de créer la fonction getter d’identifiant de nœud pgactive. |
# Comprendre les conflits active-active
Lorsque vous utilisez pgactive en mode active-active, l’écriture dans les mêmes tables à partir de plusieurs nœuds peut créer des conflits de données. Alors que certains systèmes de mise en cluster utilisent des verrous distribués pour empêcher les accès simultanés, pgactive adopte une approche optimiste qui convient mieux aux applications distribuées géographiquement.
Certains systèmes de mise en cluster de bases de données empêchent l’accès simultané aux données en utilisant des verrous distribués. Bien que cette approche fonctionne lorsque les serveurs sont à proximité, elle ne prend pas en charge les applications distribuées géographiquement, car elle nécessite une latence extrêmement faible pour de bonnes performances. Au lieu d’utiliser des verrous distribués (approche pessimiste), l’extension pgactive utilise une approche optimiste. Cela signifie qu’elle :
+ Vous aide à éviter les conflits dans la mesure du possible.
+ Permet à certains types de conflits de se produire.
+ Permet de résoudre les conflits lorsque des conflits surviennent.
Cette approche vous donne plus de flexibilité lors de la création d’applications distribuées.
## Comment se produisent les conflits
Les conflits entre nœuds proviennent de séquences d’événements qui ne pourraient pas se produire si toutes les transactions impliquées se produisaient simultanément sur le même nœud. Comme les nœuds n’échangent des modifications qu’une fois les transactions validées, chaque transaction est valide individuellement sur le nœud sur lequel elle a été validée, mais ne le serait pas si elle était exécutée sur un autre nœud ayant effectué une autre tâche dans l’intervalle. Comme l’application de pgactive réexécute essentiellement la transaction sur les autres nœuds, l’opération de réexécution peut échouer en cas de conflit entre une transaction appliquée et une transaction validée sur le nœud récepteur.
La raison pour laquelle la plupart des conflits ne peuvent pas se produire lorsque toutes les transactions sont exécutées sur un seul nœud est que PostgreSQL dispose de mécanismes de communication entre transactions pour les empêcher, notamment :
+ Index UNIQUE
+ SEQUENCEs
+ Verrouillage des lignes et des relations
+ Suivi des dépendances SERIALIZABLE
Tous ces mécanismes sont des moyens de communiquer entre les transactions afin d’éviter les problèmes de simultanéité indésirables.
pgactive atteint une faible latence et gère bien les partitions réseau, car il n’utilise pas de gestionnaire de transactions distribué ni de gestionnaire de verrouillage. Cependant, cela signifie que les transactions sur différents nœuds s’exécutent de manière totalement isolée les unes des autres. Bien que l’isolation améliore généralement la cohérence de la base de données, dans ce cas, vous devez réduire l’isolation pour éviter les conflits.
## Types de conflits
Les conflits qui peuvent survenir sont notamment les suivants :
**Topics**
+ [
### Conflits PRIMARY KEY ou UNIQUE
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict1)
+ [
### Conflits INSERT/INSERT
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict2)
+ [
### INSERTs qui violent plusieurs contraintes UNIQUES
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict3)
+ [
### Conflits UPDATE/UPDATE
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict4)
+ [
### Conflits UPDATE sur la PRIMARY KEY
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5)
+ [
### UPDATEs qui violent plusieurs contraintes UNIQUES
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict6)
+ [
### Conflits UPDATE/DELETE
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7)
+ [
### Conflits INSERT/UPDATE
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict8)
+ [
### Conflits DELETE/DELETE
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict9)
+ [
### Conflits de contraintes liées aux clés étrangères
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict10)
+ [
### Conflits de contraintes d’exclusion
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict11)
+ [
### Conflits de données globales
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict12)
+ [
### Conflits de verrou et abandons les blocages
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict13)
+ [
### Conflits divergents
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14)
### Conflits PRIMARY KEY ou UNIQUE
Les conflits de lignes se produisent lorsque plusieurs opérations tentent de modifier la même clé de ligne d’une manière impossible sur un seul nœud. Ces conflits constituent le type de conflit de données le plus courant.
pgactive résout les conflits détectés par le biais de last-update-wins la gestion ou de votre gestionnaire de conflits personnalisé.
Les conflits de lignes incluent :
+ INSERT et INSERT
+ INSERT et UPDATE
+ UPDATE et DELETE
+ INSERT et DELETE
+ DELETE et DELETE
+ INSERT et DELETE
### Conflits INSERT/INSERT
Ce conflit le plus courant se produit lorsque, INSERTs sur deux nœuds différents, créez un tuple avec les mêmes valeurs de CLÉ PRIMAIRE (ou des valeurs de contrainte UNIQUE identiques lorsqu'aucune CLÉ PRIMAIRE n'existe).
pgactivelink résout les conflits INSERT en utilisant l’horodatage de l’hôte d’origine pour conserver le tuple le plus récent. Vous pouvez remplacer ce comportement par défaut à l’aide de votre gestionnaire de conflits personnalisé. Bien que ce processus ne nécessite aucune action particulière de l’administrateur, sachez que pgactivelink ignore l’une des opérations INSERT sur tous les nœuds. Aucune fusion automatique de données ne se produit à moins que votre gestionnaire personnalisé ne l’implémente.
Le pgactivelink ne peut résoudre que les conflits impliquant une seule violation de contrainte. Si un INSERT enfreint plusieurs contraintes UNIQUE, vous devez mettre en œuvre des stratégies de résolution de conflits supplémentaires.
### INSERTs qui violent plusieurs contraintes UNIQUES
Un INSERT/INSERT conflit peut violer plusieurs contraintes UNIQUE, y compris la CLÉ PRIMAIRE. pgactivelink ne peut gérer que les conflits impliquant une seule contrainte UNIQUE. Lorsque des conflits violent plusieurs contraintes UNIQUE, l’application de travail d’application échoue et renvoie l’erreur suivante :
`multiple unique constraints violated by remotely INSERTed tuple.`
Dans les anciennes versions, cette situation générait plutôt une erreur de « conflit d’unicité divergente ».
Pour résoudre ces conflits, vous devez effectuer une action manuelle. Effectuez une opération DELETE sur les tuples locaux en conflit ou une opération UPDATE pour supprimer les conflits avec le nouveau tuple distant. Sachez que vous devrez peut-être résoudre plusieurs tuples en conflit. À l’heure actuelle, pgactivelink ne fournit aucune fonctionnalité intégrée permettant d’ignorer, de supprimer ou de fusionner les tuples qui violent plusieurs contraintes uniques.
**Note**
Pour plus d'informations, consultez la section UPDATEs relative à la violation de plusieurs contraintes UNIQUE.
### Conflits UPDATE/UPDATE
Ce conflit se produit lorsque deux nœuds modifient simultanément le même tuple sans changer sa CLÉ PRIMAIRE. pgactivelink résout ces conflits en utilisant la last-update-wins logique ou votre gestionnaire de conflits personnalisé, s'il est défini. Une PRIMARY KEY est essentielle pour l’appariement des tuples et la résolution des conflits. Pour les tables sans PRIMARY KEY, pgactivelink rejette les opérations UPDATE avec l’erreur suivante :
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
### Conflits UPDATE sur la PRIMARY KEY
pgactive a des limitations lors de la gestion des mises à jour de PRIMARY KEY. Bien que vous puissiez effectuer une opération de mise à jour sur une CLÉ PRIMAIRE, pgactive ne peut pas résoudre automatiquement les conflits en utilisant last-update-wins la logique de ces opérations. Vous devez vous assurer que les mises à jour de votre PRIMARY KEY n’entrent pas en conflit avec les valeurs existantes. Si des conflits surviennent lors des mises à jour de la PRIMARY KEY, ils deviennent des conflits divergents qui nécessitent une intervention manuelle de votre part. Pour plus d’informations sur la gestion de ces situations, consultez [Conflits divergents](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### UPDATEs qui violent plusieurs contraintes UNIQUES
pgactivelink ne peut pas appliquer de résolution de last-update-wins conflit lorsqu'une mise à jour entrante viole plusieurs contraintes UNIQUES ou valeurs PRIMARY KEY. Ce comportement est similaire à celui des opérations INSERT impliquant plusieurs violations de contraintes. Ces situations créent des conflits divergents qui nécessitent une intervention manuelle de votre part. Pour plus d’informations, consultez [Conflits divergents](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### Conflits UPDATE/DELETE
Ces conflits se produisent lorsqu'un nœud UPDATEs par ligne et qu'un autre nœud le DELETEs fait simultanément. Dans ce cas, un UPDATE/DELETE conflit survient lors de la rediffusion. La solution consiste à ignorer toute UPDATE qui arrive après une DELETE, sauf indication contraire de votre gestionnaire de conflits personnalisé.
pgactivelink a besoin d’une PRIMARY KEY pour apparier des tuples et résoudre les conflits. Pour les tables sans PRIMARY KEY, elle rejette les opérations DELETE avec l’erreur suivante :
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
**Note**
pgactivelink ne peut pas faire la distinction entre les conflits et UPDATE/DELETE . INSERT/UPDATE Dans les deux cas, une opération UPDATE affecte une ligne inexistante. En raison de la réplication asynchrone et de l’absence d’ordre de réexécution entre les nœuds, pgactivelink ne peut pas déterminer si la mise à jour concerne une nouvelle ligne (INSERT non encore reçu) ou une ligne supprimée. Dans les deux scénarios, pgactivelink ignore l’opération UPDATE.
### Conflits INSERT/UPDATE
Ce conflit peut se produire dans des environnements à nœuds multiples. Cela se produit lorsqu' INSERTs un nœud par ligne, un deuxième nœud UPDATEs et un troisième nœud reçoivent la mise à jour avant l'INSERT d'origine. Par défaut, pgactivelink résout ces conflits en supprimant l’UPDATE, sauf indication contraire de votre déclencheur de conflit personnalisé. Sachez que cette méthode de résolution peut entraîner des incohérences de données entre les nœuds. Pour plus d’informations sur des scénarios similaires et leur gestion, consultez [Conflits UPDATE/DELETE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7).
### Conflits DELETE/DELETE
Ce conflit se produit lorsque deux nœuds différents suppriment simultanément le même tuple. pgactivelink considère que ces conflits sont inoffensifs, car les deux opérations DELETE ont le même résultat final. Dans ce scénario, pgactivelink ignore en toute sécurité l’une des opérations DELETE sans affecter la cohérence des données.
### Conflits de contraintes liées aux clés étrangères
Les contraintes FOREIGN KEY peuvent provoquer des conflits lors de l’application de transactions distantes à des données locales existantes. Ces conflits se produisent généralement lorsque les transactions sont appliquées dans un ordre différent de leur ordre logique sur les nœuds d’origine.
Par défaut, pgactive applique les modifications avec session\$1replication\$1role en tant que `replica`, ce qui permet de contourner les contrôles de clé étrangère lors de la réplication. Dans les configurations active-active, cela peut entraîner des violations de clés étrangères. La plupart des violations sont temporaires et sont résolues une fois que la réplication rattrape son retard. Cependant, des suspensions de clés étrangères peuvent se produire parce que pgactive ne prend pas en charge le verrouillage des lignes entre nœuds.
Ce comportement est inhérent aux systèmes active-active asynchrones tolérants au partitionnement. Par exemple, le nœud A peut insérer une nouvelle ligne enfant tandis que le nœud B supprime simultanément sa ligne parent. Le système ne peut pas empêcher ce type de modification simultanée entre les nœuds.
Afin de minimiser les conflits de clés étrangères, nous vous recommandons de respecter les points suivants :
+ Limitez les relations de clé étrangère aux entités étroitement liées.
+ Modifiez les entités associées à partir d’un seul nœud lorsque cela est possible.
+ Choisissez des entités qui nécessitent rarement des modifications.
+ Mettez en œuvre un contrôle de simultanéité au niveau de l’application pour les modifications.
### Conflits de contraintes d’exclusion
pgactivelink ne prend pas en charge les contraintes d’exclusion et restreint leur création.
**Note**
Si vous convertissez une base de données autonome existante en base de données pgactivelink, supprimez manuellement toutes les contraintes d’exclusion.
Dans un système asynchrone distribué, il n’est pas possible de garantir qu’aucun ensemble de lignes ne viole la contrainte. Cela est dû au fait que toutes les transactions sur les différents nœuds sont totalement isolées. Les contraintes d’exclusion peuvent entraîner des blocages de relecture, dans lesquels la relecture ne peut pas progresser d’un nœud à l’autre en raison de violations des contraintes d’exclusion.
Si vous forcez pgactivelink à créer une contrainte d’exclusion, ou si vous ne supprimez pas les contraintes existantes lors de la conversion d’une base de données autonome en pgactivelink, la réplication risque de s’interrompre. Pour rétablir la progression de la réplication, supprimez ou modifiez les tuples locaux qui entrent en conflit avec un tuple distant entrant afin que la transaction distante puisse être appliquée.
### Conflits de données globales
Lorsque vous utilisez pgactivelink, des conflits peuvent survenir lorsque les nœuds possèdent des données globales PostgreSQL différentes à l’échelle du système, telles que des rôles. Ces conflits peuvent entraîner la réussite et la validation d’opérations (principalement DDL) sur un nœud, mais ne pas s’appliquer aux autres nœuds.
Si un utilisateur existe sur un nœud mais pas sur un autre, des problèmes de réplication peuvent survenir :
+ Node1 a un utilisateur nommé `fred`, mais cet utilisateur n’existe pas sur Node2
+ Lorsque `fred` crée une table sur Node1, la table est répliquée avec `fred` en tant que propriétaire
+ Lorsque cette commande DDL est appliquée à Node2, elle échoue, car l’utilisateur `fred` n’existe pas
+ Cet échec génère une ERROR dans les journaux PostgreSQL sur Node2 et incrémente le compteur `pgactive.pgactive_stats.nr_rollbacks`
**Résolution :** créez l’utilisateur `fred` sur Node2. L’utilisateur n’a pas besoin d’autorisations identiques mais doit exister sur les deux nœuds.
Si une table existe sur un nœud mais pas sur un autre, les opérations de modification des données échouent :
+ Node1 possède une table nommée `foo` qui n’existe pas sur Node2
+ Toute opération DML sur la table `foo` de Node1 échoue une fois répliquée sur Node2
**Résolution :** créez la table `foo` sur Node2 avec la même structure.
**Note**
pgactivelink ne réplique actuellement pas les commandes CREATE USER ni les opérations DDL. La réplication DDL est prévue pour une future version.
### Conflits de verrou et abandons les blocages
Comme les processus d’application pgactive fonctionnent comme des sessions utilisateur normales, ils suivent les règles standard de verrouillage des lignes et des tables. Cela peut amener les processus d’application de pgactivelink à attendre les verrous détenus par les transactions des utilisateurs ou par d’autres processus d’application.
Les types de verrous suivants peuvent affecter les processus d’application :
+ Verrouillage explicite au niveau de la table (LOCK TABLE ...) par les sessions utilisateur
+ Verrouillage explicite au niveau des lignes (SELECT... FOR UPDATE/FOR SHARE) par sessions utilisateur
+ Verrouillage à partir de clés étrangères
+ Verrouillage implicite dû à une ligne UPDATEs INSERTs DELETEs, ou à une activité locale ou à une application depuis d'autres serveurs
Des blocages peuvent se produire entre :
+ Un processus d’application pgactivelink et une transaction utilisateur
+ Deux processus d’application
Lorsque des blocages se produisent, le détecteur de blocage de PostgreSQL met fin à l’une des transactions problématiques. Si le processus de l’application de travail d’application pgactivelink est arrêté, il réessaie automatiquement et réussit généralement.
**Note**
Ces problèmes sont temporaires et ne nécessitent généralement pas l’intervention de l’administrateur. Si un processus d’application est bloqué pendant une période prolongée par le verrouillage d’une session utilisateur inactive, vous pouvez mettre fin à la session utilisateur pour reprendre la réplication. Cette situation est similaire à celle où un utilisateur détient un long verrou qui affecte une autre session utilisateur.
Pour identifier les délais de relecture liés au verrouillage, activez la fonctionnalité `log_lock_waits` dans PostgreSQL.
### Conflits divergents
Des conflits divergents se produisent lorsque des données qui devraient être identiques entre les nœuds diffèrent de façon inattendue. Bien que ces conflits ne devraient pas se produire, ils ne peuvent pas tous être évités de manière fiable dans le cadre de la mise en œuvre actuelle.
**Note**
La modification de la PRIMARY KEY d’une ligne peut provoquer des conflits divergents si un autre nœud modifie la clé de la même ligne avant que tous les nœuds n’aient traité la modification. Évitez de modifier les clés primaires ou limitez les modifications à un nœud désigné. Pour plus d’informations, consultez [Conflits UPDATE sur la PRIMARY KEY](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5).
Les conflits divergents impliquant des données de ligne nécessitent généralement l’intervention de l’administrateur. Pour résoudre ces conflits, vous devez ajuster manuellement les données d’un nœud pour qu’elles correspondent à celles d’un autre tout en désactivant temporairement la réplication à l’aide de `pgactive.pgactive_do_not_replicate`. Ces conflits ne devraient pas se produire lorsque vous utilisez pgactive comme indiqué et que vous évitez les paramètres ou les fonctions marqués comme non sécurisés.
En tant qu’administrateur, vous devez résoudre ces conflits manuellement. Selon le type de conflit, vous devez utiliser des options avancées telles que `pgactive.pgactive_do_not_replicate`. Utilisez ces options avec prudence, car une mauvaise utilisation peut aggraver la situation. En raison de la variété des conflits possibles, nous ne pouvons pas fournir d’instructions de résolution universelles.
Des conflits divergents se produisent lorsque des données qui devraient être identiques dans des nœuds différents diffèrent de façon inattendue. Bien que ces conflits ne devraient pas se produire, ils ne peuvent pas tous être évités de manière fiable dans le cadre de la mise en œuvre actuelle.
## Éviter ou tolérer les conflits
Dans la plupart des cas, vous pouvez utiliser une conception d’application appropriée pour éviter les conflits ou faire en sorte que votre application tolère les conflits.
Les conflits se produisent uniquement lorsque des opérations simultanées ont lieu sur plusieurs nœuds. Pour éviter les conflits :
+ Écrivez sur un seul nœud
+ Écrivez dans des sous-ensembles de base de données indépendants sur chaque nœud (par exemple, attribuer à chaque nœud un schéma distinct)
Pour les conflits INSERT et INSERT, utilisez des séquences globales pour éviter complètement les conflits.
Si les conflits ne sont pas acceptables pour votre cas d’utilisation, envisagez d’implémenter le verrouillage distribué au niveau de l’application. Souvent, la meilleure approche consiste à concevoir votre application pour qu’elle fonctionne avec les mécanismes de résolution de conflits de pgactive plutôt que d’essayer de prévenir tous les conflits. Pour plus d’informations, consultez [Types de conflits](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflicttypes).
## Journalisation des conflits
pgactivelink journalise les incidents de conflit dans la table `pgactive.pgactive_conflict_history` pour vous aider à diagnostiquer et à gérer les conflits active-active. La journalisation des conflits dans cette table ne se produit que lorsque vous définissez `pgactive.log_conflicts_to_table` sur la valeur true. L’extension pgactive journalise également les conflits dans le fichier journal de PostgreSQL lorsque log\$1min\$1messages est défini sur `LOG` ou `lower`, quel que soit le paramètre `pgactive.log_conflicts_to_table`.
Utilisez la table d’historique des conflits pour :
+ Mesurer la fréquence à laquelle votre application crée des conflits
+ Identifier les endroits où les conflits se produisent
+ Améliorer votre application pour réduire les taux de conflit
+ Détecter les cas où la résolution des conflits ne produit pas les résultats souhaités
+ Déterminer où vous avez besoin de déclencheurs de conflits définis par l’utilisateur ou de modifications de la conception de l’application
Pour les conflits de lignes, vous pouvez éventuellement journaliser les valeurs des lignes. Ceci est contrôlé par le paramètre `pgactive.log_conflicts_to_table`. Remarque :
+ Il s’agit d’une option à l’échelle de la base de données globale
+ Il n’y a aucun contrôle par table sur la journalisation des valeurs des lignes
+ Aucune limite n’est appliquée aux numéros de champs, aux éléments du tableau ou à la longueur des champs
+ L’activation de cette fonctionnalité peut être déconseillée si vous utilisez des lignes de plusieurs mégaoctets susceptibles de déclencher des conflits
Étant donné que la table d’historique des conflits contient les données de chaque table de la base de données (chacune avec des schémas potentiellement différents), les valeurs des lignes journalisées sont stockées sous forme de champs JSON. Le JSON est créé en utilisant `row_to_json`, comme si vous l’appeliez directement depuis SQL. PostgreSQL ne fournit pas de fonction, vous aurez donc besoin `json_to_row` d'un code spécifique à la table (PL/pgSQL, PL/Python, PL/Perlin, etc.) pour reconstruire un tuple de type composite à partir du JSON enregistré.
**Note**
La prise en charge des conflits définis par l’utilisateur est prévue dans le cadre d’une future fonctionnalité d’extension.
# Présentation des schémas pgactive
Le schéma pgactive gère la réplication active-active dans RDS pour PostgreSQL. Ce schéma contient des tables qui stockent les informations de configuration et d’état de la réplication.
**Note**
Le schéma pgactive est en évolution et sujet à modifications. Ne modifiez pas directement les données de ces tables.
Les tables clés du schéma pgactive sont les suivantes :
+ `pgactive_nodes` : stocke les informations relatives aux nœuds du groupe de réplication active-active.
+ `pgactive_connections` : stocke les détails de connexion pour chaque nœud.
## pgactive\$1nodes
Le pgactive\$1nodes stocke des informations sur les nœuds participant au groupe de réplication active-active.
| Colonne | Type | Classement (Collation) | Nullable | Par défaut |
| --- | --- | --- | --- | --- |
| node\$1sysid | text | – | not null | – |
| node\$1timeline | oid | – | not null | – |
| node\$1dboid | oid | – | not null | – |
| node\$1status | char | – | not null | – |
| node\$1name | text | – | not null | – |
| node\$1dsn | text | – | not null | – |
| node\$1init\$1from\$1dsn | text | – | not null | – |
| node\$1read\$1only | boolean | – | – | false |
| node\$1seq\$1id | smallint | – | not null | – |
**node\$1sysid**
ID unique pour un nœud, généré pendant `pgactive_create_group` ou `pgactive_join_group`
**node\$1status**
État de préparation du nœud :
+ **b** : début de la configuration
+ **i** : initialisation
+ **c** : rattrapage
+ **o** : création d’emplacements sortants
+ **r** : prêt
+ **k** : tué
Cette colonne n’indique pas si un nœud est connecté ou déconnecté.
**node\$1name**
Nom de nœud unique fourni par l’utilisateur.
**node\$1dsn**
Chaîne de connexion ou nom de mappage utilisateur
**node\$1init\$1from\$1dsn**
DSN à partir duquel ce nœud a été créé.
## pgactive\$1connection
Le pgactive\$1connections stocke les détails de connexion pour chaque nœud.
| Colonne | Type | Classement (Collation) | Nullable | Par défaut |
| --- | --- | --- | --- | --- |
| conn\$1sysid | text | Aucune | not null | Aucune |
| conn\$1timeline | oid | Aucune | not null | Aucune |
| conn\$1dboid | oid | Aucune | not null | Aucune |
| conn\$1dsn | text | Aucune | not null | Aucune |
| conn\$1apply\$1delay | entier | Aucune | none | none |
| conn\$1replication\$1sets | text | Aucune | none | none |
conn\$1sysid
Identifiant de nœud pour le nœud auquel cette entrée fait référence.
conn\$1dsn
Identique à pgactive.pgactive\$1nodes `node_dsn`.
conn\$1apply\$1delay
Si cette option est définie, il faut attendre quelques millisecondes avant d’appliquer chaque transaction depuis le nœud distant. Principalement pour le débogage. Si la valeur est nulle, la valeur globale par défaut s’applique.
## Utilisation des ensembles de réplication
Les ensembles de réplication déterminent les tables à inclure ou à exclure des opérations de réplication. Par défaut, toutes les tables sont répliquées sauf indication contraire à l’aide des fonctions suivantes :
+ `pgactive_exclude_table_replication_set()` : exclut les tables spécifiées de la réplication
+ `pgactive_include_table_replication_set()` : inclut les tables spécifiées dans la réplication
**Note**
Avant de configurer des ensembles de réplication, tenez compte des éléments suivants :
Vous pouvez configurer l’inclusion ou l’exclusion de tables uniquement après l’exécution de `pgactive_create_group()`, mais avant `pgactive_join_group()`.
Une fois que vous avez utilisé `pgactive_exclude_table_replication_set()`, vous ne pouvez plus utiliser `pgactive_include_table_replication_set()`.
Une fois que vous avez utilisé `pgactive_include_table_replication_set()`, vous ne pouvez plus utiliser `pgactive_exclude_table_replication_set()`.
Le système gère les tables nouvellement créées différemment en fonction de votre configuration initiale :
+ Si vous avez exclu des tables : toutes les nouvelles tables créées après `pgactive_join_group()` sont automatiquement incluses dans la réplication
+ Si vous avez inclus des tables : toutes les nouvelles tables créées après `pgactive_join_group()` sont automatiquement exclues de la réplication.
Pour afficher la configuration de l’ensemble de réplication pour une table spécifique, utilisez la fonction `pgactive.pgactive_get_table_replication_sets()`.
# Référence des fonctions pgactive
Vous trouverez ci-dessous la liste des fonctions pgactive avec leurs paramètres, leurs valeurs renvoyées et leurs notes d’utilisation pratiques pour vous aider à les utiliser efficacement :
## get\$1last\$1applied\$1xact\$1info
Récupère les dernières informations de transaction appliquées pour un nœud spécifié.
**Arguments**
+ sysid (texte) : OID de chronologie
+ dboid (OID)
**Type de retour**
Elle exécute les opérations suivantes :
+ last\$1applied\$1xact\$1id (OID)
+ last\$1applied\$1xact\$1committs (horodatage avec fuseau horaire)
+ last\$1applied\$1xact\$1at (horodatage avec fuseau horaire)
**Notes d’utilisation**
Utilisez cette fonction pour récupérer les dernières informations de transaction appliquées pour un nœud spécifié.
## pgactive\$1apply\$1pause
Suspend le processus d’application de la réplication.
**Arguments**
Aucun
**Type de retour**
booléen
**Notes d’utilisation**
Appelez cette fonction pour suspendre le processus d’application de la réplication.
## pgactive\$1apply\$1resume
Reprend le processus d’application de la réplication.
**Arguments**
Aucun
**Type de retour**
void
**Notes d’utilisation**
Appelez cette fonction pour reprendre le processus d’application de la réplication.
## pgactive\$1is\$1apply\$1paused
Vérifie si l’application de réplication est actuellement en pause.
**Arguments**
Aucun
**Type de retour**
booléen
**Notes d’utilisation**
Utilisez cette fonction pour vérifier si l’application de réplication est actuellement en pause.
## pgactive\$1create\$1group
Crée un groupe pgactive en convertissant une base de données autonome en nœud initial.
**Arguments**
+ node\$1name (texte)
+ node\$1dsn (texte)
+ apply\$1delay integer DEFAULT NULL::integer - replication\$1sets text[] DEFAULT ARRAY[‘default’::text]
**Type de retour**
void
**Notes d’utilisation**
Crée un groupe pgactive en convertissant une base de données autonome en nœud initial. La fonction effectue des vérifications d’intégrité avant de transformer le nœud en nœud pgactive. Avant d’utiliser cette fonction, assurez-vous que votre cluster PostgreSQL possède suffisamment de `max_worker_processes` disponibles pour prendre en charge les travailleurs en arrière-plan pgactive.
## pgactive\$1detach\$1nodes
Supprime les nœuds spécifiés du groupe pgactive.
**Arguments**
+ p\$1nodes (text[])
**Type de retour**
void
**Notes d’utilisation**
Utilisez cette fonction pour supprimer les nœuds spécifiés du groupe pgactive.
## pgactive\$1exclude\$1table\$1replication\$1set
Exclut une table spécifique de la réplication.
**Arguments**
+ p\$1relation (regclass)
**Type de retour**
void
**Notes d’utilisation**
Utilisez cette fonction pour exclure une table spécifique de la réplication.
## pgactive\$1get\$1replication\$1lag\$1info
Récupère des informations détaillées sur le délai de réplication, notamment les détails du nœud, l’état du WAL et les valeurs LSN.
**Arguments**
Aucun
**Type de retour**
SETOF record - node\$1name text - node\$1sysid text - application\$1name text - slot\$1name text - active boolean - active\$1pid integer - pending\$1wal\$1decoding bigint - Taille approximative du WAL en octets à décoder sur le nœud expéditeur - pending\$1wal\$1to\$1apply bigint - Taille approximative du WAL en octets à appliquer sur le nœud récepteur - restart\$1lsn pg\$1lsn - confirmed\$1flush\$1lsn pg\$1lsn - sent\$1lsn pg\$1lsn - write\$1lsn pg\$1lsn - flush\$1lsn pg\$1lsn - replay\$1lsn pg\$1lsn
**Notes d’utilisation**
Appelez cette fonction pour récupérer des informations sur le délai de réplication, notamment les détails du nœud, l’état du WAL et les valeurs LSN.
## pgactive\$1get\$1stats
Récupère les statistiques de réplication pgactive.
**Arguments**
Aucun
**Type de retour**
SETOF record - rep\$1node\$1id oid - rilocalid oid - riremoteid text - nr\$1commit bigint - nr\$1rollback bigint - nr\$1insert bigint - nr\$1insert\$1conflict bigint - nr\$1update bigint - nr\$1update\$1conflict bigint - nr\$1delete bigint - nr\$1delete\$1conflict bigint - nr\$1disconnect bigint
**Notes d’utilisation**
Utilisez cette fonction pour récupérer les statistiques de réplication de pgactive.
## pgactive\$1get\$1table\$1replication\$1sets
Obtient la configuration d’un ensemble de réplication d’une relation spécifique.
**Arguments**
+ relation (regclass)
**Type de retour**
Registre SETOF
**Notes d’utilisation**
Appelez cette fonction pour obtenir la configuration de l’ensemble de réplication pour une relation spécifique.
## pgactive\$1include\$1table\$1replication\$1set
Inclut une table spécifique dans la réplication.
**Arguments**
+ p\$1relation (regclass)
**Type de retour**
void
**Notes d’utilisation**
Utilisez cette fonction pour inclure une table spécifique dans la réplication.
## pgactive\$1join\$1group
Ajoute un nœud à un groupe pgactive existant.
**Arguments**
+ node\$1name (texte)
+ node\$1dsn (texte)
+ join\$1using\$1dsn (texte)
+ apply\$1delay (entier, facultatif)
+ replication\$1sets (text[], valeur par défaut : [’default’])
+ bypass\$1collation\$1check (booléen, valeur par défaut : false)
+ bypass\$1node\$1identifier\$1creation (booléen, valeur par défaut : false)
+ bypass\$1user\$1tables\$1check (booléen, valeur par défaut : false)
**Type de retour**
void
**Notes d’utilisation**
Appelez cette fonction pour ajouter un nœud à un groupe pgactive existant. Assurez-vous que votre cluster PostgreSQL a une valeur max\$1worker\$1processes suffisante pour les application de travail en arrière-plan de pgactive.
## pgactive\$1remove
Supprime tous les composants pgactive du nœud local.
**Arguments**
+ force (booléen, valeur par défaut : false)
**Type de retour**
void
**Notes d’utilisation**
Appelez cette fonction pour supprimer tous les composants pgactive du nœud local.
## pgactive\$1snowflake\$1id\$1nextval
Génère des valeurs de séquence uniques spécifiques au nœud.
**Arguments**
+ regclass
**Type de retour**
bigint
**Notes d’utilisation**
Utilisez cette fonction pour générer des valeurs de séquence uniques spécifiques au nœud.
## pgactive\$1update\$1node\$1conninfo
Met à jour les informations de connexion pour un nœud pgactive.
**Arguments**
+ node\$1name\$1to\$1update (texte)
+ node\$1dsn\$1to\$1update (texte)
**Type de retour**
void
**Notes d’utilisation**
Utilisez cette fonction pour mettre à jour les informations de connexion d’un nœud pgactive.
## pgactive\$1wait\$1for\$1node\$1ready
Surveille la progression des opérations de création ou d’association de groupes.
**Arguments**
+ timeout (entier, valeur par défaut : 0)
+ progress\$1interval (entier, valeur par défaut : 60)
**Type de retour**
void
**Notes d’utilisation**
Appelez cette fonction pour suivre la progression des opérations de création ou d’association de groupes.
# Gestion des conflits de la réplication active-active
L'extension `pgactive` fonctionne par base de données et non par cluster. Chaque instance de base de données qui utilise `pgactive` est une instance indépendante et peut accepter les modifications de données de n'importe quelle source. Lorsqu'une modification est envoyée à une instance de base de données, PostgreSQL la valide localement, puis utilise `pgactive` pour répliquer la modification de manière asynchrone sur les autres instances de base de données. Lorsque deux instances de base de données PostgreSQL mettent à jour le même enregistrement à peu près au même moment, un conflit peut survenir.
L'extension `pgactive` propose des mécanismes de détection et de résolution automatique des conflits. Il suit l'horodatage du moment où la transaction a été validée sur les deux instances de base de données et applique automatiquement la modification avec l'horodatage le plus récent. L'extension `pgactive` journalise également la survenance d'un conflit dans la table `pgactive.pgactive_conflict_history`.
Le `pgactive.pgactive_conflict_history` continue de croître. Vous souhaiterez peut-être définir une politique de purge. Cela peut être fait en supprimant régulièrement certains enregistrements ou en définissant un schéma de partitionnement pour cette relation (puis en détachant, supprimant, tronquant les partitions qui vous intéressent). Pour mettre en œuvre régulièrement la politique de purge, l’une des options consiste à utiliser l’extension `pg_cron`. Consultez les informations suivantes concernant un exemple de table d’historique`pg_cron`, [Planification de la maintenance avec l’extension pg\$1cron PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html).
# Gestion des séquences dans une réplication active-active
Une instance de base de données RDS for PostgreSQL dotée de l'extension `pgactive` utilise deux mécanismes de séquence différents pour générer des valeurs uniques.
**Séquences globales**
Pour utiliser une séquence globale, créez une séquence locale avec l'instruction `CREATE SEQUENCE`. Utilisez `pgactive.pgactive_snowflake_id_nextval(seqname)` plutôt que `usingnextval(seqname)` pour obtenir la prochaine valeur unique de la séquence.
L'exemple suivant crée une séquence globale :
```
app=> CREATE TABLE gstest (
id bigint primary key,
parrot text
);
```
```
app=>CREATE SEQUENCE gstest_id_seq OWNED BY gstest.id;
```
```
app=> ALTER TABLE gstest \
ALTER COLUMN id SET DEFAULT \
pgactive.pgactive_snowflake_id_nextval('gstest_id_seq');
```
**Séquences partitionnées**
Dans les séquences fractionnées ou partitionnées, une séquence PostgreSQL normale est utilisée sur chaque nœud. Chaque séquence s'incrémente de la même valeur et débute à des décalages différents. Par exemple, avec un pas de 100, le nœud 1 génère la séquence 101, 201, 301, etc. et le nœud 2 génère la séquence 102, 202, 302, etc. Ce mécanisme fonctionne bien même si les nœuds ne peuvent pas communiquer pendant de longues périodes. Cependant, il impose au concepteur de spécifier un nombre maximal de nœuds au moment d'établir le schéma et nécessite une configuration par nœud. Les erreurs peuvent facilement engendrer un chevauchement de séquences.
Il est relativement simple de configurer cette approche avec `pgactive` en créant la séquence souhaitée sur un nœud comme suit :
```
CREATE TABLE some_table (generated_value bigint primary key);
```
```
app=> CREATE SEQUENCE some_seq INCREMENT 100 OWNED BY some_table.generated_value;
```
```
app=> ALTER TABLE some_table ALTER COLUMN generated_value SET DEFAULT nextval('some_seq');
```
Appelez ensuite `setval` sur chaque nœud pour donner une valeur de départ de décalage différente comme suit.
```
app=>
-- On node 1
SELECT setval('some_seq', 1);
-- On node 2
SELECT setval('some_seq', 2);
```
# Réduction du gonflement des tables et des index avec l’extension pg\$1repack
Vous pouvez utiliser l’extension `pg_repack` pour éliminer le gonflement des tables et des index comme alternative à `VACUUM FULL`. Cette extension est prise en charge sur RDS pour PostgreSQL versions 9.6.3 et ultérieures. Pour plus d'informations sur l'`pg_repack`extension et le réemballage complet de la table, consultez la [documentation du GitHub projet](https://reorg.github.io/pg_repack/).
Contrairement à cela`VACUUM FULL`, l'`pg_repack`extension ne nécessite un lock exclusif (AccessExclusiveLock) que pendant une courte période lors de l'opération de reconstruction de la table dans les cas suivants :
+ Création initiale de la table de journal : une table de journal est créée pour enregistrer les modifications survenues lors de la copie initiale des données, comme indiqué dans l’exemple suivant :
```
postgres=>\dt+ repack.log_*
List of relations
-[ RECORD 1 ]-+----------
Schema | repack
Name | log_16490
Type | table
Owner | postgres
Persistence | permanent
Access method | heap
Size | 65 MB
Description |
```
+ swap-and-dropPhase finale.
Pour le reste de l’opération de reconstruction, il suffit d’un verrou `ACCESS SHARE` sur la table d’origine pour copier des lignes de celle-ci vers la nouvelle table. Cela permet aux opérations INSERT, UPDATE et DELETE de se dérouler comme d’habitude.
## Recommandations
Les recommandations suivantes s’appliquent lorsque vous supprimez le gonflement des tables et des index à l’aide de l’extension `pg_repack` :
+ Effectuez le reconditionnement en dehors des heures ouvrables ou pendant une fenêtre de maintenance afin de minimiser son impact sur les performances des autres activités de base de données.
+ Surveillez de près les sessions bloquantes pendant l'activité de reconstruction et assurez-vous qu'aucune activité sur la table d'origine ne risque de bloquer`pg_repack`, en particulier pendant la swap-and-drop phase finale lorsqu'un verrouillage exclusif de la table d'origine est nécessaire. Pour plus d’informations, consultez [Identification de ce qui bloque une requête](https://repost.aws/knowledge-center/rds-aurora-postgresql-query-blocked).
Lorsque vous rencontrez une session bloquante, vous pouvez y mettre fin à l’aide de la commande suivante après un examen attentif. Cela permet la poursuite de `pg_repack` pour terminer la reconstruction :
```
SELECT pg_terminate_backend(pid);
```
+ Lors de l’application des modifications accumulées à partir de la table de journal `pg_repack's` sur des systèmes présentant un taux de transactions très élevé, le processus d’application risque de ne pas être en mesure de suivre le rythme des modifications. Dans de tels cas, `pg_repack` ne serait pas en mesure de terminer le processus d’application. Pour de plus amples informations, veuillez consulter [Surveillance de la nouvelle table lors du reconditionnement](#Appendix.PostgreSQL.CommonDBATasks.pg_repack.Monitoring). Si les index sont très gonflés, une autre solution consiste à effectuer un reconditionnement des index uniquement. Cela permet également aux cycles de nettoyage des index du VACUUM de se terminer plus rapidement.
Vous pouvez ignorer la phase de nettoyage de l’index à l’aide du VACUUM manuel de PostgreSQL version 12, et elle est automatiquement ignorée lors de l’autovacuum d’urgence à partir de PostgreSQL version 14. Cela permet au VACUUM de se terminer plus rapidement sans supprimer le gonflement de l’index et cette solution est uniquement destinée aux situations d’urgence, telles que la prévention du VACUUM de bouclage. Pour plus d’informations, consultez [Prévention du gonflement dans les index](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html#AuroraPostgreSQL.diag-table-ind-bloat.AvoidinginIndexes) dans le Guide de l’utilisateur Amazon Aurora.
## Conditions préalables
+ La table doit avoir une contrainte PRIMARY KEY ou UNIQUE non nulle.
+ La version de l’extension doit être la même pour le client et le serveur.
+ Assurez-vous que l’instance RDS a plus de `FreeStorageSpace` que la taille totale de la table sans le gonflement. Par exemple, considérez que la taille totale de la table, y compris TOAST et les index, est de 2 To, et que le gonflement total de la table est de 1 To. La valeur de `FreeStorageSpace` requise doit être supérieure à la valeur renvoyée par le calcul suivant :
`2TB (Table size)` - `1TB (Table bloat)` = `1TB`
Vous pouvez utiliser la requête suivante pour vérifier la taille totale de la table et utiliser `pgstattuple` pour en déduire le gonflement. Pour plus d’informations, consultez [Diagnostic du gonflement de la table et de l’index](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html) dans le Guide de l’utilisateur Amazon Aurora.
```
SELECT pg_size_pretty(pg_total_relation_size('table_name')) AS total_table_size;
```
Cet espace est récupéré une fois l’activité terminée.
+ Assurez-vous que l’instance RDS dispose d’une capacité de calcul et d’E/S suffisante pour gérer l’opération de reconditionnement. Vous pouvez envisager d’augmenter verticalement la classe d’instance pour un équilibre optimal des performances.
**Pour utiliser l’extension `pg_repack`**
1. Installez l’extension `pg_repack` sur votre instance de base de données RDS pour PostgreSQL en exécutant la commande suivante.
```
CREATE EXTENSION pg_repack;
```
1. Exécutez les commandes suivantes pour accorder l’accès en écriture aux tables de journal temporaires créées par `pg_repack`.
```
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT INSERT ON TABLES TO PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT USAGE, SELECT ON SEQUENCES TO PUBLIC;
```
1. Connectez-vous à la base de données à l’aide de l’utilitaire client `pg_repack`. Utilisez un compte qui possède les privilèges `rds_superuser`. Par exemple, supposons que le rôle `rds_test` a les privilèges `rds_superuser`. La syntaxe suivante effectue une opération `pg_repack` pour les tables complètes, y compris tous les index de table de la base de données `postgres`.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test -k postgres
```
**Note**
Vous devez vous connecter à l’aide de l’option -k. L’option -a n’est pas prise en charge.
La réponse du client `pg_repack` fournit des informations sur les tables de l’instance de base de données qui sont reconditionnées.
```
INFO: repacking table "pgbench_tellers"
INFO: repacking table "pgbench_accounts"
INFO: repacking table "pgbench_branches"
```
1. La syntaxe suivante reconditionne une seule table `orders` qui inclut les index de la base de données `postgres`.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders -k postgres
```
La syntaxe suivante reconditionne uniquement les index de la table `orders` dans la base de données `postgres`.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders --only-indexes -k postgres
```
## Surveillance de la nouvelle table lors du reconditionnement
+ La taille de la base de données est augmentée de la taille totale de la table moins le surchargement, jusqu'à la swap-and-drop phase de reconditionnement. Vous pouvez surveiller le taux de croissance de la taille de la base de données, calculer la vitesse du reconditionnement et estimer approximativement le temps nécessaire pour terminer le transfert de données initial.
Par exemple, considérez que la taille totale de la table est de 2 To, la taille de la base de données de 4 To et le gonflement total de la table de 1 To. La valeur de taille totale de la base de données renvoyée par le calcul à la fin de l’opération de reconditionnement est la suivante :
`2TB (Table size)` \$1 `4 TB (Database size)` - `1TB (Table bloat)` = `5TB`
Vous pouvez estimer approximativement la vitesse de l’opération de reconditionnement en échantillonnant le taux de croissance en octets entre deux points dans le temps. Si le taux de croissance est de 1 Go par minute, l’opération initiale de création de table peut prendre environ 1 000 minutes ou 16,6 heures. Outre la création initiale de la table, `pg_repack` doit également appliquer les modifications accumulées. Le temps nécessaire dépend du taux d’application des modifications en cours et des modifications accumulées.
**Note**
Vous pouvez utiliser l’extension `pgstattuple` pour calculer le gonflement dans la table. Pour plus d’informations, consultez [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html).
+ Le nombre de lignes de la table de journal `pg_repack's`, sous le schéma de reconditionnement, représente le volume de modifications en attente d’être appliquées à la nouvelle table après le chargement initial.
Vous pouvez consulter la table de journal `pg_repack's` dans `pg_stat_all_tables` pour surveiller les modifications appliquées à la nouvelle table. `pg_stat_all_tables.n_live_tup` indique le nombre d’enregistrements en attente d’être appliqués à la nouvelle table. Pour plus d’informations, consultez [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW).
```
postgres=>SELECT relname,n_live_tup FROM pg_stat_all_tables WHERE schemaname = 'repack' AND relname ILIKE '%log%';
-[ RECORD 1 ]---------
relname | log_16490
n_live_tup | 2000000
```
+ Vous pouvez utiliser l’extension `pg_stat_statements` pour connaître le temps nécessaire à chaque étape de l’opération de reconditionnement. Cela est utile pour préparer l’application de la même opération de reconditionnement dans un environnement de production. Vous pouvez ajuster la clause `LIMIT` pour étendre davantage la sortie.
```
postgres=>SELECT
SUBSTR(query, 1, 100) query,
round((round(total_exec_time::numeric, 6) / 1000 / 60),4) total_exec_time_in_minutes
FROM
pg_stat_statements
WHERE
query ILIKE '%repack%'
ORDER BY
total_exec_time DESC LIMIT 5;
query | total_exec_time_in_minutes
-----------------------------------------------------------------------+----------------------------
CREATE UNIQUE INDEX index_16493 ON repack.table_16490 USING btree (a) | 6.8627
INSERT INTO repack.table_16490 SELECT a FROM ONLY public.t1 | 6.4150
SELECT repack.repack_apply($1, $2, $3, $4, $5, $6) | 0.5395
SELECT repack.repack_drop($1, $2) | 0.0004
SELECT repack.repack_swap($1) | 0.0004
(5 rows)
```
Le reconditionnement est une out-of-place opération complète, de sorte que la table d'origine n'est pas affectée et nous ne prévoyons aucun problème inattendu nécessitant la restauration de la table d'origine. Si le reconditionnement échoue de façon inattendue, vous devez rechercher la cause de l’erreur et la résoudre.
Une fois le problème résolu, supprimez et recréez l’extension `pg_repack` dans la base de données où se trouve la table, puis recommencez l’étape `pg_repack`. En outre, la disponibilité des ressources informatiques et l’accessibilité simultanée de la table jouent un rôle crucial dans la réalisation en temps voulu de l’opération de reconditionnement.
# Mise à niveau et utilisation de l' PLV8 extension
PLV8 est une extension de langage Javascript fiable pour PostgreSQL. Vous pouvez l'utiliser pour des procédures stockées, des déclencheurs et tout autre code procédural pouvant être appelé depuis SQL. Cette extension de langage est prise en charge par toutes les versions actuelles de PostgreSQL.
Si vous utilisez [PLV8](https://plv8.github.io/)et mettez à niveau PostgreSQL vers une PLV8 nouvelle version, vous profitez immédiatement de la nouvelle extension. Procédez comme suit pour synchroniser les métadonnées de votre catalogue avec la nouvelle version de PLV8. Ces étapes sont facultatives, mais nous vous recommandons vivement de les compléter afin d'éviter des avertissements de décalage des métadonnées.
Le processus de mise à niveau supprime toutes vos PLV8 fonctions existantes. Nous vous recommandons donc de créer un instantané de votre instance de base de données RDS pour PostgreSQL avant la mise à niveau. Pour de plus amples informations, veuillez consulter [Création d’un instantané de base de données pour une instance de base de données mono-AZ pour Amazon RDS](USER_CreateSnapshot.md).
**Important**
À partir de la version 18 de PostgreSQL, Amazon RDS pour PostgreSQL rendra obsolètes les extensions PostgreSQL `plcoffee` et `plls`. Nous vous recommandons de cesser d'utiliser CoffeeScript et LiveScript dans vos applications afin de disposer d'un chemin de mise à niveau pour les futures mises à niveau des versions du moteur.
**Pour synchroniser les métadonnées de votre catalogue avec une nouvelle version de PLV8**
1. Vérifiez que vous devez mettre à jour. Pour ce faire, exécutez la commande suivante tout en étant connecté à votre instance.
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
Si les résultats contiennent des valeurs pour une version installée avec un numéro inférieur à celui de la version par défaut, poursuivez cette procédure pour mettre à jour vos extensions. Par exemple, l'ensemble de résultats suivant indique que vous devez procéder à la mise à jour.
```
name | default_version | installed_version | comment
--------+-----------------+-------------------+--------------------------------------------------
plls | 2.1.0 | 1.5.3 | PL/LiveScript (v8) trusted procedural language
plcoffee| 2.1.0 | 1.5.3 | PL/CoffeeScript (v8) trusted procedural language
plv8 | 2.1.0 | 1.5.3 | PL/JavaScript (v8) trusted procedural language
(3 rows)
```
1. Créez un instantané de votre instance de base de données RDS pour PostgreSQL si vous ne l’avez pas encore fait. Vous pouvez poursuivre avec les étapes suivantes tandis que l'instantané est en cours de création.
1. Déterminez le nombre de PLV8 fonctions de votre instance de base de données afin de vérifier qu'elles sont toutes en place après la mise à niveau. Par exemple, la requête SQL suivante renvoie le nombre de fonctions écrites en pvl8, plcoffee et plls.
```
SELECT proname, nspname, lanname
FROM pg_proc p, pg_language l, pg_namespace n
WHERE p.prolang = l.oid
AND n.oid = p.pronamespace
AND lanname IN ('plv8','plcoffee','plls');
```
1. Utiliser pg\$1dump pour créer un fichier de vidage schema-only. Par exemple, créez un fichier sur votre ordinateur client dans le répertoire `/tmp`.
```
./pg_dump -Fc --schema-only -U master postgres >/tmp/test.dmp
```
Cet exemple utilise les options suivantes :
+ `-Fc` : format personnalisé
+ --schema-only : supprime uniquement les commandes nécessaires à la création du schéma (les fonctions dans ce cas)
+ `-U` : le nom de l'utilisateur principal RDS
+ `database` : le nom de base de données dans votre instance de base de données
Pour plus d’informations sur pg\$1dump, consultez [pg\$1dump](https://www.postgresql.org/docs/current/static/app-pgdump.html ) de la documentation PostgreSQL.
1. Extrayez la déclaration DDL « CREATE FUNCTION » présente dans le fichier de vidage. L'exemple suivant utilise la commande `grep` pour extraire l'instruction DDL qui crée les fonctions et les enregistre dans un fichier. Vous l'utiliserez dans les étapes suivantes pour recréer les fonctions.
```
./pg_restore -l /tmp/test.dmp | grep FUNCTION > /tmp/function_list
```
Pour plus d’informations sur pg\$1restore, consultez [pg\$1restore](https://www.postgresql.org/docs/current/static/app-pgrestore.html) de la documentation PostgreSQL.
1. Supprimez les fonctions et les extensions. L'exemple suivant supprime tous les objets PLV8 basés. L'option cascade garantit que les objets dépendants sont supprimés.
```
DROP EXTENSION plv8 CASCADE;
```
Si votre instance PostgreSQL contient des objets basés sur plcoffee ou plls, répétez l'étape pour ces extensions.
1. Créez les extensions. L'exemple suivant crée les extensions plv8, plcoffee et plls.
```
CREATE EXTENSION plv8;
CREATE EXTENSION plcoffee;
CREATE EXTENSION plls;
```
1. Créez les fonctions à l'aide du fichier de vidage et du fichier « pilote ».
L'exemple suivant recrée les fonctions que vous avez extraites précédemment.
```
./pg_restore -U master -d postgres -Fc -L /tmp/function_list /tmp/test.dmp
```
1. Vérifiez que toutes vos fonctions ont été recréées à l'aide de la requête suivante.
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
La PLV8 version 2 ajoute la ligne supplémentaire suivante à votre jeu de résultats :
```
proname | nspname | lanname
---------------+------------+----------
plv8_version | pg_catalog | plv8
```
# Utilisation PL/Rust pour écrire des fonctions PostgreSQL dans le langage Rust
PL/Rust is a trusted Rust language extension for PostgreSQL. You can use it for stored procedures, functions, and other procedural code that's callable from SQL. The PL/Rustl'extension de langue est disponible dans les versions suivantes :
+ RDS pour PostgreSQL 17.1 et versions 17 ultérieures
+ RDS pour PostgreSQL 16.1 et versions 16 ultérieures
+ RDS pour PostgreSQL 15.2-R2 et versions 15 ultérieures
+ RDS pour PostgreSQL 14.9 et versions 14 ultérieures
+ RDS pour PostgreSQL 13.12 et versions 13 ultérieures
Pour plus d'informations, voir [PL/Rust](https://github.com/tcdi/plrust#readme) on. GitHub
**Topics**
+ [
## Configuration de PL/Rust
](#PL_Rust-setting-up)
+ [
## Création de fonctions avec PL/Rust
](#PL_Rust-create-function)
+ [
## Utilisation de caisses avec PL/Rust
](#PL_Rust-crates)
+ [
## Limites de PL/Rust
](#PL_Rust-limitations)
## Configuration de PL/Rust
Pour installer l'extension plrust sur votre instance de base de données, ajoutez plrust au paramètre `shared_preload_libraries` dans le groupe de paramètres de la base de données associé à votre instance de base de données. Une fois l'extension plrust installée, vous pouvez créer des fonctions.
Pour modifier le paramètre `shared_preload_libraries`, votre instance de base de données doit être associée à un groupe de paramètres personnalisé. Pour obtenir des informations sur la création d'un groupe de paramètres de base de données personnalisé, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Vous pouvez installer l'extension plrust en utilisant le AWS Management Console ou le AWS CLI.
Les étapes suivantes supposent que votre instance de base de données est associée à un groupe de paramètres de cluster de bases de données personnalisé.
### Console
**Installer l'extension plrust dans le paramètre `shared_preload_libraries`**
Effectuez les étapes suivantes à l’aide d’un compte membre du groupe (rôle) `rds_superuser`.
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 **Databases (Bases de données)**.
1. Choisissez le nom de votre instance de base de données pour afficher ses détails.
1. Ouvrez l'onglet **Configuration** de votre instance de base de données et recherchez le lien du groupe de paramètres de l'instance de base de données.
1. Cliquez sur le lien pour ouvrir les paramètres personnalisés associés à votre instance de base de données.
1. Dans le champ de recherche **Parameters** (Paramètres), tapez `shared_pre` pour trouver le paramètre **`shared_preload_libraries`**.
1. Choisissez **Edit parameters** (Modifier les paramètres) pour accéder aux valeurs des propriétés.
1. Ajoutez plrust à la liste dans le champ **Valeurs**. Utilisez une virgule pour séparer les éléments de la liste de valeurs.
1. Redémarrez l'instance de base de données pour que la modification apportée au paramètre `shared_preload_libraries` prenne effet. Le redémarrage initial peut nécessiter plus de temps.
1. Lorsque l'instance est disponible, vérifiez que plrust a été initialisé. Utilisez `psql` pour vous connecter à l'instance de base de données, puis exécutez la commande suivante.
```
SHOW shared_preload_libraries;
```
Votre sortie doit ressembler à ce qui suit :
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
### AWS CLI
**Installez l'extension plrust dans le paramètre shared\$1preload\$1libraries**
Effectuez les étapes suivantes à l'aide d'un compte membre du groupe (rôle) `rds_superuser`.
1. Utilisez la [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI commande pour ajouter plrust au `shared_preload_libraries` paramètre.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=plrust,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilisez la [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance) AWS CLI commande pour redémarrer l'instance de base de données et initialiser la bibliothèque plrust. Le redémarrage initial peut nécessiter plus de temps.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Lorsque l'instance est disponible, vous pouvez vérifier que plrust a été initialisé. Utilisez `psql` pour vous connecter à l'instance de base de données, puis exécutez la commande suivante.
```
SHOW shared_preload_libraries;
```
Votre sortie doit ressembler à ce qui suit :
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
## Création de fonctions avec PL/Rust
PL/Rust compile la fonction sous forme de bibliothèque dynamique, la charger et l'exécute.
La fonction Rust suivante filtre les multiples d'un tableau.
```
postgres=> CREATE LANGUAGE plrust;
CREATE EXTENSION
```
```
CREATE OR REPLACE FUNCTION filter_multiples(a BIGINT[], multiple BIGINT) RETURNS BIGINT[]
IMMUTABLE STRICT
LANGUAGE PLRUST AS
$$
Ok(Some(a.into_iter().filter(|x| x.unwrap() % multiple != 0).collect()))
$$;
WITH gen_values AS (
SELECT ARRAY(SELECT * FROM generate_series(1,100)) as arr)
SELECT filter_multiples(arr, 3)
from gen_values;
```
## Utilisation de caisses avec PL/Rust
Dans RDS pour PostgreSQL versions 16.3-R2 et supérieures, 15.7-R2 et versions supérieures 15 versions, 14.12-R2 et versions supérieures 14 versions, et 13.15-R2 et versions supérieures 13 versions, prend en charge des caisses supplémentaires : PL/Rust
+ `url`
+ `regex`
+ `serde`
+ `serde_json`
Dans RDS pour PostgreSQL versions 15.5-R2 et supérieures, 14.10-R2 et versions 14 et versions 13.13-R2 et supérieures 13 versions, prend en charge deux caisses supplémentaires : PL/Rust
+ `croaring-rs`
+ `num-bigint`
À partir des versions 15.4, 14.9 et 13.12 d'Amazon RDS for PostgreSQL, les caisses suivantes sont prises en charge : PL/Rust
+ `aes`
+ `ctr`
+ `rand`
Seules les fonctionnalités par défaut sont prises en charge pour ces caisses. Les nouvelles versions de RDS pour PostgreSQL peuvent contenir des versions mises à jour de caisses, et les anciennes versions de caisses peuvent ne plus être prises en charge.
Suivez les meilleures pratiques pour effectuer une mise à niveau de version majeure afin de vérifier si vos PL/Rust fonctions sont compatibles avec la nouvelle version majeure. Pour plus d'informations, consultez le blog [Bonnes pratiques pour la mise à niveau d'Amazon RDS vers les versions majeures et mineures de PostgreSQL](https://aws.amazon.com/blogs/database/best-practices-for-upgrading-amazon-rds-to-major-and-minor-versions-of-postgresql/) (langue française non garantie) et [Mise à niveau du moteur de base de données PostgreSQL pour Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html) dans le Guide de l'utilisateur Amazon RDS.
Des exemples d'utilisation des dépendances lors de la création d'une PL/Rust fonction sont disponibles sur [Utiliser les dépendances](https://tcdi.github.io/plrust/use-plrust.html#use-dependencies).
## Limites de PL/Rust
Par défaut, les utilisateurs de la base de données ne peuvent pas utiliserPL/Rust. To provide access to PL/Rust, se connecter en tant qu'utilisateur avec le privilège rds\$1superuser et exécuter la commande suivante :
```
postgres=> GRANT USAGE ON LANGUAGE PLRUST TO user;
```
# Gestion des données spatiales avec l’extension PostGIS
PostGIS est une extension de PostgreSQL pour le stockage et la gestion des informations spatiales. Pour en savoir plus sur PostGIS, consultez [PostGIS.net](https://postgis.net/).
À partir de la version 10.5, PostgreSQL prend en charge la bibliothèque libprotobuf 1.3.0 utilisée par PostGIS pour travailler avec les données des tuiles vectorielles des boîtes de cartes.
La configuration de l’extension PostGIS nécessite des privilèges `rds_superuser`. Nous vous recommandons de créer un utilisateur (rôle) pour gérer l’extension PostGIS et vos données spatiales. L’extension PostGIS et ses composants associés ajoutent des milliers de fonctions à PostgreSQL. Pensez à créer l’extension PostGIS dans son propre schéma si cela est logique pour votre cas d’utilisation. L’exemple suivant montre comment installer l’extension dans sa propre base de données, mais cela n’est pas nécessaire.
**Topics**
+ [
## Étape 1 : créer un utilisateur (rôle) pour gérer l’extension PostGIS
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Connect)
+ [
## Étape 2 : Chargez les extensions PostGIS
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.LoadExtensions)
+ [
## Étape 3 : Transfert de la propriété des schémas d’extension
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferOwnership)
+ [
## Étape 4 : Transfert de la propriété des tables PostGIS
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferObjects)
+ [
## Étape 5 : Testez les extensions
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Test)
+ [
## Étape 6 : Mettre à niveau l’extension PostGIS
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)
+ [Versions de l’extension PostGIS](#CHAP_PostgreSQL.Extensions.PostGIS)
+ [Mise à niveau de PostGIS 2 vers PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3)
## Étape 1 : créer un utilisateur (rôle) pour gérer l’extension PostGIS
Tout d’abord, connectez-vous à votre instance de base de données RDS pour PostgreSQL en tant qu’utilisateur disposant de privilèges `rds_superuser`. Si vous avez conservé le nom par défaut lors de la configuration de votre instance, vous vous connectez en tant que `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Créez un rôle (utilisateur) distinct pour administrer l’extension PostGIS.
```
postgres=> CREATE ROLE gis_admin LOGIN PASSWORD 'change_me';
CREATE ROLE
```
Accordez des privilèges `rds_superuser` à ce rôle, pour lui permettre d’installer l’extension.
```
postgres=> GRANT rds_superuser TO gis_admin;
GRANT
```
Créez une base de données à utiliser pour vos artefacts PostGIS. Cette étape est facultative. Vous pouvez également créer un schéma dans votre base de données utilisateur pour les extensions PostGIS, mais cela n’est pas non plus nécessaire.
```
postgres=> CREATE DATABASE lab_gis;
CREATE DATABASE
```
Accordez à `gis_admin` tous les privilèges sur la base de données `lab_gis`.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_gis TO gis_admin;
GRANT
```
Quittez la session et reconnectez-vous à votre instance de base de données RDS pour PostgreSQL en tant que `gis_admin`.
```
postgres=> psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=gis_admin --password --dbname=lab_gis
Password for user gis_admin:...
lab_gis=>
```
Continuez à configurer l’extension comme indiqué dans les étapes suivantes.
## Étape 2 : Chargez les extensions PostGIS
L’extension PostGIS comprend plusieurs extensions connexes qui fonctionnent ensemble pour fournir des fonctionnalités géospatiales. En fonction de votre cas d’utilisation, vous n’aurez peut-être pas besoin de toutes les extensions créées dans cette étape.
Utilisez les instructions `CREATE EXTENSION` pour charger les extensions PostGIS.
```
CREATE EXTENSION postgis;
CREATE EXTENSION
CREATE EXTENSION postgis_raster;
CREATE EXTENSION
CREATE EXTENSION fuzzystrmatch;
CREATE EXTENSION
CREATE EXTENSION postgis_tiger_geocoder;
CREATE EXTENSION
CREATE EXTENSION postgis_topology;
CREATE EXTENSION
CREATE EXTENSION address_standardizer_data_us;
CREATE EXTENSION
```
Vous pouvez vérifier les résultats en exécutant la requête SQL présentée dans cet exemple, qui répertorie les extensions et leurs propriétaires.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+-----------
public | postgres
tiger | rdsadmin
tiger_data | rdsadmin
topology | rdsadmin
(4 rows)
```
## Étape 3 : Transfert de la propriété des schémas d’extension
Utilisez les instructions ALTER SCHEMA pour transférer la propriété des schémas au rôle `gis_admin`.
```
ALTER SCHEMA tiger OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA tiger_data OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA topology OWNER TO gis_admin;
ALTER SCHEMA
```
Vous pouvez confirmer le changement de propriétaire en exécutant la requête SQL suivante. Vous pouvez également utiliser la méta-commande `\dn` à partir de la ligne de commande psql.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+---------------
public | postgres
tiger | gis_admin
tiger_data | gis_admin
topology | gis_admin
(4 rows)
```
## Étape 4 : Transfert de la propriété des tables PostGIS
**Note**
Ne changez pas la propriété des fonctions PostGIS. Le bon fonctionnement et les futures mises à niveau de PostGIS nécessitent que ces fonctions conservent leur propriété d’origine. Pour plus d’informations sur les autorisations PostGIS, consultez [Sécurité de PostgreSQL](https://postgis.net/workshops/postgis-intro/security.html).
Utilisez la fonction suivante pour transférer la propriété des tables PostGIS au rôle `gis_admin`. Exécutez l’instruction suivante à partir de l’invite psql pour créer la fonction.
```
CREATE FUNCTION exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;
CREATE FUNCTION
```
Ensuite, exécutez cette requête pour exécuter la fonction `exec` qui à son tour exécute les instructions et modifie les autorisations.
```
SELECT exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO gis_admin;')
FROM (
SELECT nspname, relname
FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid)
WHERE nspname in ('tiger','topology') AND
relkind IN ('r','S','v') ORDER BY relkind = 'S')
s;
```
## Étape 5 : Testez les extensions
Pour éviter d’avoir à spécifier le nom du schéma, ajoutez le schéma `tiger` à votre chemin de recherche en utilisant la commande suivante.
```
SET search_path=public,tiger;
SET
```
Testez le schéma `tiger` à l’aide de l’instruction SELECT suivante.
```
SELECT address, streetname, streettypeabbrev, zip
FROM normalize_address('1 Devonshire Place, Boston, MA 02109') AS na;
address | streetname | streettypeabbrev | zip
---------+------------+------------------+-------
1 | Devonshire | Pl | 02109
(1 row)
```
Pour en savoir plus sur cette extension, consultez [Tiger Geocoder](https://postgis.net/docs/Extras.html#Tiger_Geocoder) dans la documentation de PostGIS.
Testez l’accès au schéma `topology` en utilisant l’instruction `SELECT` suivante. Cela appelle la fonction `createtopology` qui enregistre un nouvel objet topologique (my\$1new\$1topo) avec l’identifiant de référence spatiale spécifié (26986) et la tolérance par défaut (0.5). Pour en savoir plus, consultez [CreateTopology](https://postgis.net/docs/CreateTopology.html)la documentation de PostGIS.
```
SELECT topology.createtopology('my_new_topo',26986,0.5);
createtopology
----------------
1
(1 row)
```
## Étape 6 : Mettre à niveau l’extension PostGIS
Chaque nouvelle version de PostgreSQL prend en charge une ou plusieurs versions de l’extension PostGIS compatibles avec cette version. La mise à niveau du moteur PostgreSQL vers une nouvelle version ne met pas automatiquement à niveau l’extension PostGIS. Avant de mettre à niveau le moteur PostgreSQL, vous mettez généralement à niveau PostGIS vers la version la plus récente disponible pour la version actuelle de PostgreSQL. Pour en savoir plus, consultez [Versions de l’extension PostGIS](#CHAP_PostgreSQL.Extensions.PostGIS).
Après la mise à niveau du moteur PostgreSQL, vous mettez à nouveau à niveau l’extension PostGIS, vers la version prise en charge par la nouvelle version du moteur PostgreSQL. Pour obtenir plus d’informations sur la mise à niveau du moteur PostgreSQL, consultez [Comment effectuer une mise à niveau de version majeure pour RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
Vous pouvez vérifier à tout moment si des mises à jour de l’extension PostGIS sont disponibles sur votre instance de base de données RDS pour PostgreSQL. Pour ce faire, exécutez la commande suivante. Cette fonction est disponible avec PostGIS 2.5.0 et les versions ultérieures.
```
SELECT postGIS_extensions_upgrade();
```
Si votre application ne prend pas en charge la dernière version de PostGIS, vous pouvez installer une version plus ancienne de PostGIS qui est disponible dans votre version majeure comme suit.
```
CREATE EXTENSION postgis VERSION "2.5.5";
```
Si vous souhaitez effectuer une mise à niveau vers une version PostGIS spécifique à partir d’une version antérieure, vous pouvez également utiliser la commande suivante.
```
ALTER EXTENSION postgis UPDATE TO "2.5.5";
```
Selon la version à partir de laquelle vous effectuez la mise à niveau, vous devrez peut-être utiliser à nouveau cette fonction. Le résultat de la première exécution de la fonction détermine si une mise à niveau supplémentaire est nécessaire. C’est le cas, par exemple, pour la mise à niveau de PostGIS 2 vers PostGIS 3. Pour plus d’informations, consultez [Mise à niveau de PostGIS 2 vers PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3).
Si vous avez mis à niveau cette extension pour vous préparer à une mise à niveau de version majeure du moteur PostgreSQL, vous pouvez continuer avec d’autres tâches préliminaires. Pour plus d’informations, consultez [Comment effectuer une mise à niveau de version majeure pour RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
## Versions de l’extension PostGIS
Nous vous recommandons d’installer les versions de toutes les extensions, telles que PostGIS, telles qu’elles sont répertoriées dans [Versions d’extension pour Amazon RDS pour PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) dans *Notes de mise à jour d’Amazon RDS pour PostgreSQL*. Pour obtenir une liste des versions qui sont disponibles dans votre version, utilisez la commande suivante.
```
SELECT * FROM pg_available_extension_versions WHERE name='postgis';
```
Vous pouvez trouver des informations sur la version dans les sections suivantes des *Notes de mise à jour de Amazon RDS pour PostgreSQL* :
+ [ Extensions PostgreSQL version 16 prises en charge sur Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-16x)
+ [ Extensions PostgreSQL version 15 prises en charge sur Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-15x)
+ [ Extensions PostgreSQL version 14 prises en charge sur Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-14x)
+ [ Extensions PostgreSQL version 13 prises en charge sur Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-13x)
+ [ Extensions PostgreSQL version 12 prises en charge sur Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-12x)
+ [ Extensions PostgreSQL version 11 prises en charge sur Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-11x)
+ [ Extensions PostgreSQL version 10 prises en charge sur Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-101x)
+ [ Extensions PostgreSQL version 9.6.x prises en charge sur Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-96x)
## Mise à niveau de PostGIS 2 vers PostGIS 3
Depuis la version 3.0, la fonctionnalité matricielle de PostGIS est désormais une extension distincte, `postgis_raster`. Cette extension dispose de son propre chemin d’installation et de mise à niveau. Cela supprime des dizaines de fonctions, de types de données et d’autres artefacts nécessaires au traitement des images matricielles de l’extension `postgis` de base. Cela signifie que si votre cas d’utilisation ne nécessite pas de traitement matriciel, vous n’avez pas besoin d’installer l’extension `postgis_raster`.
Dans l’exemple de mise à niveau suivant, la première commande de mise à niveau extrait la fonctionnalité raster dans l’extension `postgis_raster`. Une deuxième commande de mise à niveau est alors nécessaire pour mettre à niveau `postgis_raster` vers la nouvelle version.
**Pour effectuer une mise à niveau de PostGIS 2 vers PostGIS 3**
1. Identifiez la version par défaut de PostGIS qui est disponible pour la version de PostgreSQL sur votre . Instance de base de données RDS pour PostgreSQL. Pour ce faire, exécutez la requête suivante.
```
SELECT * FROM pg_available_extensions
WHERE default_version > installed_version;
name | default_version | installed_version | comment
---------+-----------------+-------------------+------------------------------------------------------------
postgis | 3.1.4 | 2.3.7 | PostGIS geometry and geography spatial types and functions
(1 row)
```
1. Identifiez les versions de PostGIS installées dans chaque base de données sur votre instance de base de données RDS pour PostgreSQL. En d’autres termes, interrogez chaque base de données utilisateur comme suit.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
---------+---------+--------+---------------------------------------------------------------------
postgis | 2.3.7 | public | PostGIS geometry, geography, and raster spatial types and functions
(1 row)
```
Ce décalage entre la version par défaut (PostGIS 3.1.4) et la version installée (PostGIS 2.3.7) signifie que vous devez mettre à niveau l’extension PostGIS.
```
ALTER EXTENSION postgis UPDATE;
ALTER EXTENSION
WARNING: unpackaging raster
WARNING: PostGIS Raster functionality has been unpackaged
```
1. Exécutez la requête suivante pour vérifier que la fonctionnalité raster est maintenant dans son propre package.
```
SELECT
probin,
count(*)
FROM
pg_proc
WHERE
probin LIKE '%postgis%'
GROUP BY
probin;
probin | count
--------------------------+-------
$libdir/rtpostgis-2.3 | 107
$libdir/postgis-3 | 487
(2 rows)
```
Le résultat montre qu’il y a toujours une différence entre les versions. Les fonctions PostGIS sont en version 3 (postgis-3), tandis que les fonctions raster (rtpostgis) sont en version 2 (rtpostgis-2.3). Pour terminer la mise à niveau, vous exécutez à nouveau la commande de mise à niveau, comme suit.
```
postgres=> SELECT postgis_extensions_upgrade();
```
Vous pouvez ignorer les messages d’avertissement, il n’y a aucun risque. Exécutez à nouveau la requête suivante pour vérifier que la mise à niveau est terminée. La mise à niveau est terminée lorsque PostGIS et toutes les extensions associées ne sont plus marquées comme nécessitant une mise à niveau.
```
SELECT postgis_full_version();
```
1. Utilisez la requête suivante pour voir le processus de mise à niveau terminé et les extensions packagées séparément, et vérifiez que leurs versions correspondent.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
----------------+---------+--------+---------------------------------------------------------------------
postgis | 3.1.5 | public | PostGIS geometry, geography, and raster spatial types and functions
postgis_raster | 3.1.5 | public | PostGIS raster types and functions
(2 rows)
```
Le résultat montre que l’extension PostGIS 2 a été mise à niveau vers PostGIS 3, et que `postgis` et l’extension `postgis_raster` maintenant séparée sont en version 3.1.5.
Une fois cette mise à niveau terminée, si vous ne prévoyez pas d’utiliser la fonctionnalité raster, vous pouvez abandonner l’extension comme suit.
```
DROP EXTENSION postgis_raster;
```
# Utilisation des encapsuleurs de données externes pris en charge pour Amazon RDS pour PostgreSQL
Un encapsuleur de données externes est un type d’extension spécifique qui permet d’accéder à des données externes. Par exemple, l’extension `oracle_fdw` permet à votre cluster de bases de données RDS pour PostgreSQL de fonctionner avec des bases de données Oracle. Autre exemple, en utilisant l’extension `postgres_fdw` native PostgreSQL, vous pouvez accéder aux données stockées dans des instances de base de données PostgreSQL externes à votre instance de base de données RDS pour PostgreSQL.
Vous trouverez ci-dessous des informations sur plusieurs encapsuleurs de données externes PostgreSQL pris en charge.
**Topics**
+ [
# Utilisation de l'extension log\$1fdw pour accéder au journal de base de données à l'aide de SQL
](CHAP_PostgreSQL.Extensions.log_fdw.md)
+ [
# Utilisation de l'extension postgres\$1fdw pour accéder à des données externes
](postgresql-commondbatasks-fdw.md)
+ [
# Travailler avec des bases de données MySQL en utilisant l'extension mysql\$1fdw
](postgresql-mysql-fdw.md)
+ [
# Utilisation des bases de données Oracle avec l'extension oracle\$1fdw
](postgresql-oracle-fdw.md)
+ [
# Utilisation de bases de données SQL Server avec l'extension tds\$1fdw
](postgresql-tds-fdw.md)
# Utilisation de l'extension log\$1fdw pour accéder au journal de base de données à l'aide de SQL
L'instance de base de données RDS for PostgreSQL prend en charge l'extension `log_fdw`, qui vous permet d'accéder au journal de votre moteur de base de données à l'aide d'une interface SQL. L'extension `log_fdw` fournit deux fonctions qui facilitent la création de tables source pour les journaux de base de données :
+ `list_postgres_log_files` – Répertorie les fichiers dans le répertoire du journal de base de données et indique la taille des fichiers en octets.
+ `create_foreign_table_for_log_file(table_name text, server_name text, log_file_name text)` – Crée un tableau source pour le fichier spécifié dans la base de données actuelle.
Toutes les fonctions créées par `log_fdw` appartiennent à `rds_superuser`. Les membres du rôle `rds_superuser` peuvent accorder l'accès à ces fonctions à d'autres utilisateurs de base de données.
Par défaut, les fichiers journaux sont générés par Amazon RDS au format `stderr` (erreur standard), comme spécifié dans le paramètre `log_destination`. Il n'y a que deux options pour ce paramètre, `stderr` et `csvlog` (valeurs séparées par des virgules, CSV). Si vous ajoutez l'option `csvlog` au paramètre, Amazon RDS génère les journaux `stderr` et `csvlog`. Cela peut affecter la capacité de stockage de votre cluster de base de données. Vous devez donc connaître les autres paramètres qui affectent la gestion des journaux. Pour de plus amples informations, veuillez consulter [Définition de la destination du journal (`stderr`, `csvlog`)](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md#USER_LogAccess.Concepts.PostgreSQL.Log_Format).
L'un des avantages de la génération de journaux `csvlog` est que l'extension `log_fdw` vous permet de créer des tables externes dont les données sont soigneusement réparties en plusieurs colonnes. Pour ce faire, votre instance doit être associée à un groupe de paramètres de base de données personnalisé afin que vous puissiez modifier le paramètre de `log_destination`. Pour plus d'informations sur la manière de procéder, consultez [Utilisation de paramètres sur votre instance de base de données RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
L'exemple suivant suppose que le paramètre `log_destination` comprend le champ `cvslog`.
**Pour utiliser l'extension log\$1fdw**
1. Installez l’extension `log_fdw`.
```
postgres=> CREATE EXTENSION log_fdw;
CREATE EXTENSION
```
1. Créez le serveur de journal en tant qu'encapsuleur de données externes.
```
postgres=> CREATE SERVER log_server FOREIGN DATA WRAPPER log_fdw;
CREATE SERVER
```
1. Sélectionnez l'ensemble des fichiers journaux d'une liste.
```
postgres=> SELECT * FROM list_postgres_log_files() ORDER BY 1;
```
Voici un exemple de réponse.
```
file_name | file_size_bytes
------------------------------+-----------------
postgresql.log.2023-08-09-22.csv | 1111
postgresql.log.2023-08-09-23.csv | 1172
postgresql.log.2023-08-10-00.csv | 1744
postgresql.log.2023-08-10-01.csv | 1102
(4 rows)
```
1. Créez une table avec une seule colonne « log\$1entry » pour le fichier sélectionné.
```
postgres=> SELECT create_foreign_table_for_log_file('my_postgres_error_log',
'log_server', 'postgresql.log.2023-08-09-22.csv');
```
La réponse ne fournit aucun détail autre que l'existence de la table.
```
-----------------------------------
(1 row)
```
1. Sélectionnez un exemple de fichier journal. Le code suivant récupère l'heure du journal et la description du message d'erreur.
```
postgres=> SELECT log_time, message FROM my_postgres_error_log ORDER BY 1;
```
Voici un exemple de réponse.
```
log_time | message
----------------------------------+---------------------------------------------------------------------------
Tue Aug 09 15:45:18.172 2023 PDT | ending log output to stderr
Tue Aug 09 15:45:18.175 2023 PDT | database system was interrupted; last known up at 2023-08-09 22:43:34 UTC
Tue Aug 09 15:45:18.223 2023 PDT | checkpoint record is at 0/90002E0
Tue Aug 09 15:45:18.223 2023 PDT | redo record is at 0/90002A8; shutdown FALSE
Tue Aug 09 15:45:18.223 2023 PDT | next transaction ID: 0/1879; next OID: 24578
Tue Aug 09 15:45:18.223 2023 PDT | next MultiXactId: 1; next MultiXactOffset: 0
Tue Aug 09 15:45:18.223 2023 PDT | oldest unfrozen transaction ID: 1822, in database 1
(7 rows)
```
# Utilisation de l'extension postgres\$1fdw pour accéder à des données externes
Vous pouvez accéder aux données d'un tableau sur un serveur de bases de données distant à l'aide de l'extension [postgres\$1fdw](https://www.postgresql.org/docs/current/static/postgres-fdw.html). Si vous configurez une connexion distante à partir de votre instance de base de données PostgreSQL, l'accès à votre réplica en lecture est également disponible.
**Pour utiliser postgres\$1fdw pour accéder à un serveur de bases de données distant**
1. Installez l'extension postgres\$1fdw.
```
CREATE EXTENSION postgres_fdw;
```
1. Créez un serveur de données externes à l'aide de CREATE SERVER.
```
CREATE SERVER foreign_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host 'xxx.xx.xxx.xx', port '5432', dbname 'foreign_db');
```
1. Créez un mappage utilisateur pour identifier le rôle à utiliser sur le serveur distant.
**Important**
Pour éviter que le mot de passe ne soit consigné dans les journaux, définissez le paramètre `log_statement=none` au niveau de la session. Définir ce réglage au niveau du paramètre ne permet pas de masquer le mot de passe.
```
CREATE USER MAPPING FOR local_user
SERVER foreign_server
OPTIONS (user 'foreign_user', password 'password');
```
1. Créez une table mappée à la table sur le serveur distant.
```
CREATE FOREIGN TABLE foreign_table (
id integer NOT NULL,
data text)
SERVER foreign_server
OPTIONS (schema_name 'some_schema', table_name 'some_table');
```
# Travailler avec des bases de données MySQL en utilisant l'extension mysql\$1fdw
Pour accéder à une base de données compatible MySQL à partir de votre instance de base de données RDS for PostgreSQL, vous pouvez installer et utiliser l'extension `mysql_fdw`. Cet encapsuleur de données externes vous permet de travailler avec RDS for MySQL, Aurora MySQL, MariaDB et d'autres bases de données compatibles avec MySQL. La connexion de votre instance de base de données RDS for PostgreSQL à la base de données MySQL est chiffrée au mieux, en fonction des configurations du client et du serveur. Cependant, vous pouvez imposer le chiffrement si vous le souhaitez. Pour de plus amples informations, veuillez consulter [Utilisation du chiffrement en transit avec l'extension](#postgresql-mysql-fdw.encryption-in-transit).
L'extension `mysql_fdw` est prise en charge par Amazon RDS for PostgreSQL versions 14.2 et 13.6 et ultérieures. Elle prend en charge la sélection, l'insertion, la mise à jour et la suppression d'une base de données RDS for PostgreSQL vers des tables sur une instance de base de données compatible MySQL.
**Topics**
+ [
## Configuration de votre base de données RDS for PostgreSQL pour utiliser l'extension mysql\$1fdw
](#postgresql-mysql-fdw.setting-up)
+ [
## Exemple : utilisation d'une base de données RDS for MySQL à partir de RDS for PostgreSQL
](#postgresql-mysql-fdw.using-mysql_fdw)
+ [
## Utilisation du chiffrement en transit avec l'extension
](#postgresql-mysql-fdw.encryption-in-transit)
## Configuration de votre base de données RDS for PostgreSQL pour utiliser l'extension mysql\$1fdw
La configuration de l'extension `mysql_fdw` sur votre instance de base de données RDS for PostgreSQL implique le chargement de l'extension dans votre instance de base de données, puis la création du point de connexion à l'instance de base de données MySQL. Pour cette tâche, vous devez disposer des informations suivantes sur l'instance de base de données MySQL :
+ Nom d'hôte ou point de terminaison. Pour une instance de base de données RDS for MySQL, vous pouvez trouver le point de terminaison à l'aide de la console. Sélectionnez l'onglet Connectivité et sécurité et regardez dans la section « Point de terminaison et port ».
+ Numéro de port. Le numéro de port par défaut pour MySQL est 3306.
+ Nom du moteur de la base de données. L'identifiant de la base de données.
Vous devez également fournir un accès sur le groupe de sécurité ou la liste de contrôle d'accès (ACL) pour le port MySQL 3306. Les instances de bases de données RDS for PostgreSQL et RDS for MySQL doivent avoir accès au port 3306. Si l'accès n'est pas configuré correctement, lorsque vous essayez de vous connecter à une table compatible avec MySQL, vous voyez apparaître un message d'erreur similaire au suivant :
```
ERROR: failed to connect to MySQL: Can't connect to MySQL server on 'hostname.aws-region.rds.amazonaws.com:3306' (110)
```
Dans la procédure suivante, vous (en tant que compte `rds_superuser`) créez le serveur externe. Vous accordez ensuite l'accès au serveur externe à des utilisateurs spécifiques. Ces utilisateurs créent ensuite leurs propres mappages vers les comptes utilisateurs MySQL appropriés pour travailler avec l'instance de base de données MySQL.
**Pour utiliser mysql\$1fdw pour accéder à un serveur de base de données MySQL**
1. Connectez-vous à votre instance de base de données PostgreSQL en utilisant un compte qui a le rôle `rds_superuser`. Si vous avez accepté les valeurs par défaut lors de la création de votre instance de base de donnés RDS for PostgreSQL, le nom d'utilisateur est `postgres`, et vous pouvez vous connecter à l'aide de l'outil de ligne de commande `psql` comme suit :
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres –-password
```
1. Installez l'extension `mysql_fdw` comme suit :
```
postgres=> CREATE EXTENSION mysql_fdw;
CREATE EXTENSION
```
Une fois l'extension installée sur votre instance de base de données RDS for PostgreSQL, vous devez configurer le serveur externe qui fournit la connexion à une base de données MySQL.
**Pour créer le serveur externe**
Effectuez ces tâches sur l'instance de base de données RDS for PostgreSQL. Les étapes supposent que vous êtes connecté en tant qu'utilisateur avec des privilèges `rds_superuser`, tels que `postgres`.
1. Créer un serveur externe dans l'instance de base de données RDS for PostgreSQL :
```
postgres=> CREATE SERVER mysql-db FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'db-name.111122223333.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Accordez aux utilisateurs appropriés l'accès au serveur externe. Il doit s'agir d'utilisateurs non administrateurs, c'est-à-dire d'utilisateurs sans rôle `rds_superuser`.
```
postgres=> GRANT USAGE ON FOREIGN SERVER mysql-db to user1;
GRANT
```
Les utilisateurs de PostgreSQL créent et gèrent leurs propres connexions à la base de données MySQL via le serveur externe.
## Exemple : utilisation d'une base de données RDS for MySQL à partir de RDS for PostgreSQL
Supposons que vous ayez une table simple sur une instance de base de données RDS for PostgreSQL. Vos utilisateurs RDS for PostgreSQL souhaitent interroger les éléments (`SELECT`), `INSERT`, `UPDATE` et `DELETE` de cette table. Supposons que l'extension `mysql_fdw` a été créée sur votre instance de base de données RDS for PostgreSQL, comme indiqué dans la procédure précédente. Après vous être connecté à l'instance de base de données RDS for PostgreSQL en tant qu'utilisateur disposant de privilèges `rds_superuser`, vous pouvez procéder aux étapes suivantes.
1. Créez un serveur externe sur l'instance de base de données RDS for PostgreSQL :
```
test=> CREATE SERVER mysqldb FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'your-DB.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Accordez l'utilisation à un utilisateur dépourvu d'autorisations `rds_superuser`, par exemple `user1` :
```
test=> GRANT USAGE ON FOREIGN SERVER mysqldb TO user1;
GRANT
```
1. Connectez-vous en tant que*user1*, puis créez un mappage vers l'utilisateur MySQL :
```
test=> CREATE USER MAPPING FOR user1 SERVER mysqldb OPTIONS (username 'myuser', password 'mypassword');
CREATE USER MAPPING
```
1. Créez une table externe liée à la table MySQL :
```
test=> CREATE FOREIGN TABLE mytab (a int, b text) SERVER mysqldb OPTIONS (dbname 'test', table_name '');
CREATE FOREIGN TABLE
```
1. Exécutez une requête simple dans la table externe :
```
test=> SELECT * FROM mytab;
a | b
---+-------
1 | apple
(1 row)
```
1. Vous pouvez ajouter, modifier et supprimer des données de la table MySQL. Par exemple :
```
test=> INSERT INTO mytab values (2, 'mango');
INSERT 0 1
```
Exécutez à nouveau la requête `SELECT` pour voir les résultats :
```
test=> SELECT * FROM mytab ORDER BY 1;
a | b
---+-------
1 | apple
2 | mango
(2 rows)
```
## Utilisation du chiffrement en transit avec l'extension
La connexion à MySQL à partir de RDS for PostgreSQL utilise le chiffrement en transit (TLS/SSL) par défaut. Toutefois, la connexion redevient non chiffrée lorsque la configuration du client et du serveur diffère. Vous pouvez imposer le chiffrement pour toutes les connexions sortantes en spécifiant l'option `REQUIRE SSL` sur les comptes d'utilisateur RDS for MySQL. Cette même approche fonctionne également pour les comptes utilisateurs MariaDB et Aurora MySQL.
Pour les comptes utilisateurs MySQL configurés pour `REQUIRE SSL`, la tentative de connexion échoue si une connexion sécurisée ne peut être établie.
Pour appliquer le chiffrement aux comptes d'utilisateurs de bases de données MySQL existants, vous pouvez utiliser la commande `ALTER USER`. La syntaxe varie en fonction de la version MySQL, comme indiqué dans le tableau suivant. Pour plus d'informations, consultez [ALTER USER](https://dev.mysql.com/doc/refman/8.0/en/alter-user.html) dans le *Manuel de référence de MySQL*.
| MySQL 5.7, MySQL 8.0 | MySQL 5.6 |
| --- | --- |
| `ALTER USER 'user'@'%' REQUIRE SSL;` | `GRANT USAGE ON *.* to 'user'@'%' REQUIRE SSL;` |
Pour plus d'informations sur l'extension `mysql_fdw`, consultez la documentation [mysql\$1fdw](https://github.com/EnterpriseDB/mysql_fdw).
# Utilisation des bases de données Oracle avec l'extension oracle\$1fdw
Pour accéder à une base de données Oracle depuis votre instance de base de données RDS pour PostgreSQL, vous pouvez installer et utiliser l’extension `oracle_fdw`. Cette extension est un encapsuleur de données externes pour les bases de données Oracle. Pour en savoir plus sur cette extension, consultez la documentation [oracle\$1fdw](https://github.com/laurenz/oracle_fdw).
L'extension `oracle_fdw` est prise en charge sur RDS pour PostgreSQL 12.7, 13.3 et les versions ultérieures.
**Topics**
+ [
## Activation de l'extension oracle\$1fdw
](#postgresql-oracle-fdw.enabling)
+ [
## Exemple : utilisation d'un serveur externe lié à une base de données Amazon RDS for Oracle Database
](#postgresql-oracle-fdw.example)
+ [
## Utilisation du chiffrement en transit
](#postgresql-oracle-fdw.encryption)
+ [
## Comprendre la vue et les autorisations pg\$1user\$1mappings
](#postgresql-oracle-fdw.permissions)
## Activation de l'extension oracle\$1fdw
Pour utiliser l'extension oracle\$1fdw, suivez la procédure suivante.
**Pour activer l'extension oracle\$1fdw**
+ Exécutez la commande suivante en utilisant un compte disposant d'autorisations `rds_superuser`.
```
CREATE EXTENSION oracle_fdw;
```
## Exemple : utilisation d'un serveur externe lié à une base de données Amazon RDS for Oracle Database
Les exemples suivants démontrent l'utilisation d'un serveur externe lié à une base de données Amazon RDS for Oracle.
**Pour créer un serveur externe lié à une base de données RDS for Oracle**
1. Notez ce qui suit sur l'instance de base de données RDS for Oracle :
+ Point de terminaison
+ Port
+ Nom de base de données
1. Créez un serveur externe.
```
test=> CREATE SERVER oradb FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver '//endpoint:port/DB_name');
CREATE SERVER
```
1. Accordez l'utilisation à un utilisateur dépourvu d'autorisations `rds_superuser`, par exemple `user1`.
```
test=> GRANT USAGE ON FOREIGN SERVER oradb TO user1;
GRANT
```
1. Connectez-vous en tant que `user1` et créez un mappage à un utilisateur Oracle.
```
test=> CREATE USER MAPPING FOR user1 SERVER oradb OPTIONS (user 'oracleuser', password 'mypassword');
CREATE USER MAPPING
```
1. Créez une table externe liée à une table Oracle.
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER oradb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Interrogez la table externe.
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
Si la requête signale l'erreur suivante, vérifiez votre groupe de sécurité et votre liste de contrôle d'accès (ACL) pour vous assurer que les deux instances peuvent communiquer.
```
ERROR: connection for foreign table "mytab" cannot be established
DETAIL: ORA-12170: TNS:Connect timeout occurred
```
## Utilisation du chiffrement en transit
Le chiffrement PostgreSQL vers Oracle en transit est basé sur une combinaison de paramètres de configuration client et serveur. Pour un exemple d'utilisation d'Oracle 21c, consultez [A propos de la négociation du chiffrement et de l'intégrité](https://docs.oracle.com/en/database/oracle/oracle-database/21/dbseg/configuring-network-data-encryption-and-integrity.html#GUID-3A2AF4AA-AE3E-446B-8F64-31C48F27A2B5) dans la documentation Oracle. Le client utilisé pour oracle\$1fdw sur Amazon RDS est configuré avec `ACCEPTED`, ce qui signifie que le chiffrement dépend de la configuration du serveur de base de données Oracle et qu’il utilise Oracle Security Library (libnnz) pour le chiffrement.
Si votre base de données se trouve sur RDS for Oracle, consultez la section [Oracle native network encryption](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.NetworkEncryption.html) (Chiffrement réseau natif Oracle) pour configurer le chiffrement.
## Comprendre la vue et les autorisations pg\$1user\$1mappings
Le catalogue PostgreSQL `pg_user_mapping` stocke le mappage d’un utilisateur RDS pour PostgreSQL vers l’utilisateur d’un serveur de données externe (distant). L'accès au catalogue est restreint, mais vous utilisez la vue `pg_user_mappings` pour visualiser les mappages. Dans ce qui suit, vous trouverez un exemple qui présente comment les autorisations s'appliquent avec un exemple de base de données Oracle, mais ces informations s'appliquent plus généralement à tout encapsuleur de données externes.
Dans la sortie suivante, vous pouvez trouver des rôles et des autorisations mappés à trois exemples d'utilisateurs différents. Les utilisateurs `rdssu1` et `rdssu2` sont membres du rôle `rds_superuser`, et `user1` ne l'est pas. L'exemple utilise la métacommande `psql` `\du` pour lister les rôles existants.
```
test=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+-------------------------------------------------------------
rdssu1 | | {rds_superuser}
rdssu2 | | {rds_superuser}
user1 | | {}
```
Tous les utilisateurs, y compris ceux qui disposent de privilèges `rds_superuser`, sont autorisés à voir leurs propres mappages d'utilisateurs (`umoptions`) dans la table `pg_user_mappings`. Comme le montre l'exemple suivant, lorsque `rdssu1` tente d'obtenir tous les mappages d'utilisateurs, une erreur s'affiche en dépit des privilèges `rds_superuser` de `rdssu1` :
```
test=> SELECT * FROM pg_user_mapping;
ERROR: permission denied for table pg_user_mapping
```
Voici quelques exemples.
```
test=> SET SESSION AUTHORIZATION rdssu1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 | {user=oracleuser,password=mypwd}
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
test=> SET SESSION AUTHORIZATION rdssu2;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 | {user=oracleuser,password=mypwd}
(3 rows)
test=> SET SESSION AUTHORIZATION user1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+--------------------------------
16414 | 16411 | oradb | 16412 | user1 | {user=oracleuser,password=mypwd}
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
```
En raison des différences dans l'implémentation de `information_schema._pg_user_mappings` et de `pg_catalog.pg_user_mappings`, un `rds_superuser` créé manuellement nécessite des autorisations supplémentaires pour afficher les mots de passe dans `pg_catalog.pg_user_mappings`.
Un `rds_superuser` n'a besoin d'aucune autorisation supplémentaire pour afficher les mots de passe dans `information_schema._pg_user_mappings`.
Les utilisateurs qui n'ont pas le rôle `rds_superuser` peuvent afficher les mots de passe dans `pg_user_mappings` uniquement dans les conditions suivantes :
+ L'utilisateur actif est celui faisant l'objet du mappage. Il possède le serveur ou détient le privilège `USAGE` sur celui-ci.
+ L'utilisateur actuel est le propriétaire du serveur et le mappage est pour `PUBLIC`.
# Utilisation de bases de données SQL Server avec l'extension tds\$1fdw
Vous pouvez utiliser l'extension PostgreSQL `tds_fdw` pour accéder aux bases de données qui prennent en charge le protocole TDS (tabular data stream), comme les bases de données Sybase et Microsoft SQL Server. Cet encapsuleur de données externes vous permet de vous connecter à partir de votre instance de base de données RDS for PostgreSQL ou de votre à des bases de données qui utilisent le protocole TDS, y compris Amazon RDS for Microsoft SQL Server. Pour plus d'informations, consultez la documentation de [tds-fdw/tds\$1fdw](https://github.com/tds-fdw/tds_fdw) sur GitHub.
L'extension `tds_fdw` est prise en charge sur Amazon RDS for PostgreSQL versions 14.2, 13.6 et ultérieures.
## Configuration de votre base de données Aurora PostgreSQL pour utiliser l'extension tds\$1fdw
Dans les procédures suivantes, vous trouverez un exemple de configuration et d'utilisation de `tds_fdw` avec une instance de base de données RDS for PostgreSQL. Avant de pouvoir vous connecter à une base de données SQL Server à l'aide de `tds_fdw`, vous devez obtenir les détails suivants pour l'instance :
+ Nom d'hôte ou point de terminaison. Pour une instance de base de données RDS for SQL Server, vous pouvez trouver le point de terminaison en utilisant la console. Sélectionnez l'onglet Connectivité et sécurité et regardez dans la section « Point de terminaison et port ».
+ Numéro de port. Le numéro de port par défaut de Microsoft SQL Server est 1433.
+ Nom du moteur de la base de données. L'identifiant de la base de données.
Vous devez également fournir un accès au groupe de sécurité ou à la liste de contrôle d'accès (ACL) pour le port du serveur SQL 1433. l'instance de base de données RDS for PostgreSQL et l'instance de base de données RDS for SQL Server ont tous deux besoin d'accéder au port 1433. Si l'accès n'est pas configuré correctement, lorsque vous essayez d'interroger le serveur Microsoft SQL, le message d'erreur suivant s'affiche :
```
ERROR: DB-Library error: DB #: 20009, DB Msg: Unable to connect:
Adaptive Server is unavailable or does not exist (mssql2019.aws-region.rds.amazonaws.com), OS #: 0, OS Msg: Success, Level: 9
```
**Pour utiliser tds\$1fdw pour vous connecter à une base de données SQL Server**
1. Connectez-vous à votre instance de base de données PostgreSQL en utilisant un compte qui dispose du rôle `rds_superuser` :
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=test –-password
```
1. Installez l'extension `tds_fdw` :
```
test=> CREATE EXTENSION tds_fdw;
CREATE EXTENSION
```
Une fois l'extension installée sur votre instance de base de données RDS for PostgreSQL, vous configurez le serveur externe.
**Pour créer le serveur externe**
Effectuez ces tâches sur l'instance de base de données RDS for PostgreSQL en utilisant un compte qui dispose de privilèges `rds_superuser`.
1. Créer un serveur externe dans l'instance de base de données RDS for PostgreSQL :
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing');
CREATE SERVER
```
Pour accéder à des données non-ASCII côté SQL Server, créez un lien vers le serveur avec l'option character\$1set dans l'instance de base de données RDS for PostgreSQL :
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing', character_set 'UTF-8');
CREATE SERVER
```
1. Accordez des autorisations à un utilisateur qui n'a pas de privilèges de rôle `rds_superuser`, par exemple, `user1` :
```
test=> GRANT USAGE ON FOREIGN SERVER sqlserverdb TO user1;
```
1. Connectez-vous en tant que user1 et créez un mappage vers un utilisateur SQL Server :
```
test=> CREATE USER MAPPING FOR user1 SERVER sqlserverdb OPTIONS (username 'sqlserveruser', password 'password');
CREATE USER MAPPING
```
1. Créez une table externe liée à une table SQL Server :
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER sqlserverdb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Interrogez la table externe :
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
### Utilisation du chiffrement en transit pour la connexion
La connexion de RDS for PostgreSQL à SQL Server utilise le chiffrement en transit (TLS/SSL) selon la configuration de la base de données SQL Server. Si le serveur SQL n'est pas configuré pour le chiffrement, le client RDS for PostgreSQL qui émet la requête à la base de données du serveur SQL revient au mode non chiffré.
Vous pouvez renforcer le chiffrement de la connexion aux instances de base de données RDS for SQL Server en définissant le paramètre `rds.force_ssl`. Pour savoir comment procéder, consultez [Forcer les connexions à votre instance de base de données pour utiliser SSL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html#SQLServer.Concepts.General.SSL.Forcing). Pour plus d'informations sur la configuration SSL/TLS pour RDS for SQL Server, consultez [Utilisation de SSL avec une instance DB Microsoft SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html).
# Utilisation de Trusted Language Extensions pour PostgreSQL
Trusted Language Extensions pour PostgreSQL est un kit de développement open source permettant de créer des extensions PostgreSQL. Il vous permet de créer des extensions PostgreSQL à hautes performances et de les exécuter en toute sécurité sur votre instance de base de données RDS pour PostgreSQL. En utilisant Trusted Language Extensions (TLE) pour PostgreSQL, vous pouvez créer des extensions PostgreSQL qui suivent l’approche documentée pour étendre les fonctionnalités de PostgreSQL. Pour plus d’informations, consultez [Packaging Related Objects into an Extension](https://www.postgresql.org/docs/current/extend-extensions.html) (Empaquetage d’objets associés dans une extension) dans la documentation PostgreSQL.
L’un des principaux avantages de TLE est que vous pouvez l’utiliser dans des environnements qui ne donnent pas accès au système de fichiers sous-jacent à l’instance PostgreSQL. Auparavant, l’installation d’une nouvelle extension nécessitait l’accès au système de fichiers. TLE supprime cette contrainte. Il fournit un environnement de développement permettant de créer de nouvelles extensions pour n’importe quelle base de données PostgreSQL, y compris celles qui s’exécutent sur vos instances de base de données RDS pour PostgreSQL.
TLE est conçu pour empêcher l’accès à des ressources dangereuses pour les extensions que vous créez à l’aide de TLE. Son environnement d’exécution limite l’impact de tout défaut d’extension à une seule connexion de base de données. TLE permet également aux administrateurs de base de données de contrôler précisément qui peut installer les extensions et fournit un modèle d’autorisations pour les exécuter.
TLE est pris en charge sur les versions suivantes de RDS pour PostgreSQL :
+ Version 18.1 et versions supérieures 18 versions
+ Version 17.1 et versions 17 ultérieures
+ Version 16.1 et versions 16 ultérieures
+ Version 15.2 et versions 15 ultérieures
+ Version 14.5 et versions 14 ultérieures
+ Version 13.12 et versions 13 ultérieures
Le runtime et l’environnement de développement Trusted Language Extensions sont fournis sous la forme de l’extension PostgreSQL `pg_tle`, version 1.0.1. Il prend en charge la création d'extensions en JavaScript Perl, Tcl, PL/pgSQL et SQL. Vous installez l’extension `pg_tle` dans votre instance de base de données RDS pour PostgreSQL de la même manière que vous installez les autres extensions PostgreSQL. Une fois le kit `pg_tle` configuré, les développeurs peuvent l’utiliser pour créer de nouvelles extensions PostgreSQL, appelées *extensions TLE*.
Dans les rubriques suivantes, vous apprendrez comment configurer le kit Trusted Language Extensions et comment commencer à créer vos propres extensions TLE.
**Topics**
+ [
# Terminologie
](PostgreSQL_trusted_language_extension-terminology.md)
+ [
# Exigences relatives à l’utilisation de Trusted Language Extensions pour PostgreSQL
](PostgreSQL_trusted_language_extension-requirements.md)
+ [
# Configuration de Trusted Language Extensions dans votre instance de base de données RDS for PostgreSQL
](PostgreSQL_trusted_language_extension-setting-up.md)
+ [
# Présentation de Trusted Language Extensions pour PostgreSQL
](PostgreSQL_trusted_language_extension.overview.md)
+ [
# Création d'extensions TLE pour RDS for PostgreSQL
](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md)
+ [
# Suppression de vos extensions TLE d'une base de données
](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md)
+ [
# Désinstallation de Trusted Language Extensions pour PostgreSQL
](PostgreSQL_trusted_language_extension-uninstalling-pg_tle-devkit.md)
+ [
# Utilisation des hooks PostgreSQL avec vos extensions TLE
](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md)
+ [
# Utilisation de types de données personnalisés dans TLE
](PostgreSQL_trusted_language_extension-custom-data-type.md)
+ [
# Référence de fonction pour Trusted Language Extensions pour PostgreSQL
](PostgreSQL_trusted_language_extension-functions-reference.md)
+ [
# Référence des hooks pour Trusted Language Extensions pour PostgreSQL
](PostgreSQL_trusted_language_extension-hooks-reference.md)
# Terminologie
Pour vous aider à mieux comprendre Trusted Language Extensions, consultez le glossaire suivant des termes utilisés dans cette rubrique.
**Trusted Language Extensions pour PostgreSQL**
*Trusted Language Extensions pour PostgreSQL* est le nom officiel du kit de développement open source fourni en tant qu'extension `pg_tle`. Il peut être utilisé sur n'importe quel système PostgreSQL. Pour plus d'informations, consultez [aws/pg\$1tle](https://github.com/aws/pg_tle) sur GitHub.
**Trusted Language Extensions**
*Trusted Language Extensions* est le nom court de Trusted Language Extensions pour PostgreSQL. Ce nom court et son abréviation (TLE) sont également utilisés dans cette documentation.
**langage approuvé**
Un *langage approuvé* est un langage de programmation ou de script doté d'attributs de sécurité spécifiques. Par exemple, les langages approuvés limitent généralement l'accès au système de fichiers et limitent l'utilisation de propriétés réseau spécifiées. Le kit de développement TLE est conçu pour prendre en charge les langages approuvés. PostgreSQL prend en charge plusieurs langages utilisés pour créer des extensions approuvées ou non approuvées. Pour voir un exemple, consultez [Trusted and Untrusted PL/Perl](https://www.postgresql.org/docs/current/plperl-trusted.html) (Langage PL/Perl approuvé et non approuvé) dans la documentation PostgreSQL. Lorsque vous créez une extension à l'aide du kit Trusted Language Extensions, l'extension utilise intrinsèquement des mécanismes linguistiques approuvés.
**extension TLE**
Une *extension TLE* est une extension PostgreSQL créée à l'aide du kit de développement Trusted Language Extensions (TLE).
# Exigences relatives à l’utilisation de Trusted Language Extensions pour PostgreSQL
Vous trouverez ci-dessous les exigences relatives à la configuration et à l’utilisation du kit de développement TLE.
+ ** Versions de RDS pour PostgreSQL** : Trusted Language Extensions est pris en charge sur RDS pour PostgreSQL version 13.12 et versions 13 ultérieures, version 14.5 et versions 14 ultérieures et version 15.2 et versions ultérieures uniquement.
+ Si vous devez mettre à niveau votre instance RDS pour PostgreSQL, consultez [Mises à niveau du moteur de base de données RDS pour PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md).
+ Si vous ne possédez pas encore d’instance de base de données Amazon RDS exécutant PostgreSQL, vous pouvez en créer un(e). Pour plus d’informations, consultez instance de base de données RDS pour PostgreSQL, consultez [Création et connexion à une instance de base de données PostgreSQL](CHAP_GettingStarted.CreatingConnecting.PostgreSQL.md).
+ **Nécessite les privilèges `rds_superuser`** : pour installer et configurer l’extension `pg_tle`, votre rôle d’utilisateur de base de données doit disposer des autorisations du rôle `rds_superuser`. Par défaut, ce rôle est accordé à l’utilisateur `postgres` qui crée le Instance de base de données RDS pour PostgreSQL.
+ **Nécessite un groupe de paramètres de base de données personnalisé** : votre instance de base de données RDS pour PostgreSQL doit être configurée avec un groupe de paramètres de base de données personnalisé.
+ Si votre instance de base de données RDS pour PostgreSQL n’est pas configurée avec un groupe de paramètres de base de données personnalisé, vous devez en créer un(e) et l’associer à votre instance de base de données RDS pour PostgreSQL. Pour un bref résumé des étapes, consultez [Création et application d’un groupe de paramètres de base de données personnalisé](#PostgreSQL_trusted_language_extension-requirements-create-custom-params).
+ Si votre instance de base de données RDS pour PostgreSQL est déjà configurée à l’aide d’un groupe de paramètres de base de données personnalisé, vous pouvez configurer Trusted Language Extensions. Pour en savoir plus, consultez [Configuration de Trusted Language Extensions dans votre instance de base de données RDS for PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
## Création et application d’un groupe de paramètres de base de données personnalisé
Utilisez les étapes suivantes pour créer un groupe de paramètres de base de données personnalisé et configurer votre instance de base de données RDS pour PostgreSQL afin de l’utiliser.
### Console
**Pour créer un groupe de paramètres de base de données personnalisé et l'utiliser avec votre instance de RDS pour 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. Choisissez Parameter groups (Groupes de paramètres) dans le menu Amazon RDS.
1. Choisissez **Créer un groupe de paramètres**.
1. Dans la page **Parameter group details** (Détails des groupes de paramètres), entrez les informations suivantes.
+ Pour **Parameter group family** (Famille de groupes de paramètres), choisissez postgres14.
+ Pour **Type**, choisissez DB Parameter Group (Groupe de paramètres de base de données).
+ Pour **Group name** (Nom du groupe), attribuez un nom significatif à votre groupe de paramètres dans le contexte de vos opérations.
+ Pour **Description**, entrez une description utile afin que les autres membres de votre équipe puissent la trouver facilement.
1. Choisissez **Créer**. Votre groupe de paramètres de base de données personnalisé est créé dans votre Région AWS. Vous pouvez désormais modifier votre instance de base de données RDS pour PostgreSQL afin de l’utiliser dans les étapes suivantes.
1. Choisissez **Databases** (Bases de données) dans le menu Amazon RDS.
1. Choisissez l’instance de base de données RDS pour PostgreSQL que vous souhaitez utiliser avec TLE parmi les éléments répertoriés, puis choisissez **Modify** (Modifier).
1. Dans la page Modify DB instance settings (Modifier les paramètres d’instance de base de données), recherchez **Database options** (Options de base de données) dans la section Additional configuration (Configuration supplémentaire) et choisissez votre groupe de paramètres de base de données personnalisé dans le sélecteur.
1. Choisissez **Continue** (Continuer) pour enregistrer la modification.
1. Choisissez **Apply immediately** (Appliquer immédiatement) afin de continuer à configurer l’instance de base de données RDS pour PostgreSQL pour utiliser TLE.
Pour continuer à configurer votre système pour Trusted Language Extensions, consultez [Configuration de Trusted Language Extensions dans votre instance de base de données RDS for PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
Pour plus d’informations sur l’utilisation de groupes de paramètres de base de données, consultez [Groupes de paramètres de base de données pour les instances de base de données Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
### AWS CLI
Vous pouvez éviter de spécifier l’argument `--region` lorsque vous utilisez des commandes CLI en configurant votre AWS CLI avec votre Région AWS par défaut. Pour plus d’informations, consultez [Principes de base de la configuration](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) dans le *guide de l’utilisateur AWS Command Line Interface *.
**Pour créer un groupe de paramètres de base de données personnalisé et l'utiliser avec votre instance de RDS pour PostgreSQL**
1. Utilisez la [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI commande pour créer un groupe de paramètres de base de données personnalisé basé sur pour votre. Région AWS
Pour Linux, macOS ou Unix :
```
aws rds create-db-parameter-group \
--region aws-region \
--db-parameter-group-name custom-params-for-pg-tle \
--db-parameter-group-family postgres14 \
--description "My custom DB parameter group for Trusted Language Extensions"
```
Pour Windows :
```
aws rds create-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name custom-params-for-pg-tle ^
--db-parameter-group-family postgres14 ^
--description "My custom DB parameter group for Trusted Language Extensions"
```
Votre groupe de paramètres de base de données personnalisé est disponible dans votre Région AWS. Vous pouvez donc modifier l’instance de base de données RDS pour PostgreSQL afin de l’utiliser.
1. Utilisez la [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) AWS CLI commande pour appliquer votre groupe de paramètres de base de données personnalisé à . votre instance de base de données RDS pour PostgreSQL. Cette commande redémarre immédiatement l’instance active.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--region aws-region \
--db-instance-identifier your-instance-name \
--db-parameter-group-name custom-params-for-pg-tle \
--apply-immediately
```
Pour Windows :
```
aws rds modify-db-instance ^
--region aws-region ^
--db-instance-identifier your-instance-name ^
--db-parameter-group-name custom-params-for-pg-tle ^
--apply-immediately
```
Pour continuer à configurer votre système pour Trusted Language Extensions, consultez [Configuration de Trusted Language Extensions dans votre instance de base de données RDS for PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
Pour plus d'informations, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
# Configuration de Trusted Language Extensions dans votre instance de base de données RDS for PostgreSQL
Les étapes suivantes supposent que votre instance de base de données RDS for PostgreSQL est associée à un groupe de paramètres de base de données personnalisé. Vous pouvez utiliser la AWS Management Console ou AWS CLI pour effectuer ces étapes.
Lorsque vous configurez Trusted Language Extensions dans votre instance de base de données RDS for PostgreSQL, vous l'installez dans une base de données spécifique à l'usage des utilisateurs de base de données autorisés sur cette base de données.
## console
**Pour configurer Trusted Language Extensions**
Effectuez les étapes suivantes à l'aide d'un compte membre du groupe (rôle) `rds_superuser`.
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le volet de navigation, choisissez votre instance de base de données RDS for PostgreSQL.
1. Ouvrez l'onglet **Configuration** pour votre Instance de base de données RDS for PostgreSQL. Parmi les détails de l'instance, trouvez le lien **Groupe de paramètres**.
1. Cliquez sur le lien pour ouvrir les paramètres personnalisés associés à votre Instance de base de données RDS for PostgreSQL.
1. Dans le champ de recherche **Parameters** (Paramètres), tapez `shared_pre` pour trouver le paramètre `shared_preload_libraries`.
1. Choisissez **Edit parameters** (Modifier les paramètres) pour accéder aux valeurs des propriétés.
1. Ajoutez `pg_tle` à la liste dans le champ **Values** (Valeurs). Utilisez une virgule pour séparer les éléments de la liste de valeurs.
![\[Image du paramètre shared_preload_libraries avec pg_tle ajouté.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pg_tle.png)
1. Redémarrez l'instance de base de données RDS for PostgreSQL afin que vos modifications du paramètre `shared_preload_libraries` prennent effet.
1. Lorsque l'instance est disponible, vérifiez que `pg_tle` a été initialisé. Utilisez `psql` pour vous connecter à l'instance de base de données RDS for PostgreSQL, puis exécutez la commande suivante.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
1. Une fois l'extension `pg_tle` initialisée, vous pouvez maintenant créer l'extension.
```
CREATE EXTENSION pg_tle;
```
Vous pouvez vérifier que l'extension est installée en utilisant la métacommande `psql` suivante.
```
labdb=> \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+--------------------------------------------
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
```
1. Accordez le rôle `pgtle_admin` au nom d'utilisateur principal que vous avez créé pour votre instance de base de données RDS for PostgreSQL lors de sa configuration. Si vous avez accepté la valeur par défaut, il s'agit de `postgres`.
```
labdb=> GRANT pgtle_admin TO postgres;
GRANT ROLE
```
Vous pouvez vérifier que l'octroi a eu lieu à l'aide de la métacommande `psql`, comme illustré dans l'exemple suivant. Seuls les rôles `pgtle_admin` et `postgres` sont affichés dans la sortie. Pour plus d'informations, consultez [Comprendre le rôle rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md).
```
labdb=> \du
List of roles
Role name | Attributes | Member of
-----------------+---------------------------------+-----------------------------------
pgtle_admin | Cannot login | {}
postgres | Create role, Create DB +| {rds_superuser,pgtle_admin}
| Password valid until infinity |...
```
1. Fermez la session `psql` à l'aide de la métacommande `\q`.
```
\q
```
Pour commencer à créer des extensions TLE, consultez [Exemple : création d'une extension de langage approuvé utilisant SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example).
## AWS CLI
Vous pouvez éviter de spécifier l'argument `--region` lorsque vous utilisez des commandes CLI en configurant votre AWS CLI avec votre Région AWS par défaut. Pour plus d'informations, consultez [Configuration basics](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) (Principes de base de la configuration) dans le *guide de l'utilisateur AWS Command Line Interface*.
**Pour configurer Trusted Language Extensions**
1. Utilisez la commande AWS CLI [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) pour ajouter `pg_tle` au paramètre `shared_preload_libraries`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pg_tle,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilisez la commande AWS CLI [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance) pour redémarrer l'instance de base de données RDS for PostgreSQL et initialiser la bibliothèque `pg_tle`.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Lorsque l'instance est disponible, vous pouvez vérifier que `pg_tle` a été initialisé. Utilisez `psql` pour vous connecter à l'instance de base de données RDS for PostgreSQL, puis exécutez la commande suivante.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
Une fois `pg_tle` initialisé, vous pouvez maintenant créer l'extension.
```
CREATE EXTENSION pg_tle;
```
1. Accordez le rôle `pgtle_admin` au nom d'utilisateur principal que vous avez créé pour votre instance de base de données RDS for PostgreSQL lors de sa configuration. Si vous avez accepté la valeur par défaut, il s'agit de `postgres`.
```
GRANT pgtle_admin TO postgres;
GRANT ROLE
```
1. Fermez la session `psql` comme suit.
```
labdb=> \q
```
Pour commencer à créer des extensions TLE, consultez [Exemple : création d'une extension de langage approuvé utilisant SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example).
# Présentation de Trusted Language Extensions pour PostgreSQL
Trusted Language Extensions pour PostgreSQL est une extension PostgreSQL que vous installez dans votre instance de base de données RDS for PostgreSQL de la même manière que vous configurez les autres extensions PostgreSQL. Dans l'image suivante d'un exemple de base de données dans l'outil client pgAdmin, vous pouvez voir certains des composants incluant l'extension `pg_tle`.
![\[Image montrant certains composants du kit de développement TLE.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/apg-pg_tle-installed-view-in-pgAdmin.png)
Vous pouvez voir les détails suivants.
1. Le kit de développement Trusted Language Extensions (TLE) pour PostgreSQL est fourni en tant qu'extension `pg_tle`. En tant que tel, `pg_tle` est ajouté aux extensions disponibles pour la base de données dans laquelle il est installé.
1. TLE a son propre schéma, `pgtle`. Ce schéma contient des fonctions d'assistance (3) pour installer et gérer les extensions que vous créez.
1. TLE fournit plus d'une douzaine de fonctions d'assistance pour installer, enregistrer et gérer vos extensions. Pour en savoir plus sur ces fonctions, consultez [Référence de fonction pour Trusted Language Extensions pour PostgreSQL](PostgreSQL_trusted_language_extension-functions-reference.md).
L'extension `pg_tle` comprend les autres composants suivants :
+ **Le rôle `pgtle_admin`** : le rôle `pgtle_admin` est créé lors de l'installation de l'extension `pg_tle`. Ce rôle est privilégié et doit être traité comme tel. Nous vous recommandons vivement de respecter le principe du *moindre privilège* lorsque vous accordez le rôle `pgtle_admin` aux utilisateurs de base de données. En d'autres termes, accordez le rôle `pgtle_admin` uniquement aux utilisateurs de base de données autorisés à créer, installer et gérer de nouvelles extensions TLE, telles que `postgres`.
+ **La table `pgtle.feature_info`** : la table `pgtle.feature_info` est une table protégée qui contient des informations sur vos extensions TLE, vos hooks, ainsi que les procédures et fonctions stockées personnalisées qu'ils utilisent. Si vous disposez de privilèges `pgtle_admin`, vous pouvez utiliser les fonctions Trusted Language Extensions suivantes pour ajouter et mettre à jour ces informations dans la table.
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
# Création d'extensions TLE pour RDS for PostgreSQL
Vous pouvez installer toutes les extensions que vous créez avec TLE dans n'importe quelle instance de base de données RDS for PostgreSQL disposant de l'extension `pg_tle`. L'extension `pg_tle` s'applique à la base de données PostgreSQL dans laquelle elle est installée. Les extensions que vous créez à l'aide de TLE sont appliquées à la même base de données.
Utilisez les différentes fonctions `pgtle` pour installer le code qui constitue votre extension TLE. Les fonctions Trusted Language Extensions suivantes nécessitent toutes le rôle `pgtle_admin`.
+ [pgtle.install\$1extension](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_extension)
+ [pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path)
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version)
+ [pgtle.uninstall\$1extension(name)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name)
+ [pgtle.uninstall\$1extension(name, version)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name-version)
+ [pgtle.uninstall\$1extension\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension_if_exists)
+ [pgtle.uninstall\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path)
+ [pgtle.uninstall\$1update\$1path\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path_if_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
## Exemple : création d'une extension de langage approuvé utilisant SQL
L'exemple suivant montre comment créer une extension TLE nommée `pg_distance` et contenant quelques fonctions SQL permettant de calculer des distances à l'aide de différentes formules. Dans la liste, vous trouverez la fonction de calcul de la distance de Manhattan et la fonction de calcul de la distance euclidienne. Pour plus d'informations sur la différence entre ces formules, consultez [Taxicab geometry](https://en.wikipedia.org/wiki/Taxicab_geometry) (Géométrie de Manhattan) et [Euclidean geometry](https://en.wikipedia.org/wiki/Euclidean_geometry) (Géométrie euclidienne) sur Wikipedia.
Vous pouvez utiliser cet exemple dans votre propre instance de base de données RDS for PostgreSQL si vous disposez de l'extension `pg_tle` configurée comme indiqué dans [Configuration de Trusted Language Extensions dans votre instance de base de données RDS for PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
**Note**
Vous devez disposer des privilèges du rôle `pgtle_admin` pour suivre cette procédure.
**Pour créer l'exemple d'extension TLE**
Les étapes suivantes utilisent un exemple de base de données nommé `labdb`. Cette base de données appartient à l'utilisateur principal `postgres`. Le rôle `postgres` possède également les autorisations du rôle `pgtle_admin`.
1. Utilisez `psql` pour vous connecter à Instance de base de données RDS pour PostgreSQL.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Créez une extension TLE nommée `pg_distance` en copiant le code suivant et en le collant dans votre console de session `psql`.
```
SELECT pgtle.install_extension
(
'pg_distance',
'0.1',
'Distance functions for two points',
$_pg_tle_$
CREATE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL;
CREATE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL;
CREATE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL;
$_pg_tle_$
);
```
Vous devez voir la sortie suivante.
```
install_extension
---------------
t
(1 row)
```
Les artefacts qui constituent l'extension `pg_distance` sont désormais installés dans votre base de données. Ces artefacts incluent le fichier de contrôle et le code de l'extension, qui sont des éléments qui doivent être présents pour que l'extension puisse être créée à l'aide de la commande `CREATE EXTENSION`. En d'autres termes, il vous reste à créer l'extension pour mettre ses fonctions à la disposition des utilisateurs de la base de données.
1. Pour créer cette extension, utilisez la commande `CREATE EXTENSION` comme vous le feriez pour toute autre extension. Comme pour les autres extensions, l'utilisateur de la base de données doit disposer des autorisations `CREATE` dans la base de données.
```
CREATE EXTENSION pg_distance;
```
1. Pour tester l'extension TLE `pg_distance`, vous pouvez l'utiliser pour calculer la [distance de Manhattan](https://en.wikipedia.org/wiki/Taxicab_geometry) entre quatre points.
```
labdb=> SELECT manhattan_dist(1, 1, 5, 5);
8
```
Pour calculer la [distance euclidienne](https://en.wikipedia.org/wiki/Euclidean_geometry) entre le même ensemble de points, vous pouvez utiliser ce qui suit.
```
labdb=> SELECT euclidean_dist(1, 1, 5, 5);
5.656854249492381
```
L'extension `pg_distance` charge les fonctions dans la base de données et les met à la disposition de tous les utilisateurs dotés d'autorisations sur la base de données.
## Modification de votre extension TLE
Pour améliorer les performances des requêtes pour les fonctions incluses dans cette extension TLE, ajoutez les deux attributs PostgreSQL suivants à leurs spécifications.
+ `IMMUTABLE` : l'attribut `IMMUTABLE` garantit que l'optimiseur de requêtes peut utiliser des optimisations pour améliorer les temps de réponse aux requêtes. Pour plus d'informations, consultez [Function Volatility Categories](https://www.postgresql.org/docs/current/xfunc-volatility.html) (Catégories de volatilité des fonctions) dans la documentation PostgreSQL.
+ `PARALLEL SAFE` : l'attribut `PARALLEL SAFE` est un autre attribut qui permet à PostgreSQL d'exécuter la fonction en mode parallèle. Pour plus d’informations, consultez [CREATE FUNCTION](https://www.postgresql.org/docs/current/sql-createfunction.html) dans la documentation PostgreSQL.
Dans l'exemple suivant, vous pouvez voir comment la fonction `pgtle.install_update_path` est utilisée pour ajouter ces attributs à chaque fonction afin de créer une version `0.2` de l'extension TLE `pg_distance`. Pour plus d’informations sur cette fonction, consultez [pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path). Vous devez avoir le rôle `pgtle_admin` pour effectuer cette tâche.
**Pour mettre à jour une extension TLE existante et spécifier la version par défaut**
1. Connectez-vous à l'instance de base de données RDS for PostgreSQL à l'aide de `psql` ou d'un autre outil client, tel que pgAdmin.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Modifiez l'extension TLE existante en copiant le code suivant et en le collant dans votre console de session `psql`.
```
SELECT pgtle.install_update_path
(
'pg_distance',
'0.1',
'0.2',
$_pg_tle_$
CREATE OR REPLACE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
$_pg_tle_$
);
```
Vous voyez une réponse similaire à la suivante.
```
install_update_path
---------------------
t
(1 row)
```
Vous pouvez faire de cette version de l'extension la version par défaut, afin que les utilisateurs de base de données n'aient pas à spécifier de version lorsqu'ils créent ou mettent à jour l'extension dans leur base de données.
1. Pour spécifier que la version modifiée (version 0.2) de votre extension TLE est la version par défaut, utilisez la fonction `pgtle.set_default_version` comme indiqué dans l'exemple suivant.
```
SELECT pgtle.set_default_version('pg_distance', '0.2');
```
Pour plus d’informations sur cette fonction, consultez [pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version).
1. Une fois le code en place, vous pouvez mettre à jour l'extension TLE installée de la manière habituelle, en utilisant la commande `ALTER EXTENSION ... UPDATE`, comme indiqué ici :
```
ALTER EXTENSION pg_distance UPDATE;
```
# Suppression de vos extensions TLE d'une base de données
Vous pouvez supprimer vos extensions TLE en utilisant la commande `DROP EXTENSION` de la même manière que vous le feriez pour les autres extensions PostgreSQL. La suppression de l'extension ne supprime pas les fichiers d'installation qui composent l'extension et qui permettent aux utilisateurs de la recréer. Pour supprimer l'extension et ses fichiers d'installation, effectuez la procédure en deux étapes suivante.
**Pour supprimer l'extension TLE et supprimer ses fichiers d'installation**
1. Utilisez `psql` ou un autre outil client pour vous connecter à l'instance de base de données RDS for PostgreSQL..
```
psql --host=.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. Supprimez l'extension comme vous le feriez pour n'importe quelle extension PostgreSQL.
```
DROP EXTENSION your-TLE-extension
```
Par exemple, si vous créez l'extension `pg_distance` comme détaillé dans [Exemple : création d'une extension de langage approuvé utilisant SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example), vous pouvez la supprimer comme suit.
```
DROP EXTENSION pg_distance;
```
Vous voyez une sortie confirmant que l'extension a été supprimée, comme suit.
```
DROP EXTENSION
```
À ce stade, l'extension n'est plus active dans la base de données. Cependant, ses fichiers d'installation et son fichier de contrôle sont toujours disponibles dans la base de données, ce qui permet aux utilisateurs de la base de données de recréer l'extension s'ils le souhaitent.
+ Si vous souhaitez garder intacts les fichiers d'extension afin que les utilisateurs de la base de données puissent créer votre extension TLE, vous pouvez vous arrêter ici.
+ Pour supprimer tous les fichiers qui composent l'extension, passez à l'étape suivante.
1. Pour supprimer tous les fichiers d'installation de votre extension, utilisez la fonction `pgtle.uninstall_extension`. Cette fonction supprime tous les fichiers de code et de contrôle relatifs à votre extension.
```
SELECT pgtle.uninstall_extension('your-tle-extension-name');
```
Par exemple, pour supprimer tous les fichiers d'installation `pg_distance`, utilisez la commande suivante.
```
SELECT pgtle.uninstall_extension('pg_distance');
uninstall_extension
---------------------
t
(1 row)
```
# Désinstallation de Trusted Language Extensions pour PostgreSQL
Si vous ne souhaitez plus créer vos propres extensions TLE à l'aide de TLE, vous pouvez supprimer l'extension `pg_tle` et supprimer tous les artefacts. Cette action inclut la suppression de toutes les extensions TLE de la base de données et la suppression du schéma `pgtle`.
**Pour supprimer l'extension `pg_tle` et son schéma d'une base de données**
1. Utilisez `psql` ou un autre outil client pour vous connecter à l'instance de base de données RDS for PostgreSQL..
```
psql --host=.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. Supprimez l'extension `pg_tle` de la base de données. Si vos propres extensions TLE s'exécutent encore dans la base de données, vous devez les supprimer également. Pour ce faire, vous pouvez utiliser le mot clé `CASCADE`, comme illustré ci-dessous.
```
DROP EXTENSION pg_tle CASCADE;
```
Si l'extension `pg_tle` n'est toujours pas active dans la base de données, vous n'avez pas besoin d'utiliser le mot clé `CASCADE`.
1. Supprimez le schéma `pgtle`. Cette action supprime toutes les fonctions de gestion de la base de données.
```
DROP SCHEMA pgtle CASCADE;
```
La commande renvoie ce qui suit une fois le processus terminé.
```
DROP SCHEMA
```
L'extension `pg_tle`, son schéma et ses fonctions, ainsi que tous les artefacts sont supprimés. Pour créer de nouvelles extensions à l'aide de TLE, répétez la procédure de configuration. Pour de plus amples informations, consultez [Configuration de Trusted Language Extensions dans votre instance de base de données RDS for PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
# Utilisation des hooks PostgreSQL avec vos extensions TLE
Un *hook* est un mécanisme de rappel disponible dans PostgreSQL qui permet aux développeurs d'appeler des fonctions personnalisées ou d'autres routines lors d'opérations de base de données normales. Le kit de développement TLE prend en charge les hooks PostgreSQL afin que vous puissiez intégrer des fonctions personnalisées au comportement PostgreSQL au moment de l'exécution. Par exemple, vous pouvez utiliser un hook pour associer le processus d'authentification à votre propre code personnalisé, ou pour modifier le processus de planification et d'exécution des requêtes en fonction de vos besoins spécifiques.
Vos extensions TLE peuvent utiliser des hooks. Si un hook a une portée globale, il s'applique à toutes les bases de données. Par conséquent, si votre extension TLE utilise un hook global, vous devez créer votre extension TLE dans toutes les bases de données auxquelles vos utilisateurs peuvent accéder.
Lorsque vous utilisez l'extension `pg_tle` pour créer votre propre kit Trusted Language Extensions, vous pouvez utiliser les hooks disponibles à partir d'une API SQL pour développer les fonctions de votre extension. Vous devez enregistrer tous les hooks avec `pg_tle`. Pour certains hooks, vous devrez peut-être également définir différents paramètres de configuration. Par exemple, le hook de vérification `passcode` peut être activé, désactivé ou requis. Pour plus d'informations sur les exigences spécifiques relatives aux hooks `pg_tle` disponibles, consultez [Référence des hooks pour Trusted Language Extensions pour PostgreSQL](PostgreSQL_trusted_language_extension-hooks-reference.md).
## Exemple : création d'une extension utilisant un hook PostgreSQL
L'exemple présenté dans cette section utilise un hook PostgreSQL pour vérifier le mot de passe fourni lors d'opérations SQL spécifiques et empêche les utilisateurs de base de données de définir leurs mots de passe sur l'un de ceux contenus dans la table `password_check.bad_passwords`. La table contient les dix choix de mots de passe les plus couramment utilisés, mais les plus faciles à déchiffrer.
Pour configurer cet exemple dans votre instance de base de données RDS for PostgreSQL, vous devez avoir déjà installé Trusted Language Extensions. Pour en savoir plus, consultez [Configuration de Trusted Language Extensions dans votre instance de base de données RDS for PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
**Pour configurer l'exemple de hook de vérification de mot de passe**
1. Utilisez `psql` pour vous connecter à Instance de base de données RDS for PostgreSQL.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Copiez le code à partir de [Listing du code du hook de vérification de mot de passe](#PostgreSQL_trusted_language_extension-example-hook_code_listing) et collez-le dans votre base de données.
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
Lorsque l'extension a été chargée dans votre base de données, le résultat suivant s'affiche.
```
install_extension
-------------------
t
(1 row)
```
1. Toujours connecté à la base de données, vous pouvez maintenant créer l'extension.
```
CREATE EXTENSION my_password_check_rules;
```
1. Vous pouvez confirmer que l'extension a été créée dans la base de données à l'aide de la métacommande `psql` suivante.
```
\dx
List of installed extensions
Name | Version | Schema | Description
-------------------------+---------+------------+-------------------------------------------------------------
my_password_check_rules | 1.0 | public | Prevent use of any of the top-ten most common bad passwords
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
1. Ouvrez une autre session de terminal pour travailler avec AWS CLI. Vous devez modifier votre groupe de paramètres de base de données personnalisé pour activer le hook de vérification de mot de passe. Pour ce faire, utilisez la commande CLI [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html), comme illustré dans l'exemple suivant.
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
Lorsque le paramètre est activé avec succès, le résultat suivant s'affiche.
```
(
"DBParameterGroupName": "docs-lab-parameters-for-tle"
}
```
L'application de la modification du groupe de paramètres peut prendre quelques minutes. Toutefois, ce paramètre étant dynamique, vous n'avez pas besoin de redémarrer l'instance de base de données RDS for PostgreSQL pour que le paramètre prenne effet.
1. Ouvrez la session `psql` et interrogez la base de données pour vérifier que le hook password\$1check a été activé.
```
labdb=> SHOW pgtle.enable_password_check;
pgtle.enable_password_check
-----------------------------
on
(1 row)
```
Le hook de vérification de mot de passe est désormais actif. Vous pouvez le tester en créant un nouveau rôle et en utilisant l'un des mauvais mots de passe, comme illustré dans l'exemple suivant.
```
CREATE ROLE test_role PASSWORD 'password';
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 21 at RAISE
SQL statement "SELECT password_check.passcheck_hook(
$1::pg_catalog.text,
$2::pg_catalog.text,
$3::pgtle.password_types,
$4::pg_catalog.timestamptz,
$5::pg_catalog.bool)"
```
La sortie a été formatée pour être lisible.
L'exemple suivant montre que le comportement `pgsql` de la métacomcommande interactive `\password` est également affecté par le hook password\$1check.
```
postgres=> SET password_encryption TO 'md5';
SET
postgres=> \password
Enter new password for user "postgres":*****
Enter it again:*****
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 12 at RAISE
SQL statement "SELECT password_check.passcheck_hook($1::pg_catalog.text, $2::pg_catalog.text, $3::pgtle.password_types, $4::pg_catalog.timestamptz, $5::pg_catalog.bool)"
```
Vous pouvez supprimer cette extension TLE et désinstaller ses fichiers sources si vous le souhaitez. Pour de plus amples informations, consultez [Suppression de vos extensions TLE d'une base de donnéesSuppression de vos extensions TLE d'une base de données](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md).
### Listing du code du hook de vérification de mot de passe
L'exemple de code affiché ici définit la spécification de l'extension TLE `my_password_check_rules`. Lorsque vous copiez ce code et que vous le collez dans votre base de données, le code de l'extension `my_password_check_rules` est chargé dans la base de données et le hook `password_check` est enregistré pour être utilisé par l'extension.
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
# Utilisation de types de données personnalisés dans TLE
PostgreSQL prend en charge les commandes permettant d'enregistrer de nouveaux types de base (également appelés types scalaires) pour un traitement efficace des structures de données complexes dans votre base de données. Un type de base vous permet de personnaliser la façon dont les données sont stockées en interne et la façon de les convertir vers et depuis une représentation textuelle externe. Ces types de données personnalisés sont utiles lors de l'extension de PostgreSQL pour prendre en charge des domaines fonctionnels dans lesquels un type intégré tel qu'un nombre ou un texte ne peut pas fournir une sémantique de recherche suffisante.
RDS for PostgreSQL vous permet de créer des types de données personnalisés dans votre extension de langage approuvé et de définir des fonctions qui prennent en charge les opérations SQL et d'index pour ces nouveaux types de données. Les types de données personnalisés sont disponibles pour les versions suivantes :
+ RDS for PostgreSQL 15.4 et versions 15 ultérieures
+ RDS for PostgreSQL 14.9 et versions 14 ultérieures
+ RDS for PostgreSQL 13.12 et versions 13 ultérieures
Pour plus d'informations, consultez [Types de base de langage approuvé](https://github.com/aws/pg_tle/blob/main/docs/09_datatypes.md) (langue française non garantie).
# Référence de fonction pour Trusted Language Extensions pour PostgreSQL
Consultez la documentation de référence suivante sur les fonctions disponibles dans Trusted Language Extensions pour PostgreSQL. Utilisez ces fonctions pour installer, enregistrer, mettre à jour et gérer vos *extensions TLE*, c'est-à-dire les extensions PostgreSQL que vous développez à l'aide du kit de développement Trusted Language Extensions.
**Topics**
+ [
## pgtle.available\$1extensions
](#pgtle.available_extensions)
+ [
## pgtle.available\$1extension\$1versions
](#pgtle.available_extension_versions)
+ [
## pgtle.extension\$1update\$1paths
](#pgtle.extension_update_paths)
+ [
## pgtle.install\$1extension
](#pgtle.install_extension)
+ [
## pgtle.install\$1update\$1path
](#pgtle.install_update_path)
+ [
## pgtle.register\$1feature
](#pgtle.register_feature)
+ [
## pgtle.register\$1feature\$1if\$1not\$1exists
](#pgtle.register_feature_if_not_exists)
+ [
## pgtle.set\$1default\$1version
](#pgtle.set_default_version)
+ [
## pgtle.uninstall\$1extension(name)
](#pgtle.uninstall_extension-name)
+ [
## pgtle.uninstall\$1extension(name, version)
](#pgtle.uninstall_extension-name-version)
+ [
## pgtle.uninstall\$1extension\$1if\$1exists
](#pgtle.uninstall_extension_if_exists)
+ [
## pgtle.uninstall\$1update\$1path
](#pgtle.uninstall_update_path)
+ [
## pgtle.uninstall\$1update\$1path\$1if\$1exists
](#pgtle.uninstall_update_path_if_exists)
+ [
## pgtle.unregister\$1feature
](#pgtle.unregister_feature)
+ [
## pgtle.unregister\$1feature\$1if\$1exists
](#pgtle.unregister_feature_if_exists)
## pgtle.available\$1extensions
La fonction `pgtle.available_extensions` est une fonction à renvoi d'ensemble. Elle renvoie toutes les extensions TLE disponibles dans la base de données. Chaque ligne renvoyée contient des informations sur une seule extension TLE.
### Prototype de fonction
```
pgtle.available_extensions()
```
### Rôle
Aucune.
### Arguments
Aucune.
### Sortie
+ `name` : nom de l'extension TLE.
+ `default_version` : la version de l'extension TLE à utiliser lorsque la commande `CREATE EXTENSION` est appelée sans version spécifiée.
+ `description` : une description plus détaillée de l'extension TLE.
### Exemple d'utilisation
```
SELECT * FROM pgtle.available_extensions();
```
## pgtle.available\$1extension\$1versions
La fonction `available_extension_versions` est une fonction à renvoi d'ensemble. Elle renvoie une liste de toutes les extensions TLE disponibles et de leurs versions. Chaque ligne contient des informations sur une version spécifique de l'extension TLE donnée, y compris si elle nécessite un rôle spécifique.
### Prototype de fonction
```
pgtle.available_extension_versions()
```
### Rôle
Aucune.
### Arguments
Aucune.
### Sortie
+ `name` : nom de l'extension TLE.
+ `version` : version de l'extension TLE.
+ `superuser` : cette valeur est toujours `false` pour vos extensions TLE. Les autorisations nécessaires pour créer l'extension TLE ou la mettre à jour sont les mêmes que pour la création d'autres objets dans la base de données donnée.
+ `trusted` : cette valeur est toujours `false` pour une extension TLE.
+ `relocatable` : cette valeur est toujours `false` pour une extension TLE.
+ `schema` : spécifie le nom du schéma dans lequel l'extension TLE est installée.
+ `requires` : tableau contenant les noms des autres extensions requises par cette extension TLE.
+ `description` : description détaillée de l'extension TLE.
Pour obtenir plus d'informations sur les valeurs de sortie, consultez la section [Packaging Related Objects into an Extension > Extension Files](https://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11) (Packaging des objets connexes dans une extension > Fichiers d'extension) dans la documentation de PostgreSQL.
### Exemple d'utilisation
```
SELECT * FROM pgtle.available_extension_versions();
```
## pgtle.extension\$1update\$1paths
La fonction `extension_update_paths` est une fonction à renvoi d'ensemble. Elle renvoie une liste de tous les chemins de mise à jour possibles pour une extension TLE. Chaque ligne comprend les mises à niveau ou les rétrogradations disponibles pour cette extension TLE.
### Prototype de fonction
```
pgtle.extension_update_paths(name)
```
### Rôle
Aucune.
### Arguments
`name` : nom de l'extension TLE à partir de laquelle obtenir les chemins de mise à niveau.
### Sortie
+ `source` : version source d'une mise à jour.
+ `target` : version cible d'une mise à jour.
+ `path` : chemin de mise à niveau utilisé pour mettre à jour une extension TLE d'une version `source` à une version `target`, par exemple, `0.1--0.2`.
### Exemple d'utilisation
```
SELECT * FROM pgtle.extension_update_paths('your-TLE');
```
## pgtle.install\$1extension
La fonction `install_extension` vous permet d'installer les artefacts qui composent votre extension TLE dans la base de données, après quoi elle peut être créée à l'aide de la commande `CREATE EXTENSION`.
### Prototype de fonction
```
pgtle.install_extension(name text, version text, description text, ext text, requires text[] DEFAULT NULL::text[])
```
### Rôle
Aucune.
### Arguments
+ `name` : nom de l'extension TLE. Cette valeur est utilisée lors d’un appel de `CREATE EXTENSION`.
+ `version` : version de l'extension TLE.
+ `description` : description détaillée de l'extension TLE. Cette description est affichée dans le champ `comment` de `pgtle.available_extensions()`.
+ `ext` : contenu de l'extension TLE. Cette valeur contient des objets tels que des fonctions.
+ `requires` : paramètre facultatif qui spécifie les dépendances pour cette extension TLE. L'extension `pg_tle` est automatiquement ajoutée en tant que dépendance.
Plusieurs de ces arguments sont les mêmes que ceux qui sont inclus dans un fichier de contrôle d'extension pour installer une extension PostgreSQL sur le système de fichiers d'une instance PostgreSQL. Pour plus d'informations, consultez [Extension Files](http://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11) (Fichiers d'extension) dans [Packaging Related Objects into an Extension](https://www.postgresql.org/docs/current/extend-extensions.html) (Packaging des objets connexes dans une extension) de la documentation PostgreSQL.
### Sortie
Cette fonction renvoie `OK` en cas de réussite ou `NULL` en cas d'erreur.
+ `OK` : l'extension TLE a été installée avec succès dans la base de données.
+ `NULL` : l'extension TLE n'a pas été installée dans la base de données.
### Exemple d'utilisation
```
SELECT pgtle.install_extension(
'pg_tle_test',
'0.1',
'My first pg_tle extension',
$_pgtle_$
CREATE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 42;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.install\$1update\$1path
La fonction `install_update_path` fournit un chemin de mise à jour entre deux versions différentes d'une extension TLE. Cette fonction permet aux utilisateurs de votre extension TLE de mettre à jour sa version en utilisant la syntaxe `ALTER EXTENSION ... UPDATE`.
### Prototype de fonction
```
pgtle.install_update_path(name text, fromvers text, tovers text, ext text)
```
### Rôle
`pgtle_admin`
### Arguments
+ `name` : nom de l'extension TLE. Cette valeur est utilisée lors d’un appel de `CREATE EXTENSION`.
+ `fromvers` : version source de l'extension TLE pour la mise à niveau.
+ `tovers` : version de destination de l'extension TLE pour la mise à niveau.
+ `ext` : contenu de la mise à jour. Cette valeur contient des objets tels que des fonctions.
### Sortie
Aucune.
### Exemple d'utilisation
```
SELECT pgtle.install_update_path('pg_tle_test', '0.1', '0.2',
$_pgtle_$
CREATE OR REPLACE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 21;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.register\$1feature
La fonction `register_feature` ajoute la fonctionnalité interne PostgreSQL spécifiée à la table `pgtle.feature_info`. Les hooks PostgreSQL sont un exemple de fonctionnalité interne de PostgreSQL. Le kit de développement Trusted Language Extensions prend en charge l'utilisation des hooks PostgreSQL. Actuellement, cette fonction prend en charge la fonctionnalité suivante.
+ `passcheck` : enregistre le hook de vérification de mot de passe avec votre procédure ou fonction qui personnalise le comportement de vérification de mot de passe de PostgreSQL.
### Prototype de fonction
```
pgtle.register_feature(proc regproc, feature pg_tle_feature)
```
### Rôle
`pgtle_admin`
### Arguments
+ `proc` : nom d'une procédure ou d'une fonction stockée à utiliser pour la fonctionnalité.
+ `feature` : nom de la fonctionnalité `pg_tle` (tel que `passcheck`) à enregistrer avec la fonction.
### Sortie
Aucune.
### Exemple d'utilisation
```
SELECT pgtle.register_feature('pw_hook', 'passcheck');
```
## pgtle.register\$1feature\$1if\$1not\$1exists
La fonction `pgtle.register_feature_if_not_exists` ajoute la fonctionnalité PostgreSQL spécifiée à la table `pgtle.feature_info` et identifie l'extension TLE ou toute autre procédure ou fonction qui utilise la fonctionnalité. Pour plus d'informations sur les hooks et le kit Trusted Language Extensions, consultez [Utilisation des hooks PostgreSQL avec vos extensions TLE](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md).
### Prototype de fonction
```
pgtle.register_feature_if_not_exists(proc regproc, feature pg_tle_feature)
```
### Rôle
`pgtle_admin`
### Arguments
+ `proc` : nom d'une procédure ou d'une fonction stockée qui contient la logique (code) à utiliser comme fonctionnalité pour votre extension TLE. Par exemple, le code `pw_hook`.
+ `feature` : nom de la fonctionnalité PostgreSQL à enregistrer pour la fonction TLE. Actuellement, la seule fonctionnalité disponible est le hook `passcheck`. Pour plus d’informations, consultez [Crochet de vérification du mot de passe (passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook).
### Sortie
Renvoie `true` après l'enregistrement de la fonction pour l'extension spécifiée. Renvoie `false` si la fonctionnalité est déjà enregistrée.
### Exemple d'utilisation
```
SELECT pgtle.register_feature_if_not_exists('pw_hook', 'passcheck');
```
## pgtle.set\$1default\$1version
La fonction `set_default_version` vous permet de spécifier une valeur `default_version` pour votre extension TLE. Vous pouvez utiliser cette fonction pour définir un chemin de mise à niveau et désigner la version comme étant la version par défaut pour votre extension TLE. Lorsque les utilisateurs de la base de données spécifient votre extension TLE dans les commandes `CREATE EXTENSION` et `ALTER EXTENSION ... UPDATE`, cette version de votre extension TLE est créée dans la base de données pour cet utilisateur.
Cette fonction renvoie `true` en cas de réussite. Si l'extension TLE spécifiée dans l'argument `name` n'existe pas, la fonction renvoie une erreur. De même, si la `version` de l'extension TLE n'existe pas, elle renvoie une erreur.
### Prototype de fonction
```
pgtle.set_default_version(name text, version text)
```
### Rôle
`pgtle_admin`
### Arguments
+ `name` : nom de l'extension TLE. Cette valeur est utilisée lors d’un appel de `CREATE EXTENSION`.
+ `version` : version de l'extension TLE à définir par défaut.
### Sortie
+ `true` : lorsque la définition de la version par défaut réussit, la fonction renvoie `true`.
+ `ERROR` : renvoie un message d'erreur si une extension TLE avec le nom ou la version spécifiés n'existe pas.
### Exemple d'utilisation
```
SELECT * FROM pgtle.set_default_version('my-extension', '1.1');
```
## pgtle.uninstall\$1extension(name)
La fonction `uninstall_extension` supprime toutes les versions d'une extension TLE d'une base de données. Cette fonction empêche les appels futurs de `CREATE EXTENSION` d'installer l'extension TLE. Si l'extension TLE n'existe pas dans la base de données, une erreur est signalée.
La fonction `uninstall_extension` n'abandonne pas une extension TLE qui est actuellement active dans la base de données. Pour supprimer une extension TLE actuellement active, vous devez appeler explicitement `DROP EXTENSION`.
### Prototype de fonction
```
pgtle.uninstall_extension(extname text)
```
### Rôle
`pgtle_admin`
### Arguments
+ `extname` : nom de l'extension TLE à désinstaller. Ce nom est le même que celui utilisé avec `CREATE EXTENSION` pour charger l'extension TLE à utiliser dans une base de données spécifiée.
### Sortie
Aucune.
### Exemple d'utilisation
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test');
```
## pgtle.uninstall\$1extension(name, version)
La fonction `uninstall_extension(name, version)` supprime la version spécifiée de l'extension TLE de la base de données. Cette fonction empêche `CREATE EXTENSION` et `ALTER EXTENSION` d'installer ou de mettre à jour une extension TLE à la version spécifiée. Cette fonction supprime également tous les chemins de mise à jour pour la version spécifiée de l'extension TLE. Cette fonction ne désinstallera pas l'extension TLE si elle est actuellement active dans la base de données. Vous devez appeler explicitement `DROP EXTENSION` pour retirer l'extension TLE. Pour désinstaller toutes les versions d'une extension TLE, consultez [pgtle.uninstall\$1extension(name)](#pgtle.uninstall_extension-name).
### Prototype de fonction
```
pgtle.uninstall_extension(extname text, version text)
```
### Rôle
`pgtle_admin`
### Arguments
+ `extname` : nom de l'extension TLE. Cette valeur est utilisée lors d'un appel de `CREATE EXTENSION`.
+ `version` : la version de l'extension TLE à désinstaller de la base de données.
### Sortie
Aucune.
### Exemple d'utilisation
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test', '0.2');
```
## pgtle.uninstall\$1extension\$1if\$1exists
La fonction `uninstall_extension_if_exists` supprime toutes les versions d'une extension TLE d'une base de données spécifiée. Si l'extension TLE n'existe pas, la fonction ne renvoie rien (aucun message d'erreur n'est affiché). Si l'extension spécifiée est actuellement active dans une base de données, cette fonction ne la supprime pas. Vous devez explicitement appeler `DROP EXTENSION` pour supprimer l'extension TLE avant d'utiliser cette fonction pour désinstaller ses artefacts.
### Prototype de fonction
```
pgtle.uninstall_extension_if_exists(extname text)
```
### Rôle
`pgtle_admin`
### Arguments
+ `extname` : nom de l'extension TLE. Cette valeur est utilisée lors d’un appel de `CREATE EXTENSION`.
### Sortie
La fonction `uninstall_extension_if_exists` renvoie `true` après avoir désinstallé l'extension spécifiée. Si l'extension spécifiée n'existe pas, la fonction renvoie `false`.
+ `true` : renvoie `true` après la désinstallation de l'extension TLE.
+ `false` : renvoie `false` lorsque l'extension TLE n'existe pas dans la base de données.
### Exemple d'utilisation
```
SELECT * FROM pgtle.uninstall_extension_if_exists('pg_tle_test');
```
## pgtle.uninstall\$1update\$1path
La fonction `uninstall_update_path` supprime le chemin de mise à jour spécifique pour l'extension TLE. Cela empêche `ALTER EXTENSION ... UPDATE TO` de l'utiliser comme chemin de mise à jour.
Si l'extension TLE est actuellement utilisée par l'une des versions de ce chemin de mise à jour, elle reste dans la base de données.
Si le chemin de mise à jour spécifié n'existe pas, cette fonction génère une erreur.
### Prototype de fonction
```
pgtle.uninstall_update_path(extname text, fromvers text, tovers text)
```
### Rôle
`pgtle_admin`
### Arguments
+ `extname` : nom de l'extension TLE. Cette valeur est utilisée lors de l'appel de `CREATE EXTENSION`.
+ `fromvers` : la version source de l'extension TLE utilisée sur le chemin de mise à jour.
+ `tovers` : la version destination de l'extension TLE utilisée sur le chemin de mise à jour.
### Sortie
Aucune.
### Exemple d'utilisation
```
SELECT * FROM pgtle.uninstall_update_path('pg_tle_test', '0.1', '0.2');
```
## pgtle.uninstall\$1update\$1path\$1if\$1exists
La fonction `uninstall_update_path_if_exists` est similaire à `uninstall_update_path`, car elle supprime le chemin de mise à jour spécifié d'une extension TLE. Toutefois, si le chemin de mise à jour n'existe pas, cette fonction ne renvoie pas de message d'erreur. Au lieu de cela, la fonction renvoie `false`.
### Prototype de fonction
```
pgtle.uninstall_update_path_if_exists(extname text, fromvers text, tovers text)
```
### Rôle
`pgtle_admin`
### Arguments
+ `extname` : nom de l'extension TLE. Cette valeur est utilisée lors de l'appel de `CREATE EXTENSION`.
+ `fromvers` : la version source de l'extension TLE utilisée sur le chemin de mise à jour.
+ `tovers` : la version destination de l'extension TLE utilisée sur le chemin de mise à jour.
### Sortie
+ `true` : la fonction a mis à jour avec succès le chemin pour l'extension TLE.
+ `false` : la fonction n'a pas pu mettre à jour le chemin pour l'extension TLE.
### Exemple d'utilisation
```
SELECT * FROM pgtle.uninstall_update_path_if_exists('pg_tle_test', '0.1', '0.2');
```
## pgtle.unregister\$1feature
La fonction `unregister_feature` permet de supprimer les fonctions qui ont été enregistrées pour utiliser des fonctionnalités `pg_tle`, telles que les hooks. Pour obtenir des informations sur l'enregistrement d'une fonctionnalité, consultez [pgtle.register\$1feature](#pgtle.register_feature).
### Prototype de fonction
```
pgtle.unregister_feature(proc regproc, feature pg_tle_features)
```
### Rôle
`pgtle_admin`
### Arguments
+ `proc` : nom d'une fonction stockée à enregistrer avec une fonctionnalité `pg_tle`.
+ `feature` : nom de la fonctionnalité `pg_tle` à enregistrer avec la fonction. Par exemple, `passcheck` est une fonctionnalité qui peut être enregistrée pour être utilisée par les extensions Trusted Language Extensions (TLE) que vous développez. Pour plus d’informations, consultez [Crochet de vérification du mot de passe (passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook).
### Sortie
Aucune.
### Exemple d'utilisation
```
SELECT * FROM pgtle.unregister_feature('pw_hook', 'passcheck');
```
## pgtle.unregister\$1feature\$1if\$1exists
La fonction `unregister_feature` permet de supprimer les fonctions qui ont été enregistrées pour utiliser des fonctionnalités `pg_tle`, telles que les hooks. Pour plus d’informations, consultez [Utilisation des hooks PostgreSQL avec vos extensions TLE](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md). Renvoie `true` après avoir réussi à annuler l'enregistrement de la fonctionnalité. Renvoie `false` si la fonctionnalité n'a pas été enregistrée.
Pour obtenir des informations sur l'enregistrement de fonctionnalités `pg_tle` pour vos extensions TLE, consultez [pgtle.register\$1feature](#pgtle.register_feature).
### Prototype de fonction
```
pgtle.unregister_feature_if_exists('proc regproc', 'feature pg_tle_features')
```
### Rôle
`pgtle_admin`
### Arguments
+ `proc` : nom de la fonction stockée qui a été enregistrée pour inclure une fonctionnalité `pg_tle`.
+ `feature` : nom de la fonctionnalité `pg_tle` qui a été enregistrée avec l'extension de langage approuvé.
### Sortie
Renvoie `true` ou `false`, comme suit.
+ `true` : la fonction a annulé l'enregistrement de la fonctionnalité à l'extension.
+ `false` : la fonction n'a pas pu annuler l'enregistrement de la fonctionnalité à l'extension TLE.
### Exemple d'utilisation
```
SELECT * FROM pgtle.unregister_feature_if_exists('pw_hook', 'passcheck');
```
# Référence des hooks pour Trusted Language Extensions pour PostgreSQL
Le kit Trusted Language Extensions pour PostgreSQL prend en charge les hooks PostgreSQL. Un *hook* est un mécanisme de rappel interne mis à la disposition des développeurs pour étendre les fonctionnalités de base de PostgreSQL. En utilisant des hooks, les développeurs peuvent implémenter leurs propres fonctions ou procédures à utiliser lors de diverses opérations de base de données, modifiant ainsi le comportement de PostgreSQL. Par exemple, vous pouvez utiliser un hook `passcheck` pour personnaliser la façon dont PostgreSQL gère les mots de passe fournis lors de la création ou de la modification de mots de passe pour les utilisateurs (rôles).
Consultez la documentation suivante pour en savoir plus sur le hook passcheck disponible pour vos extensions TLE. Pour en savoir plus sur les hooks disponibles, y compris le hook d’authentification client, consultez [Hooks Trusted Language Extensions](https://github.com/aws/pg_tle/blob/main/docs/04_hooks.md).
## Crochet de vérification du mot de passe (passcheck)
Le crochet `passcheck` permet de personnaliser le comportement de PostgreSQL pendant le processus de vérification du mot de passe pour les commandes SQL et la métacommande `psql`suivantes.
+ `CREATE ROLE username ...PASSWORD` : pour plus d’informations, consultez [CREATE USER](https://www.postgresql.org/docs/current/sql-createrole.html) (CRÉER UN RÔLE) dans la documentation PostgreSQL.
+ `ALTER ROLE username...PASSWORD` : pour plus d’informations, consultez [ALTER ROLE](https://www.postgresql.org/docs/current/sql-alterrole.html) (ALTÉRER UN RÔLE) dans la documentation PostgreSQL.
+ `\password username` : cette métacommande `psql` interactive modifie de manière sécurisée le mot de passe de l’utilisateur spécifié en hachant le mot de passe avant d’utiliser la syntaxe `ALTER ROLE ... PASSWORD` de manière transparente. La métacommande est un encapsuleur sécurisé pour la commande `ALTER ROLE ... PASSWORD`, et le crochet s’applique donc au comportement de la métacommande `psql`.
Pour obtenir un exemple, consultez [Listing du code du hook de vérification de mot de passe](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md#PostgreSQL_trusted_language_extension-example-hook_code_listing).
**Contents**
+ [
### Prototype de fonction
](#passcheck_hook-prototype)
+ [
### Arguments
](#passcheck_hook-arguments)
+ [
### Configuration
](#passcheck_hook-configuration)
+ [
### Notes d’utilisation
](#passcheck_hook-usage)
### Prototype de fonction
```
passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
```
### Arguments
Une fonction de crochet `passcheck` accepte les arguments suivants.
+ `username` : nom (sous forme de texte) du rôle (nom d’utilisateur) qui définit un mot de passe.
+ `password` : texte brut ou mot de passe haché. Le mot de passe saisi doit correspondre au type spécifié dans `password_type`.
+ `password_type` : spécifiez le format `pgtle.password_type` du mot de passe. Ce format peut être l’une des options suivantes.
+ `PASSWORD_TYPE_PLAINTEXT` : un mot de passe en texte brut.
+ `PASSWORD_TYPE_MD5`— Un mot de passe haché à l'aide de l'algorithme MD5 (message digest 5).
+ `PASSWORD_TYPE_SCRAM_SHA_256` : un mot de passe qui a été haché en utilisant l’algorithme SCRAM-SHA-256.
+ `valid_until` : spécifiez l’heure à laquelle le mot de passe devient invalide. Cet argument est facultatif. Si vous utilisez cet argument, spécifiez l’heure comme une valeur `timestamptz`.
+ `valid_null` : si cette valeur booléenne est définie sur `true`, l’option `valid_until` est définie sur `NULL`.
### Configuration
La fonction `pgtle.enable_password_check` contrôle si le crochet passcheck est actif. Le crochet passcheck a trois paramètres possibles.
+ `off` : désactive le crochet de vérification du mot de passe `passcheck`. C’est la valeur par défaut.
+ `on` : active le crochet de vérification du mot de passe `passcode` afin que les mots de passe soient vérifiés dans la table.
+ `require` : nécessite la définition d’un crochet de vérification du mot de passe.
### Notes d’utilisation
Pour activer ou désactiver le crochet `passcheck`, vous devez modifier le groupe de paramètres de base de données personnalisé pour votre instance de base de données RDS pour PostgreSQL.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name your-custom-parameter-group ^
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```