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 d'écriture directe et des emplacements logiques pour la réplication logique Aurora Postgre SQL

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

Surveillance du cache d'écriture directe de réplication SQL logique Aurora Postgre

Par défaut, SQL les versions 14.5, 13.8, 12.12 et 11.17 et ultérieures d'Aurora Postgre utilisent un cache d'écriture directe pour améliorer les performances de réplication logique. Sans le cache d'écriture directe, Aurora Postgre utilise SQL la couche de stockage Aurora pour implémenter le processus de réplication logique Postgre SQL natif. Pour ce faire, il écrit WAL des données dans le stockage, puis les lit à nouveau depuis le stockage pour les décoder et les envoyer (répliquer) à ses cibles (abonnés). Cela peut entraîner des blocages lors de la réplication logique pour les clusters de base de données Aurora SQL Postgre.

Le cache en écriture directe réduit le recours à la couche de stockage Aurora. Au lieu d'écrire et de lire régulièrement sur cette couche, Aurora Postgre SQL utilise une mémoire tampon pour mettre en cache le WAL flux logique à utiliser pendant le processus de réplication, réduisant ainsi le besoin d'accéder au disque. Ce tampon est le SQL cache Postgre natif utilisé dans la réplication logique et est identifié dans les paramètres du cluster de SQL base de données Aurora Postgre comme. rds.logical_wal_cache

Lorsque vous utilisez la réplication logique avec votre cluster de SQL base de données Aurora Postgre (pour les versions qui prennent en charge le cache en écriture directe), vous pouvez surveiller le taux de réussite du cache pour voir dans quelle mesure il fonctionne pour votre cas d'utilisation. Pour ce faire, connectez-vous à l'instance d'écriture de votre SQL cluster de base de données Aurora Postgre à l'aide, psql puis utilisez la fonction Auroraaurora_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 de plus amples informations sur cette fonction, veuillez consulter aurora_stat_logical_wal_cache.

Aurora Postgre SQL fournit les deux fonctions suivantes pour surveiller le cache d'écriture directe.

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

Gestion des emplacements logiques pour Aurora Postgre SQL

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 SQL requête 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');