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.

Surveillance du cache à écriture simultanée et des emplacements logiques pour la réplication logique Aurora PostgreSQL

Surveillez le cache à écriture simultanée de la réplication logique et gérez les emplacements logiques afin d’améliorer les performances de votre cluster de bases de données Aurora PostgreSQL. Vous trouverez ci-dessous des informations supplémentaires sur le cache à écriture simultanée et les emplacements logiques.

Surveillance du cache à écriture simultanée de la réplication logique Aurora PostgreSQL

Par défaut, Aurora PostgreSQL versions 14.5, 13.8, 12.12, et 11.17 et suivantes utilisent un cache à écriture simultanée pour améliorer les performances de la réplication logique. Sans le cache à écriture simultanée, Aurora PostgreSQL utilise la couche de stockage Aurora dans sa mise en œuvre du processus de réplication logique natif de PostgreSQL. Pour ce faire, il écrit des données WAL sur un support de stockage, puis lit les données sur ce support pour les décoder et les envoyer (répliquer) à ses cibles (abonnés). Cela peut entraîner des goulots d’étranglement pendant la réplication logique pour les clusters de bases de données Aurora PostgreSQL.

Le cache à écriture simultanée évite de dépendre trop de la couche de stockage Aurora. Au lieu de toujours écrire et lire à partir de cette couche, Aurora PostgreSQL utilise un tampon pour mettre en cache le flux WAL logique à utiliser pendant le processus de réplication, ce qui évite d’avoir à accéder au disque. Ce tampon est le cache PostgreSQL natif utilisé dans la réplication logique. Il est identifié dans les paramètres du cluster de bases de données Aurora PostgreSQL en tant que rds.logical_wal_cache.

Lorsque vous utilisez la réplication logique avec votre cluster de bases de données Aurora PostgreSQL (pour les versions qui prennent en charge le cache en écriture simultanée), vous pouvez surveiller le taux de réussite de la mise en cache pour voir si elle fonctionne bien pour votre cas d’utilisation. Pour ce faire, connectez-vous à l’instance en écriture de votre cluster de bases de données Aurora PostgreSQL à l’aide de psql et utilisez ensuite la fonction Aurora, aurora_stat_logical_wal_cache, comme indiqué dans l’exemple suivant.

SELECT * FROM aurora_stat_logical_wal_cache();

La fonction renvoie la sortie suivante.

name       | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
-----------+------------+-----------+------------+-----------+----------+--------------
test_slot1 | 79183      | 24        | 0          | 24        | 100.00%  | 2022-08-05 17:39...
test_slot2 |            | 1         | 0          |  1        | 100.00%  | 2022-08-05 17:34...
(2 rows)

Les valeurs last_reset_timestamp ont été raccourcies pour plus de lisibilité. Pour plus d’informations sur cette fonction, consultez aurora_stat_logical_wal_cache.

Aurora PostgreSQL fournit les deux fonctions suivantes pour surveiller le cache à écriture simultanée.

Si vous trouvez que la taille du cache WAL ajustée automatiquement n’est pas suffisante pour vos charges de travail, vous pouvez changer la valeur de rds.logical_wal_cache manuellement. Éléments à prendre en compte :

Gestion des emplacements logiques pour Aurora PostgreSQL

L’activité de streaming est capturée dans la vue pg_replication_origin_status. Pour voir le contenu de cette vue, vous pouvez utiliser la fonction pg_show_replication_origin_status(), comme indiqué ci-dessous :

SELECT * FROM pg_show_replication_origin_status();

Vous pouvez obtenir la liste de vos emplacements logiques à l’aide de la requête SQL suivante.

SELECT * FROM pg_replication_slots;

Pour supprimer un emplacement logique, utilisez pg_drop_replication_slot avec le nom de l’option, comme indiqué dans la commande suivante.

SELECT pg_drop_replication_slot('test_slot');