Amazon Relational Database Service
Guide de l'utilisateur

Tâches DBA courantes pour PostgreSQL

Cette section décrit les implémentations de Amazon RDS de certaines tâches d'administration de base de données courantes pour les instances de bases de données exécutant le moteur de base de données PostgreSQL. Pour offrir une expérience de service géré, Amazon RDS ne fournit pas l'accès shell aux instances de base de données et limite l'accès à certaines tables et procédures système qui requièrent des privilèges avancés.

Pour plus d'informations sur l'utilisation de fichiers journaux PostgreSQL sur Amazon RDS, consultez Fichiers journaux de base de données PostgreSQL.

Création de rôles

Lorsque vous créez une instance de base de données, le rôle rds_superuser est affecté au compte du système de l'utilisateur principal que vous avez créé. Le rôle rds_superuser est un rôle Amazon RDS prédéfini semblable au rôle de superutilisateur PostgreSQL (habituellement désigné sous le nom de postgres dans les instances locales), mais limité par certaines restrictions. Tout comme le rôle de superutilisateur PostgreSQL, le rôle rds_superuser dispose du plus grand nombre de privilèges pour votre instance de base de données. Vous ne devriez pas attitrer ce rôle à des utilisateurs, sauf s'ils nécessitent l'accès le plus étendu à l'instance de base de données.

Le rôle rds_superuser permet d'effectuer les opérations suivantes :

  • Ajoutez les extensions qu'il est possible d'utiliser avec Amazon RDS. Pour plus d'informations, consultez Fonctions PostgreSQL prises en charge et la documentation sur PostgreSQL.

  • Gérer les espaces de table, y compris en créer et les supprimer. Pour plus d'informations, consultez la section Tablespaces dans la documentation PostgreSQL.

  • Répertorier tous les utilisateurs auxquels le rôle rds_superuser n'est pas attribué à l'aide de la commande pg_stat_activity et interrompre leur connexion à l'aide des commandes pg_terminate_backend et pg_cancel_backend.

  • Accorder et révoquer le rôle rds_replication pour tous les rôles autres que le rôle rds_superuser. Pour plus d'informations, consultez la section GRANT (ACCORDER) dans la documentation PostgreSQL.

L'exemple suivant montre comment créer un utilisateur puis lui affecter le rôle rds_superuser. Les rôles définis par l'utilisateur, comme rds_superuser, doivent être accordés.

create role testuser with password 'testuser' login; CREATE ROLE grant rds_superuser to testuser; GRANT ROLE

Gestion d'un accès à la base de données PostgreSQL

Dans Amazon RDS pour PostgreSQL, vous pouvez contrôler quels utilisateurs disposent des accès aux bases de données. Dans les environnements PostgreSQL, vous pouvez parfois effectuer ce type de contrôle en modifiant le fichier pg_hba.conf. Vous pouvez plutôt utiliser les autorisations de bases de données dans Amazon RDS.

Les nouvelles bases de données dans PostgreSQL sont toujours créées avec un ensemble de privilèges par défaut. Les privilèges par défaut permettent au PUBLIC (tous les utilisateurs) de se connecter à la base de données et de créer des tableaux temporaires lorsqu'ils sont connectés.

Afin de contrôler les utilisateurs disposant des accès à une base de données particulière dans Amazon RDS, révoquez d'abord les privilèges PUBLIC par défaut. Ensuite, accordez de nouveau les privilèges sur une base plus granulaire. L'exemple de code suivant illustre la marche à suivre.

psql> revoke all on database <database-name> from public; psql> grant connect, temporary on database <database-name> to <user/role name>;

Pour plus d'informations sur les privilèges dans les bases de données PostgreSQL, consultez la commande GRANT dans la documentation PostgreSQL.

Utilisation des paramètres PostgreSQL

Les paramètres PostgreSQL définis pour une instance PostgreSQL locale dans le fichier postgresql.conf sont conservés dans le groupe de paramètres de base de données de votre instance de base de données. Si vous créez une instance de base de données à l'aide du groupe de paramètres par défaut, les paramètres figurent dans un groupe de paramètres appelé default.postgres9.6.

Lorsque vous créez une instance de base de données, les paramètres du groupe de paramètres DB associé sont chargés. Vous ne pouvez pas modifier de valeurs des paramètres en modifiant des valeurs dans le groupe de paramètres. Vous pouvez également modifier des valeurs de paramètres, si vous disposez des privilèges de sécurité nécessaires, en utilisant les commandes ALTER DATABASE, ALTER ROLE et SET. Vous ne pouvez pas utiliser la commande de ligne de commande postgres ou la commande env PGOPTIONS, car vous n'aurez pas accès à l'hôte.

Il peut parfois s'avérer difficile de suivre les paramètres PostgreSQL. Utilisez les commandes suivantes pour répertorier les paramètres actuels et leur valeur par défaut.

select name, setting, boot_val, reset_val, unit from pg_settings order by name;

Pour savoir ce que signifient les valeurs de sortie, consultez la rubrique pg_settings dans la documentation PostgreSQL.

Si les paramètres de mémoire sont définis de manière trop large pour max_connections, shared_buffers ou effective_cache_size, l'instance PostgreSQL ne pourra pas démarrer. Certains paramètres utilisent des unités que vous pouvez ne pas bien connaître. Par exemple, shared_buffers définit le nombre de tampons de mémoire partagée de 8 Ko utilisés par le serveur.

L'erreur suivante est écrite dans le fichier postgres.log lorsque l'instance tente de démarrer, mais des paramètres mal définis empêchent le démarrage.

2013-09-18 21:13:15 UTC::@:[8097]:FATAL: could not map anonymous shared memory: Cannot allocate memory 2013-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.

Il existe deux types de paramètres PostgreSQL : les paramètres statiques et les paramètres dynamiques. Les paramètres statiques nécessitent le redémarrage de l'instance de base de données avant d'être appliqués. Les paramètres dynamiques peuvent être appliqués immédiatement. Le tableau suivant illustre les paramètres que vous pouvez modifier pour une instance de base de données PostgreSQL, ainsi que tous les types de paramètres.

Nom du paramètre

Type d'application

Description

application_name

Dynamique Définit le nom de l'application à indiquer dans les statistiques et les journaux.

array_nulls

Dynamique Autorise l'entrée d'éléments NULL dans les tableaux.

authentication_timeout

Dynamique Définit le délai maximum autorisé pour procéder à l'authentification du client.

autovacuum

Dynamique Démarre le sous-processus autovacuum.

autovacuum_analyze_scale_factor

Dynamique Nombre de tuples insérés, mis à jour ou supprimés avant analyse en tant que partie de reltuples.

autovacuum_analyze_threshold

