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