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.
**Topics**
+ [Surveillance du cache à écriture simultanée de la réplication logique Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [Gestion des emplacements logiques pour Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)
## 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\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
Aurora PostgreSQL fournit les deux fonctions suivantes pour surveiller le cache à écriture simultanée.
+ La fonction `aurora_stat_logical_wal_cache` :pour la documentation de référence, consultez [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
+ La fonction `aurora_stat_reset_wal_cache` :pour la documentation de référence, consultez [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md).
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 :
+ Lorsque le paramètre `rds.logical_replication` est désactivé, `rds.logical_wal_cache` est défini sur zéro (0).
+ Lorsque le paramètre `rds.logical_replication` est activé, `rds.logical_wal_cache` utilise la valeur par défaut, 16 Mo.
+ Le paramètre `rds.logical_wal_cache` est statique et nécessite un redémarrage de l’instance de base de données pour que les modifications prennent effet. Ce paramètre est défini en termes de blocs de 8 Ko. Notez que toute valeur positive inférieure à 32 Ko est traitée comme équivalant à 32 Ko. Pour plus d’informations sur `wal_buffers`, consultez [Write Ahead Log](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS) dans la documentation PostgreSQL.
## 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');
```