Dynamique Nombre minimum de tuples insérés, mis à jour ou supprimés avant analyse.

autovacuum_naptime

Dynamique Temps de repos entre les exécutions autovacuum.

autovacuum_vacuum_cost_delay

Dynamique Valeur du coût de retard du processus vacuum en millisecondes, pour le processus autovacuum.

autovacuum_vacuum_cost_limit

Dynamique Coût cumulé qui provoque l'endormissement du processus vacuum, pour le processus autovacuum.

autovacuum_vacuum_scale_factor

Dynamique Nombre de tuples mis à jour ou supprimés avant le processus vacuum en tant que partie de reltuples.

autovacuum_vacuum_threshold

Dynamique Nombre de tuples mis à jour ou supprimés avant le processus vacuum.

backslash_quote

Dynamique Définit si une barre oblique inverse (\) peut être utilisée dans les littéraux de chaîne.

bgwriter_delay

Dynamique Délai d'inactivité entre les tours d'activité du processus d'écriture en arrière-plan.

bgwriter_lru_maxpages

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

Dynamique Multiple de l'utilisation moyenne de tampons à libérer par tour.

bytea_output

Dynamique Configure le format de sortie pour les valeurs de type octets.

check_function_bodies

Dynamique Vérifie les corps des fonctions pendant la fonction CREATE FUNCTION.

checkpoint_completion_target

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

Dynamique Définit la distance maximale dans les segments de journaux entre deux points de vérification automatique de journal WAL.

checkpoint_timeout

Dynamique Définit le temps maximum entre deux points de vérification automatique des WAL.

checkpoint_warning

Dynamique Active les avertissements si des segments de points de vérification sont remplis à une fréquence supérieure à ce paramètre.

client_encoding

Dynamique Définit l'encodage du jeu de caractères du client.

client_min_messages

Dynamique Définit les niveaux des messages envoyés au client.

commit_delay

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

Dynamique Définit le nombre minimum de transactions ouvertes simultanément avant d'atteindre le délai commit_delay.

constraint_exclusion

Dynamique Autorise le planificateur à utiliser des contraintes pour optimiser les requêtes.

cpu_index_tuple_cost

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

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

Dynamique Définit l'estimation faite par le planificateur du coût de traitement de chaque ligne.

cursor_tuple_fraction

Dynamique Définit l'estimation faite par le planificateur de la fraction des lignes d'un curseur qui sera récupérée.

datestyle

Dynamique Définit le format d'affichage des valeurs de type date et heure.

deadlock_timeout

Dynamique Définit le délai d'attente au niveau d'un verrou avant blocage.

debug_pretty_print

Dynamique Indente les affichages des arborescence d'analyse et de planification.

debug_print_parse

Dynamique Enregistre l'arborescence d'analyse de chaque requête.

debug_print_plan

Dynamique Enregistre le plan d'exécution de chaque requête.

debug_print_rewritten

Dynamique Enregistre l'arbre d'interprétation réécrit de chaque requête.

default_statistics_target

Dynamique Définit la cible des statistiques par défaut.

default_tablespace

Dynamique Définit l'espace de table par défaut dans lequel créer des tables et des index.

default_transaction_deferrable

Dynamique Définit le statut reportable des nouvelles transactions.

default_transaction_isolation

Dynamique Définit le niveau d'isolation de transaction de chaque nouvelle transaction.

default_transaction_read_only

Dynamique Définit le statut en lecture seule des nouvelles transactions.

default_with_oids

Dynamique Crée des tables avec des OID par défaut.

effective_cache_size

Dynamique Définit l'estimation faite par le planificateur de la taille du cache du disque.

effective_io_concurrency

Dynamique Nombre de demandes simultanées pouvant être traitées de manière efficace par le sous-système du disque.

enable_bitmapscan

Dynamique Autorise l'utilisation de plans de parcours de bitmap par le planificateur.

enable_hashagg

Dynamique Autorise l'utilisation de plans d'agrégation hachée par le planificateur.

enable_hashjoin

Dynamique Autorise l'utilisation de plans de jointures de hachage par le planificateur.

enable_indexscan

Dynamique Autorise l'utilisation de plans de parcours d'index par le planificateur.

enable_material

Dynamique Autorise l'utilisation de la matérialisation par le planificateur.

enable_mergejoin

Dynamique Autorise l'utilisation de plans de jointures de fusion par le planificateur.

enable_nestloop

Dynamique Autorise l'utilisation de plans de jointures de boucles imbriquées par le planificateur.

enable_seqscan

Dynamique Autorise l'utilisation de plans de parcours séquentiels par le planificateur.

enable_sort

Dynamique Autorise l'utilisation des étapes de tri explicite par le planificateur.

enable_tidscan

Dynamique Autorise l'utilisation de plans de parcours de TID par le planificateur.

escape_string_warning

Dynamique Avertit sur l'utilisation des barres obliques inverses (\) dans des littéraux de chaîne ordinaires.

extra_float_digits

Dynamique Définit le nombre de chiffres affichés pour les valeurs à virgule flottante.

from_collapse_limit

Dynamique Définit la taille FROM-list au-delà de laquelle les sous-requêtes ne sont pas regroupées.

fsync

Dynamique Force la synchronisation des mises à jour sur le disque.

full_page_writes

Dynamique Ecrit les pages complètes dans les WAL lors de la première modification après un point de vérification.

geqo

Dynamique Active l'optimisation génétique des requêtes.

geqo_effort

Dynamique geqo_effort est utilisé pour définir la valeur par défaut pour les autres paramètres GEQO.

geqo_generations

Dynamique GEQO : nombre d'itérations de l'algorithme.

geqo_pool_size

Dynamique GEQO : nombre d'individus au sein d'une population.

geqo_seed

Dynamique GEQO : valeur initiale pour la sélection des chemins au hasard.

geqo_selection_bias

Dynamique GEQO : pression de sélectivité au sein de la population.

geqo_threshold

Dynamique Définit le seuil d'éléments FROM au-delà duquel GEQO est utilisé.

gin_fuzzy_search_limit

Dynamique Définit le résultat maximum autorisé pour la recherche exacte par GIN.

hot_standby_feedback

Dynamique Détermine si une instance de secours envoie des messages de commentaire aux instances principales ou de veille en amont.

intervalstyle

Dynamique Définit le format d'affichage des valeurs de type intervalle.

join_collapse_limit

Dynamique Définit la taille FROM-list au-delà de laquelle les constructions JOIN ne sont pas mises à plat.

lc_messages

Dynamique Définit la langue d'affichage des messages.

lc_monetary

Dynamique Définit la locale à utiliser pour le formatage des montants monétaires.

