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 for PostgreSQL

Amazon RDS for 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, veuillez consulter Utilisation de la fonction autovacuum de PostgreSQL sur Amazon RDS for PostgreSQL. Pour en savoir plus sur les autres tâches DBA courantes, Tâches courantes d'administration de bases de données pour Amazon RDS for PostgreSQL.

RDS for 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_cron pour planifier la maintenance depuis l'instance elle-même. Pour plus d'informations sur les extensions PostgreSQL, veuillez consulter Utilisation des extensions PostgreSQL avec Amazon RDS for PostgreSQL.

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 for 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 for PostgreSQL, veuillez consulter Utilisation des encapsuleurs de données externes pris en charge pour Amazon RDS for PostgreSQL.

Ci-dessous, vous trouverez des informations sur certaines autres fonctionnalités prises en charge par RDS for PostgreSQL.

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 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 dans la documentation de PostgreSQL.

Il existe plusieurs restrictions quant à l'utilisation de déclencheurs d'évènements PostgreSQL sur Amazon RDS. Tel est le cas des éléments suivants :

Grandes pages pour RDS for 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 for PostgreSQL. Vous allouez de grandes pages pour votre application en utilisant des appels à la mémoire partagée mmap ou SYSV. RDS for 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 for 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 pool 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, veuillez consulter Resource Consumption dans la documentation PostgreSQL.

Réplication logique pour Amazon RDS for PostgreSQL

Dès la version 10.4, RDS for PostgreSQL prend en charge la syntaxe SQL de publication et d'abonnement qui a été introduite dans PostgreSQL 10. Pour en savoir plus, veuillez consulter Réplication logique dans la documentation PostgreSQL.

Ci-dessous, vous trouverez des informations sur la configuration de la réplication logique pour une instance de base de données RDS for PostgreSQL.

Compréhension de la réplication logique et du décodage logique

RDS for 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 plus courants pour la réplication logique PostgreSQL sont AWS Database Migration Service ou un hôte géré 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 plus d'informations sur le décodage logique PostgreSQL, consultez la documentation PostgreSQL.

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 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_recvlogical, 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)

Disque RAM pour le stats_temp_directory

Vous pouvez utiliser le paramètre RDS for 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 pour toutes les versions de PostgreSQL sur Amazon RDS.

Avec certaines charges de travail, ce paramètre peut améliorer les performances et réduire les exigences relatives aux I/O. Pour plus d'informations sur le paramètre stats_temp_directory, veuillez consulter la documentation sur PostgreSQL.

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 Utilisation des groupes de paramètres.

Par exemple, la commande d'AWS CLI suivante définit le paramètre de disque RAM à 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é. Étant donné que tout le stockage se trouve sur un seul volume logique, vous ne pouvez pas utiliser d'espaces de table pour le fractionnement ou l'isolement des I/O. 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.

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 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 (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). Pour plus d'informations sur ICU-60, consultez la section Download ICU 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é à télécharger. RDS for 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.

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.

Amazon RDS fournit un ensemble de classements supplémentaires qui trient les points de code Unicode qui correspondent aux caractères LATIN9 en utilisant les tables publiées par IBM, dans l'ordre des points de code d'origine selon la page de code EBCDIC des données sources.

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 et Unicode to LATIN9 collations 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 en pg_collation, mais sont destinés à être utilisés par des outils d'intégration et de migration de données mainframe sur AWS qui mappent les pages de code avec des décalages de points de code spécifiques et nécessitent un traitement spécial dans le classement. En d'autres termes, l'utilisation des classements suivants n'est pas recommandée.

Pour en savoir plus sur la migration des applications d'un environnement mainframe vers AWS, consultez Qu'est-ce qu'AWS Mainframe Modernization ?.

Pour obtenir plus d'informations sur la gestion des classements dans PostgreSQL, consultez la section Collation Support (Prise en charge des classements) dans la documentation de PostgreSQL.