lc_numeric

Dynamique Définit la locale à utiliser pour le formatage des nombres.

lc_time

Dynamique Définit la locale à utiliser pour le formatage des valeurs de date et d'heure.

log_autovacuum_min_duration

Dynamique Définit la durée minimum d'exécution au-delà de laquelle les actions autovacuum seront enregistrées.

log_checkpoints

Dynamique Enregistre les points de vérification.

log_connections

Dynamique Enregistre toutes les connexions réussies.

log_disconnections

Dynamique Enregistre la fin d'une session, y compris sa durée.

log_duration

Dynamique Enregistre la durée de chaque instruction SQL terminée.

log_error_verbosity

Dynamique Définit la quantité de détails dans les messages enregistrés.

log_executor_stats

Dynamique Ecrit les statistiques de performance de l'exécuteur dans le journal du serveur.

log_filename

Dynamique Définit le modèle de nom de fichier pour les fichiers journaux.

log_hostname

Dynamique Enregistre le nom de l'hôte dans les journaux de connexion.

log_lock_waits

Dynamique Enregistre les longs temps d'attente pour l'acquisition d'un verrou.

log_min_duration_statement

Dynamique Définit la durée minimum d'exécution au-delà de laquelle les instructions seront enregistrées.

log_min_error_statement

Dynamique Déclenche l'enregistrement de toutes les instructions générant une erreur à ce niveau ou à un niveau supérieur.

log_min_messages

Dynamique Définit les niveaux des messages qui sont enregistrés.

log_parser_stats

Dynamique Ecrit les statistiques de performance de l'analyseur dans le journal du serveur.

log_planner_stats

Dynamique Ecrit les statistiques de performance du planificateur dans le journal du serveur.

log_rotation_age

Dynamique Déclenchement de la rotation de fichier journal automatique au-delà d'un délai de N minutes.

log_rotation_size

Dynamique Déclenchement de la rotation de fichier journal automatique au-delà de N kilo-octets.

log_statement

Dynamique Définit le type d'instructions enregistrées.

log_statement_stats

Dynamique Ecrit les statistiques de performance cumulées dans le journal du serveur.

log_temp_files

Dynamique Enregistre l'utilisation des fichiers temporaires dont la taille est supérieure à cette taille en kilo-octets.

maintenance_work_mem

Dynamique Définit la quantité maximum de mémoire que peuvent utiliser les opérations de maintenance.

max_stack_depth

Dynamique Définit la profondeur maximum de la pile, en kilo-octets.

max_standby_archive_delay

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

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_wal_size Statique Définit la taille de journal WAL qui déclenche le point de vérification. Pour PostgreSQL version 9.6 ou antérieure, la taille max_wal_size est exprimée en unités de 16 Mo. Pour PostgreSQL version 10 ou supérieure, la taille max_wal_size est exprimée en unités de 1 Mo.
min_wal_size Statique Définit la taille minimale à laquelle réduire le journal WAL. Pour PostgreSQL version 9.6 ou antérieure, la taille min_wal_size est exprimée en unités de 16 Mo. Pour PostgreSQL version 10 ou supérieure, la taille min_wal_size est exprimée en unités de 1 Mo.

quote_all_identifiers

Dynamique Ajoute des guillemets (") à tous les identificateurs lors de la génération de fragments SQL.

random_page_cost

Dynamique Définit l'estimation faite par le planificateur du coût d'une page de disque extraite de façon non séquentielle.
rds.adaptive_autovacuum Dynamique Règle automatiquement les paramètres d'autovacuum chaque fois que les seuils d'ID de transaction sont dépassés.

rds.log_retention_period

Dynamique Définit la rétention des journaux de telle manière qu'Amazon RDS supprime les journaux PostgreSQL antérieurs à N minutes.
rds.restrict_password_commands Statique Limite la gestion des mots de passe aux utilisateurs auxquels le rôle rds_password 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

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

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

Dynamique Définit le comportement des sessions concernant les déclencheurs et les règles de réécriture.

sql_inheritance

Dynamique Entraîne l'ajout par défaut de sous-tables dans plusieurs commandes.

ssl_renegotiation_limit

Dynamique Définit la quantité de trafic à envoyer et recevoir avant de renégocier les clés de chiffrement.

standard_conforming_strings

Dynamique Entraîne les chaînes ... à traiter littéralement les barres obliques inverses.

statement_timeout

Dynamique Définit la durée maximum de toute instruction.

synchronize_seqscans

Dynamique Active les analyses séquentielles synchronisées.

synchronous_commit

Dynamique Définit le niveau de synchronisation des transactions actuelles.

tcp_keepalives_count

Dynamique Nombre maximum de paquets TCP keepalive.

tcp_keepalives_idle

Dynamique Délai entre les émissions de paquets TCP keepalive.

tcp_keepalives_interval

Dynamique Délai entre les envois de paquets TCP keepalive.

temp_buffers

Dynamique Définit le nombre maximum de tampons temporaires utilisés par chaque session.

temp_tablespaces

Dynamique Définit l'espace de table à utiliser pour les tables et fichiers de tri temporaires.

timezone

Dynamique Définit le fuseau horaire pour l'affichage et l'interprétation de la date et de l'heure.

track_activities

Dynamique Active la collecte d'informations sur l'exécution des commandes.

track_counts

Dynamique Active la collecte de statistiques sur l'activité de la base de données.

track_functions

Dynamique Active la collecte de statistiques au niveau de la fonction sur l'activité de la base de données.

track_io_timing

Dynamique Active la collecte de statistiques de durée sur l'activité I/O de la base de données.

transaction_deferrable

Dynamique Indique si une transaction sérialisable en lecture seule doit être différée jusqu'à ce qu'elle puisse être exécutée sans échec de sérialisation possible.

transaction_isolation

Dynamique Définit le niveau d'isolation des transactions actuelles.

transaction_read_only

Dynamique Définit le statut en lecture seule des transactions actuelles.

transform_null_equals

Dynamique Traite l'expression =NULL en tant que IS NULL.

update_process_title

Dynamique Met à jour le titre du processus pour indiquer la commande SQL active.

vacuum_cost_delay

Dynamique Valeur du coût de délai du processus vacuum en millisecondes.

vacuum_cost_limit

Dynamique Coût cumulé qui provoque l'endormissement du processus vacuum.

vacuum_cost_page_dirty

Dynamique Coût du processus vacuum pour une page salie par le processus vacuum.

vacuum_cost_page_hit

Dynamique Coût du processus vacuum pour une page trouvée dans le cache des tampons.

vacuum_cost_page_miss

Dynamique Coût du processus vacuum pour une page non trouvée dans le cache des tampons.

vacuum_defer_cleanup_age

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

Dynamique Âge limite auquel le processus vacuum doit figer une ligne de tableau.

vacuum_freeze_table_age

Dynamique Âge auquel le processus vacuum effectue une analyse complète de la table pour figer des lignes.

wal_writer_delay

Dynamique Délai d'inactivité de l'enregistreur des WAL entre les actions de vidage WAL.

work_mem

Dynamique Définit la quantité maximum de mémoire que peuvent utiliser les espaces de travail des requêtes.

xmlbinary

Dynamique Définit la façon dont les valeurs binaires doivent être codées en XML.

xmloption

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.

autovacuum_freeze_max_age

Statique Âge auquel lancer le processus autovacuum sur une table pour empêcher le renvoi à la ligne de l'ID de transaction.

autovacuum_max_workers

Statique Définit le nombre maximum de processus autovacuum qui peuvent être exécutés simultanément.

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.

shared_buffers

Statique Définit le nombre de tampons de mémoire partagée utilisés par le serveur.

ssl

Statique Active les connexions SSL.
temp_file_limit Statique Définit la taille maximale en Ko que peuvent atteindre les fichiers temporaires.

track_activity_query_size

Statique Définit la taille réservée pour pg_stat_activity.current_query, en octets.

wal_buffers

Statique Définit le nombre de tampons de page de disque dans la mémoire partagée pour les WAL.

Amazon RDS utilise les unités PostgreSQL par défaut pour tous les paramètres. Le tableau suivant indique l'unité et la valeur PostgreSQL par défaut de chaque paramètre.

Nom du paramètre

Unité

effective_cache_size

8 Ko

segment_size

8 Ko

shared_buffers

8 Ko

temp_buffers

8 Ko

wal_buffers

8 Ko

wal_segment_size

8 Ko

log_rotation_size

Ko

log_temp_files

Ko

maintenance_work_mem

Ko

max_stack_depth

Ko

ssl_renegotiation_limit

Ko
temp_file_limit Ko

work_mem

Ko

log_rotation_age

minutes

autovacuum_vacuum_cost_delay

ms

bgwriter_delay

ms

deadlock_timeout

ms

lock_timeout

ms

log_autovacuum_min_duration

ms

log_min_duration_statement

ms

max_standby_archive_delay

ms

max_standby_streaming_delay

ms

statement_timeout

ms

vacuum_cost_delay

ms

wal_receiver_timeout

ms

wal_sender_timeout

ms

wal_writer_delay

ms

archive_timeout

s

authentication_timeout

s

autovacuum_naptime

s

checkpoint_timeout

s

checkpoint_warning

s

post_auth_delay

s

pre_auth_delay

s

tcp_keepalives_idle

s

tcp_keepalives_interval

s

wal_receiver_status_interval

s

Utilisation de la fonction autovacuum de PostgreSQL sur Amazon RDS

Nous vous conseillons vivement d'utiliser la fonction autovacuum pour les bases de données PostgreSQL afin de maintenir l'intégrité de votre instance de base de données PostgreSQL. La fonction autovacuum automatise l'exécution des commandes VACUUM et ANALYZE. Elle recherche les tables ayant eu un grand nombre de tuples insérés, mis à jour ou supprimés. Elle récupère alors le stockage en supprimant les données et les tuples obsolètes de la base de données PostgreSQL.

La fonction autovacuum est activée par défaut pour toutes les nouvelles instances de base de données Amazon RDS PostgreSQL, et les paramètres de configuration associés sont configurés par défaut de manière appropriée. Comme nos valeurs par défaut sont relativement génériques, vous pouvez bénéficier du réglage des paramètres en fonction de votre charge de travail spécifique. La section suivante peut vous aider à effectuer l'ajustement nécessaire d'autovacuum.

Allocation de mémoire pour la fonction autovacuum

L'un des paramètres les plus importants qui influencent les performances d'autovacuum est maintenance_work_mem. Ce paramètre détermine la quantité de mémoire que vous allouez à autovacuum pour analyser une table de base de données et conserver tous les ID des lignes qui vont faire l'objet d'une opération VACUUM. Si vous définissez une valeur trop basse du paramètre maintenance_work_mem, le processus vacuum pourrait avoir à analyser la table plusieurs fois pour effectuer son travail. Ces nombreuses analyses peuvent avoir un impact négatif sur les performances.

Lorsque vous faites des calculs pour déterminer la valeur du paramètre maintenance_work_mem, gardez les deux choses suivantes à l'esprit :

  • L'unité par défaut est le kilo-octet (Ko) pour ce paramètre.

  • Le paramètre maintenance_work_mem fonctionne conjointement avec le paramètre autovacuum_max_workers. Si vous disposez de plusieurs petites tables, allouez plus de autovacuum_max_workers et moins de maintenance_work_mem. Si vous avez de grandes tables (par exemple, 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. Chaque autovacuum_max_workers peut utiliser la mémoire que vous allouez. Ainsi, vous devez vous assurer que la combinaison des processus de travail et de la mémoire est égale à la mémoire totale que vous souhaitez allouer.

De manière générale, pour les hôtes volumineux, affectez au paramètre maintenance_work_mem une valeur comprise entre un et deux gigaoctets (entre 1 048 576 et 2 097 152 Ko). Pour les hôtes extrêmement volumineux, affectez à ce paramètre une valeur comprise entre deux et quatre gigaoctets (entre 2 097 152 et 4 194 304 Ko). La valeur que vous définissez pour ce paramètre doit dépendre de la charge de travail. Amazon RDS a mis à jour sa valeur par défaut pour ce paramètre en un nombre de kilo-octets calculé comme suit :

GREATEST({DBInstanceClassMemory/63963136*1024},65536).

Réduction de la probabilité de renvoi à la ligne 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 renvoi à la ligne de l'ID de transaction. Pour résoudre ce problème, Amazon RDS pour PostgreSQL fournit un mécanisme qui adapte automatiquement les valeurs des paramètres de la fonction autovacuum. Le réglage adaptatif des paramètres d'autovacuum est une fonction pour RDS pour PostgreSQL versions 9.4 et ultérieures. Une explication détaillée du renvoi à la ligne de l'ID de transaction figure dans la documentation PostgreSQL.

Le réglage adaptatif des paramètres d'autovacuum est activé par défaut pour les instances RDS 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 renvoi à la ligne de l'ID de transaction est encore possible même lorsque RDS règle les paramètres d'autovacuum. Nous vous encourageons à implémenter une alarme Amazon CloudWatch pour le renvoi à la ligne de l'ID de transaction. Pour de plus amples informations, veuillez consulter le billet de blog Implement an Early Warning System for Transaction ID Wraparound in Amazon RDS for PostgreSQL.

Lorsque le réglage adaptatif des paramètres d'autovacuum est activé, RDS commence à ajuster les paramètres d'autovacuum lorsque la métrique CloudWatch MaximumUsedTransactionIDs atteint la plus grande des valeurs suivantes :

  • 750 000 000

  • Le paramètre d'autovacuum autovacuum_freeze_max_age

RDS continue à ajuster les paramètres pour la fonction d'autovacuum si une table continue à s'orienter vers le renvoi à la ligne de l'ID de transaction. Chacun de ces ajustements dédie plus de ressources à la fonction d'autovacuum pour éviter le renvoi à la ligne. RDS met à jour les paramètres suivants associés à la fonction d'autovacuum :

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

Chaque fois que RDS modifie certains de ces paramètres d'autovacuum, il génère un événement pour l'instance de base de données affectée qui est visible sur la AWS Management Console (https://console.aws.amazon.com/rds/) et via l'API RDS. Une fois que la métrique CloudWatch MaximumUsedTransactionIDs est repassée sous le seuil, RDS réinitialise les paramètres associés à la fonction d'autovacuum en mémoire en rétablissant les valeurs spécifiées dans le groupe de paramètres, et génère un autre événement correspondant à ce changement.

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 non vidées dans une base de données. La colonne datfrozenxid de la ligne pg_database d'une base de données est une limite inférieure appliquée aux ID de transaction normaux qui apparaissent 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 d'ID de transactions, un renvoi à la ligne de l'ID de transaction (XID) se produit et la base de données passe en lecture seule. Cette requête peut servir à produire une métrique et être exécutée plusieurs fois par jour. Par défaut, autovacuum est défini pour conserver un âge de transactions inférieur à 200 000 000 (autovacuum_freeze_max_age).

Un exemple de stratégie 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 non vidé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é. En fonction de la vitesse à laquelle votre base de données utilise les ID de transaction, cette alarme peut indiquer que le système n'a presque plus de temps pour exécuter le processus d'autovacuum. Dans ce cas, nous vous recommandons de résoudre cela immédiatement.

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 de plus amples informations sur la création d'un processus qui vous avertisse d'un renvoi à la ligne de l'ID de transaction, veuillez consulter le billet de blog AWS consacré aux bases de données 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 de plus amples informations sur le gel manuel du processus vacuum, veuillez consulter Réalisation d'un gel manuel du processus vacuum.

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 est défini comme suit :

Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples

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 -- or 1 = 1 ) 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.

Si vous utilisez Amazon RDS PostgreSQL 9.6+ ou versions ultérieures, utilisez la requête suivante :

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; +

Si vous utilisez une version antérieure à Amazon RDS PostgreSQL 9.6+, sauf 9.3.12 ou versions ultérieures, 9.4.7 ou versions ultérieures, ou 9.5.2+ utilisez la requête suivante :

SELECT datname, usename, pid, waiting, 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 | waiting | xact_runtime | query --------+----------+-------+---------+-------------------------+---------------------------------------------------------------------------------------------- mydb | rdsadmin | 16473 | f | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound) mydb | rdsadmin | 22553 | f | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound) mydb | rdsadmin | 41909 | f | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3 mydb | rdsadmin | 618 | f | 00:00:00 | SELECT datname, usename, pid, waiting, 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 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 gel manuel du processus vacuum en mode détaillé sur ___table___ 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 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.

  2. Dans la première session, obtenez le PID de la session autovacuum en cours d'exécution sur la table. Cette action nécessite l'exécution de Amazon RDS PostgreSQL 9.3.12 ou version ultérieure, 9.4.7 ou version ultérieure, ou 9.5.2 ou version ultérieure afin d'avoir une visibilité complète sur les processus rdsadmin en cours d'exécution.

    Exécutez la requête suivante pour obtenir le PID de la session autovacuum.

    SELECT datname, usename, pid, waiting, current_timestamp - xact_start AS xact_runtime, query FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY xact_start;
  3. 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 à maintenance_work_mem pour la session en cours.

    set maintenance_work_mem='2 GB'; SET
  4. 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
  5. Dans la première session, si autovacuum provoquait un blocage, vous voyez dans pg_stat_activity que l'attente a la valeur « T » pour votre session vacuum. Dans ce cas, vous devez mettre fin au processus autovacuum comme suit.

    SELECT pg_terminate_backend('the_pid');
  6. À 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. 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 :

mydb=# 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 », 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.

  2. Dans la première session, obtenez le PID de la session autovacuum en cours d'exécution sur la table. Cette action nécessite l'exécution de Amazon RDS PostgreSQL 9.3.12 ou version ultérieure, 9.4.7 ou version ultérieure, ou 9.5.2 ou version ultérieure afin d'avoir une visibilité complète sur les processus rdsadmin en cours d'exécution.

    Exécutez la requête suivante pour obtenir le PID de la session autovacuum :

    SELECT datname, usename, pid, waiting, current_timestamp - xact_start AS xact_runtime, query FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY xact_start;
  3. 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
  4. Dans la première session, si autovacuum provoquait un blocage, vous voyez dans pg_stat_activity que l'attente a la valeur « T » pour votre session vacuum. Dans ce cas, vous devez mettre fin au processus autovacuum.

    select pg_terminate_backend('the_pid');
  5. À 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. Lancez votre commande dans la session 2, puis terminez le processus autovacuum dans la session 1.

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

Définition des paramètres d'autovacuum au niveau de la table

Les paramètres de stockage 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, autovacuum s'arrête pour autovacuum_vacuum_cost_delay chaque fois qu'autovacuum_cost_limit est atteint. Pour plus d'informations, consultez la documentation PostgreSQL concernant le processus de vacuum basé sur les coûts.

Journalisation d'autovacuum

Par défaut, postgresql.log ne contient pas d'informations sur le processus autovacuum. Si vous utilisez PostgreSQL 9.4.5 ou version ultérieure, vous pouvez voir le résultat dans le journal des erreurs PostgreSQL depuis les opérations de l'exécutant autovacuum en définissant le paramètre rds.force_autovacuum_logging_level. Les valeurs autorisées sont disabled, debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, et panic. La valeur par défaut est disabled parce que les autres valeurs autorisées peuvent ajouter une quantité importante d'informations à vos journaux.

Nous vous recommandons de définir la valeur du paramètre rds.force_autovacuum_logging_level sur log et d'affecter au paramètre log_autovacuum_min_duration une valeur comprise entre 1 000 et 5 000 millisecondes. Si vous définissez cette valeur sur 5 000, Amazon RDS écrit toute activité de plus de cinq secondes dans le journal. Il affiche également des messages « action vacuum ignorée » lorsque des tables sont intentionnellement ignorées en raison du verrouillage de l'application. Si vous voulez résoudre un problème et que vous avez besoin de plus de détails, vous pouvez utiliser une autre valeur de niveau de journalisation, telle que debug1 ou debug3. Utilisez ces paramètres de débogage pendant une courte période de temps, car ils produisent un contenu extrêmement détaillé écrit dans le fichier journal des erreurs. Pour plus d'informations sur ces paramètres de débogage, consultez la documentation PostgreSQL.

Note

PostgreSQL version 9.4.7 ou ultérieure améliore la visibilité des sessions autovacuum en autorisant le compte rds_superuser à visualiser les sessions autovacuum dans pg_stat_activity. Par exemple, vous pouvez identifier et résilier une session autovacuum 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.

Journalisation d'audit pour une instance de base de données PostgreSQL

Plusieurs paramètres vous permettent de définir la consignation de l'activité qui se produit sur votre instance de base de données PostgreSQL. Ces paramètres sont les suivants :

  • Le paramètrelog_statement peut être utilisé pour consigner l'activité utilisateur dans votre base de données PostgreSQL. Pour plus d'informations, consultez Fichiers journaux de base de données PostgreSQL.

  • Le paramètre rds.force_admin_logging_level consigne les actions effectuées par l'utilisateur interne RDS (rdsadmin) dans les bases de données sur l'instance de base de données, et écrit la sortie dans le journal des erreurs PostgreSQL. Les valeurs autorisées sont disabled, debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal et panic. La valeur par défaut est disabled.

  • Le paramètre rds.force_autovacuum_logging_level consigne les opérations de l'exécutant autovacuum dans toutes les bases de données sur l'instance de base de données et écrit la sortie dans le journal des erreurs PostgreSQL. Les valeurs autorisées sont disabled, debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal et panic. La valeur par défaut est disabled. Le paramètre recommandé par Amazon RDS pour rds.force_autovacuum_logging_level est LOG. Affectez à log_autovacuum_min_duration une valeur comprise entre 1 000 et 5 000. L'affectation de la valeur 5 000 entraîne l'écriture dans le journal des activités de plus de 5 secondes et l'affichage de messages « action vacuum ignorée ». Pour de plus amples informations sur ce paramètre, veuillez consulter Bonnes pratiques pour utiliser les moteurs de stockage PostgreSQL.

Utilisation de l'extension pgaudit

L'extension pgaudit fournit une journalisation détaillée des audits de session et d'objet pour Amazon RDS for PostgreSQL version 9.6.3 ou ultérieure, ainsi que version 9.5.7 ou ultérieure. Vous pouvez activer des audits de session ou des audits d'objet à l'aide de cette extension.

Avec les audits de session, vous pouvez journaliser des événements d'audit de différentes sources et inclure le texte de commande complet lorsqu'il est disponible. Par exemple, vous pouvez utiliser des audits de session pour journaliser toutes les instructions READ qui se connectent à une base de données en définissant pgaudit.log sur « READ ».

Avec les audits d'objet, vous pouvez affiner la journalisation d'audit pour que celle-ci fonctionne avec des commandes spécifiques. Par exemple, vous pouvez spécifier que vous souhaitez une journalisation d'audit pour les opérations READ sur un nombre spécifique de tables.

Pour utiliser la journalisation basée sur des objets avec l'extension pgaudit

  1. Créez un rôle de base de données spécifique appelé rds_pgaudit. Utilisez la commande suivante pour créer le rôle.

    CREATE ROLE rds_pgaudit; CREATE ROLE
  2. Modifiez le groupe de paramètres qui est associé à votre instance de base de données pour utiliser les bibliothèques de préchargement partagées contenant pgaudit et définissez le paramètre pgaudit.role. pgaudit.role doit être défini sur le rôle rds_pgaudit.

    La commande suivante modifie un groupe de paramètres personnalisé.

    aws rds modify-db-parameter-group --db-parameter-group-name rds-parameter-group-96 --parameters "ParameterName=pgaudit.role,ParameterValue=rds_pgaudit,ApplyMethod=pending-reboot" --parameters "ParameterName=shared_preload_libraries,ParameterValue=pgaudit,ApplyMethod=pending-reboot" --region us-west-2
  3. Redémarrez l'instance de base de données pour qu'elle récupère les modifications apportées au groupe de paramètres. La commande suivante redémarre une instance de base de données.

    aws rds reboot-db-instance --db-instance-identifier rds-test-instance --region us-west-2
  4. Exécutez la commande suivante pour confirmer que pgaudit a été initialisé.

    show shared_preload_libraries; shared_preload_libraries -------------------------- rdsutils,pgaudit (1 row)
  5. Exécutez la commande suivante pour créer l'extension pgaudit.

    CREATE EXTENSION pgaudit; CREATE EXTENSION
  6. 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 d'audit, exécutez plusieurs commandes que vous avez choisies d'auditer. Par exemple, vous pouvez exécuter les commandes suivantes.

CREATE TABLE t1 (id int); CREATE TABLE GRANT SELECT ON t1 TO rds_pgaudit; GRANT 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 Fichiers journaux de base de données Amazon RDS.

Utilisation de l'extension pg_repack

Vous pouvez utiliser l'extension pg_repack pour éliminer la distension des tables et des index. Cette extension est prise en charge sur Amazon RDS pour PostgreSQL versions 9.6.3 et versions ultérieures. Pour plus d'informations sur l'extension pg_repack, consultez la documentation de projet Github.

Pour utiliser l'extension pg_repack

  1. Installez l'extension pg_repack sur votre Amazon RDS pour instance de base de données PostgreSQL en exécutant la commande suivante.

    CREATE EXTENSION pg_repack;
  2. Utilisez l'utilitaire client pg_repack pour vous connecter à une base de données. Utilisez un rôle de base de données disposant des privilèges rds_superuser pour vous connecter à la base de données. Dans l'exemple de connexion suivant, le rôle rds_test dispose des privilèges rds_superuser, et le point de terminaison de base de données utilisé est rds-test-instance.cw7jjfgdr4on8.us-west-2.rds.amazonaws.com.

    pg_repack -h rds-test-instance.cw7jjfgdr4on8.us-west-2.rds.amazonaws.com -U rds_test -k postgres

    Connectez-vous à l'aide de l'option -k. L'option -a n'est pas prise en charge.

  3. La réponse du client pg_repack fournit des informations sur les tables sur 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"

Utilisation de PostGIS

PostGIS est une extension de PostgreSQL pour le stockage et la gestion des informations spatiales. Si vous ne connaissez pas bien PostGIS, vous pouvez en consulter une bonne présentation globale sur PostGIS Introduction.

Vous devez procéder à certaines configurations avant de pouvoir utiliser l'extension PostGIS. La liste suivante présente ce que vous devez faire. Chaque étape est décrite de façon plus détaillée plus loin dans cette section.

  • Connectez-vous à l'instance de base de données à l'aide du nom d'utilisateur principal utilisé pour créer l'instance de base de données.

  • Chargez les extensions PostGIS.

  • Transférez la propriété des extensions au rôle rds_superuser.

  • Transférez la propriété des objets au rôle rds_superuser.

  • Testez les extensions.

Étape 1 : Connexion à l'instance de base de données à l'aide de l'identifiant principal utilisé pour créer l'instance de base de données

Connectez-vous d'abord à l'instance de base de données à l'aide du nom d'utilisateur principal utilisé pour créer l'instance de base de données. Le rôle rds_superuser est automatiquement affecté au nom. Vous avez besoin du rôle rds_superuser qui est nécessaire pour les étapes restantes.

L'exemple suivant utilise SELECT pour vous montrer l'utilisateur actuel. Dans le cas présent, l'utilisateur doit être l'utilisateur principal choisi lors de la création de l'instance de base de données.

select current_user; current_user ------------- myawsuser (1 row)

Étape 2 : Chargement des extensions PostGIS

Utilisez les instructions CREATE EXTENSION pour charger les extensions PostGIS. Vous devez également charger l'extension . Vous pouvez ensuite utiliser la commande \dn psql pour répertorier les propriétaires des schémas PostGIS.

create extension postgis; CREATE EXTENSION create extension fuzzystrmatch; CREATE EXTENSION create extension postgis_tiger_geocoder; CREATE EXTENSION create extension postgis_topology; CREATE EXTENSION \dn List of schemas Name | Owner --------------+----------- public | myawsuser tiger | rdsadmin tiger_data | rdsadmin topology | rdsadmin (4 rows)

Étape 3 : Transfert de la propriété des extensions au rôle rds_superuser

Utilisez les instructions ALTER SCHEMA pour transférer la propriété des schémas au rôle rds_superuser.

alter schema tiger owner to rds_superuser; ALTER SCHEMA alter schema tiger_data owner to rds_superuser; ALTER SCHEMA alter schema topology owner to rds_superuser; ALTER SCHEMA \dn List of schemas Name | Owner --------------+--------------- public | myawsuser tiger | rds_superuser tiger_data | rds_superuser topology | rds_superuser (4 rows)

Étape 4 : Transfert de la propriété des objets au rôle rds_superuser

Utilisez la fonction suivante pour transférer la propriété des objets PostGIS au rôle rds_superuser. 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$;

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 rds_superuser;') 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 : Test des extensions

Ajoutez tiger à votre chemin de recherche à l'aide de la commande suivante.

SET search_path=public,tiger;

Testez tiger à l'aide de l'instruction SELECT suivante.

select na.address, na.streetname, na.streettypeabbrev, na.zip from normalize_address('1 Devonshire Place, Boston, MA 02109') as na; address | streetname | streettypeabbrev | zip ---------+------------+------------------+------- 1 | Devonshire | Pl | 02109 (1 row)

Testez topology à l'aide de l'instruction SELECT suivante.

select topology.createtopology('my_new_topo',26986,0.5); createtopology ---------------- 1 (1 row)

Utilisation de pgBadger pour l'analyse de journal serveur avec PostgreSQL

Vous pouvez utiliser un analyseur de journaux tel que pgbadger pour analyser les journaux PostgreSQL. La documentation pgbadger indique que le motif %l (ligne de journal pour la session/le processus) doit faire partie du préfixe. Cependant, si vous fournissez le préfixe rds log_line_prefix en tant que paramètre pour pgbadger, il doit tout de même produire un rapport.

Par exemple, la commande suivante formate correctement un fichier journal PostgreSQL Amazon RDS daté du 04/02/2014 à l'aide de pgbadger.

./pgbadger -p '%t:%r:%u@%d:[%p]:' postgresql.log.2014-02-04-00

Affichage du contenu de pg_config

Dans PostgreSQL version 9.6.1, vous pouvez voir les paramètres de configuration du temps compilation de la version actuellement installée de PostgreSQL à l'aide de la nouvelle vue pg_config. Vous pouvez utiliser la vue en appelant la fonction pg_config, comme illustré dans l'exemple suivant.

select * from pg_config(); name | setting -------------------+--------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------- BINDIR | /rdsdbbin/postgres-9.6.1.R1/bin DOCDIR | /rdsdbbin/postgres-9.6.1.R1/share/doc HTMLDIR | /rdsdbbin/postgres-9.6.1.R1/share/doc INCLUDEDIR | /rdsdbbin/postgres-9.6.1.R1/include PKGINCLUDEDIR | /rdsdbbin/postgres-9.6.1.R1/include INCLUDEDIR-SERVER | /rdsdbbin/postgres-9.6.1.R1/include/server LIBDIR | /rdsdbbin/postgres-9.6.1.R1/lib PKGLIBDIR | /rdsdbbin/postgres-9.6.1.R1/lib LOCALEDIR | /rdsdbbin/postgres-9.6.1.R1/share/locale MANDIR | /rdsdbbin/postgres-9.6.1.R1/share/man SHAREDIR | /rdsdbbin/postgres-9.6.1.R1/share SYSCONFDIR | /rdsdbbin/postgres-9.6.1.R1/etc PGXS | /rdsdbbin/postgres-9.6.1.R1/lib/pgxs/src/makefiles/pgxs.mk CONFIGURE | '--prefix=/rdsdbbin/postgres-9.6.1.R1' '--with-openssl' '--with-perl' '--with-tcl' '--with-ossp-uuid' '--with-libxml' '--with-libraries=/rdsdbbin /postgres-9.6.1.R1/lib' '--with-includes=/rdsdbbin/postgres-9.6.1.R1/include' '--enable-debug' CC | gcc CPPFLAGS | -D_GNU_SOURCE -I/usr/include/libxml2 -I/rdsdbbin/postgres-9.6.1.R1/include CFLAGS | -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict- aliasing -fwrapv -fexcess-precision=standard -g -O2 CFLAGS_SL | -fpic LDFLAGS | -L../../src/common -L/rdsdbbin/postgres-9.6.1.R1/lib -Wl,--as-needed -Wl, -rpath,'/rdsdbbin/postgres-9.6.1.R1/lib',--enable-new-dtags LDFLAGS_EX | LDFLAGS_SL | LIBS | -lpgcommon -lpgport -lxml2 -lssl -lcrypto -lz -lreadline -lrt -lcrypt -ldl -lm VERSION | PostgreSQL 9.6.1 (23 rows)

Si vous essayez d'accéder directement à la vue, la demande échoue.

select * from pg_config; ERROR: permission denied for relation pg_config

Utilisation de l'extension orafce

L'extension orafce propose des fonctions courantes de bases de données commerciales et facilite le portage d'une base de données commerciale vers PostgreSQL. Amazon RDS pour les versions 9.6.6 et ultérieures de PostgreSQL prend en charge cette extension. Pour plus d'informations sur orafce, consultez le projet orafce sur GitHub.

Note

Amazon RDS pour 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.

Pour utiliser l'extension orafce

  1. Connectez-vous à l'instance de base de données avec le nom d'utilisateur principal utilisé pour créer l'instance de base de données.

    Note

    Si vous souhaitez activer orafce sur une base de données différente dans la même instance, utilisez la commande psql /c dbname pour changer de la base de données principale après avoir lancé la connexion.

  2. Activez l'extension orafce avec l'extension CREATE EXTENSION.

    CREATE EXTENSION orafce;
  3. Transférez la propriété du schéma oracle au rôle rds_superuser avec la déclaration ALTER SCHEMA.

    ALTER SCHEMA oracle OWNER TO rds_superuser;

    Note

    Si vous souhaitez voir la liste des propriétaires du schéma oracle, utilisez la commande psql \dn.

Accès aux données externes à l'aide de l'extension postgres_fdw

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_fdw. Si vous configurez une connexion distante à partir de votre instance de base de données PostgreSQL, l'accès est également disponible pour votre réplica en lecture.

Pour utiliser postgres_fdw pour accéder à un serveur de bases de données distant

  1. Installez l'extension postgres_fdw.

    CREATE EXTENSION postgres_fdw;
  2. 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');
  3. Créez un mappage utilisateur pour identifier le rôle à utiliser sur le serveur distant.

    CREATE USER MAPPING FOR local_user SERVER foreign_server OPTIONS (user 'foreign_user', password 'password');
  4. 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');

Utilisation d'un serveur DNS personnalisé pour l'accès réseau sortant

Amazon RDS pour 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 Amazon RDS via votre serveur DNS personnalisé.

Activation de la résolution DNS personnalisée

Pour activer la résolution DNS dans le VPC de votre client, vous devez associer un groupe personnalisé de paramètres de base de données à l'instance RDS PostgreSQL, définir le paramètre rds.custom_dns_resolution sur 1 pour l'activer, puis redémarrer 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 le VPC de votre client, vous devez désactiver le paramètre rds.custom_dns_resolution de votre groupe personnalisé de paramètres de base de données en le définissant sur 0, puis redémarrer 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.

Pour configurer un serveur DNS personnalisé pour votre instance de base de données Amazon RDS PostgreSQL, procédez comme suit :

  1. A partir du jeu d'options 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.

    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.

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

  3. Configurez votre serveur DNS pour produire des réponses UDP (User Datagram Protocol) de 512 octets ou moins.

  4. Configurez votre serveur DNS pour produire des réponses TCP (Transmission Control Protocol) de 1024 octets ou moins.

  5. 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 une liste blanche des pare-feux appropriés pour permettre le trafic UDP et TCP sur le port 53.

    Pour plus d'informations, consultez Groupes de sécurité pour votre VPC et Ajout et suppression de règles.

  6. Configurez le VPC de votre instance de base de données Amazon RDS pour 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 plus d'informations, consultez Groupes de sécurité pour votre VPC et Ajout et suppression de règles.

  7. Le chemin d'acheminement entre l'instance de base de données Amazon RDS et le serveur DNS doit être configuré correctement pour permettre un trafic DNS.

    Si l'instance de base de données Amazon RDS et le serveur DNS ne sont pas dans le même VPC, une connexion d'appairage doit être configurée entre les deux. Pour plus d'informations, consultez Qu'est-ce que l'appairage de VPC ?

Restriction de la gestion des mots de passe

Vous pouvez définir qui peut gérer les mots de passe des utilisateurs de base de données en affectant un rôle spécifique aux personnes concernées. Cette technique vous permet d'avoir plus de contrôle sur la gestion des mots de passe du côté du client.

Pour activer la gestion restreinte des mots de passe, utilisez le paramètre statique rds.restrict_password_commands et le rôle rds_password. Lorsque le paramètre rds.restrict_password_commands est défini sur 1, seuls les utilisateurs associés au rôle rds_password peuvent exécuter certaines commandes SQL. Ces commandes SQL restreintes permettent de modifier les mots de passe des utilisateurs de base de données, ainsi que le délai d'expiration des mots de passe.

Pour utiliser la gestion restreinte des mots de passe, l'instance de base de données doit exécuter Amazon RDS pour PostgreSQL 10.6 ou version ultérieure. Comme le paramètre rds.restrict_password_commands est statique, vous devez redémarrer la base de données pour le modifier.

Lorsque la gestion restreinte des mots de passe est activée au niveau d'une base de données, si vous essayez d'exécuter des commandes SQL restreintes, l'erreur suivante est générée : ERROR: must be a member of rds_password to alter passwords (ERREUR : la modification des mots de passe nécessite que vous ayez le rôle rds_password).

Vous trouverez ci-dessous des exemples de commandes SQL dont l'utilisation est contrôlée lorsque la gestion restreinte des mots de passe est activée.

postgres=> CREATE ROLE myrole WITH PASSWORD 'mypassword'; postgres=> CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2020-01-01'; postgres=> ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2020-01-01'; postgres=> ALTER ROLE myrole WITH PASSWORD 'mypassword'; postgres=> ALTER ROLE myrole VALID UNTIL '2020-01-01'; postgres=> ALTER ROLE myrole RENAME TO myrole2;

Certaines commandes ALTER ROLE qui incluent RENAME TO peuvent également être restreintes. Elles peuvent être restreintes, car la modification du nom d'un rôle PostgreSQL associé à un mot de passe MD5 supprime le mot de passe.

Par défaut, le rôle rds_password est toujours affecté au rôle rds_superuser. Cette configuration n'est pas modifiable. Vous pouvez affecter le rôle rds_password à d'autres rôles à l'aide de la commande SQL GRANT. Nous vous conseillons de n'affecter le rôle rds_password qu'à quelques rôles utilisés exclusivement pour la gestion des mots de passe. Ces rôles nécessitent l'attribut CREATEROLE pour pouvoir modifier d'autres rôles.

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. Nous vous recommandons d'employer votre propre utilitaire côté client pour limiter les modifications liées aux mots de passe. Cette utilitaire doit être membre du rôle rds_password et posséder l'attribut de rôle CREATEROLE.