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.
# aurora\$1replica\$1status
Affiche l’état de tous les nœuds de lecture Aurora PostgreSQL.
## Syntaxe
```
aurora_replica_status()
```
## Arguments
Aucun
## Type de retour
Registre SETOF avec les colonnes suivantes :
+ `server_id` : l’ID (identifiant) de l’instance de base de données.
+ `session_id` : un identifiant unique pour la séance en cours, renvoyé pour l’instance principale et les instances de lecture comme suit :
+ Pour l’instance principale, `session_id` est toujours égal à ``MASTER_SESSION_ID’`.
+ Pour les instances de lecture, `session_id` est toujours égal au `UUID` (identifiant universel et unique) de l’instance de lecture.
+ `durable_lsn` : le numéro de séquence du journal (LSN) qui a été stocké.
+ Pour le volume principal, le LSN durable du volume principal (VDL) actuellement en vigueur.
+ Pour tout volume secondaire, le VDL du volume principal sur lequel le volume secondaire a été appliqué.
**Note**
Un numéro de séquence de journal (LSN) est un numéro séquentiel unique qui identifie un enregistrement dans le journal des transactions de la base de données. Les LSN sont ordonnés de telle sorte qu’un LSN plus grand représente une transaction qui a eu lieu plus tard dans la séquence.
+ `highest_lsn_rcvd` : le LSN le plus élevé (le plus récent) reçu par l’instance de base de données en provenance de l’instance de base de données en écriture.
+ `current_read_lsn` : le LSN de l’instantané le plus récent qui a été appliqué à tous les lecteurs.
+ `cur_replay_latency_in_usec` : le nombre de microsecondes attendu pour relire le journal sur le volume secondaire.
+ `active_txns` : le nombre de transactions actuellement actives.
+ `is_current` : non utilisé.
+ `last_transport_error` : dernier code d’erreur de réplication.
+ `last_error_timestamp` : horodatage de la dernière erreur de réplication.
+ `last_update_timestamp` : horodatage de la dernière mise à jour de l’état du réplica. Depuis Aurora PostgreSQL 13.9, la valeur de `last_update_timestamp` pour l’instance de base de données à laquelle vous êtes connecté est définie sur `NULL`.
+ `feedback_xmin` : la valeur feedback\$1xmin de secours du réplica. ID de transaction actif minimum (le plus ancien) utilisé par l’instance de base de données.
+ `feedback_epoch` : l’époque utilisée par l’instance de base de données lorsqu’elle génère des informations de secours.
+ `replica_lag_in_msec` : temps de retard de l’instance de lecteur par rapport à l’instance d’enregistreur, en millisecondes.
+ `log_stream_speed_in_kib_per_second` : le débit du flux des journaux en kilo-octets par seconde.
+ `log_buffer_sequence_number` : le numéro de séquence de la mémoire tampon du journal.
+ `oldest_read_view_trx_id` : non utilisé.
+ `oldest_read_view_lsn` : LSN le plus ancien utilisé par l’instance de base de données pour lire à partir du stockage.
+ `pending_read_ios` : les lectures de pages en suspens qui sont toujours en attente sur le réplica.
+ `read_ios` : le nombre total de pages lues sur le réplica.
+ `iops` : non utilisé.
+ `cpu` : utilisation du processeur par le démon de stockage Aurora pour chaque nœud du cluster. Pour plus d’informations sur l’utilisation du CPU par l’instance, consultez [Métriques de niveau instance pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
## Notes d’utilisation
Toutes les versions actuellement disponibles d’Aurora PostgreSQL prennent en charge cette fonction. La fonction `aurora_replica_status` renvoie les valeurs du gestionnaire d’état des réplicas d’un cluster de bases de données Aurora PostgreSQL. Vous pouvez utiliser cette fonction pour obtenir des informations sur l’état de la réplication sur votre cluster de bases de données Aurora PostgreSQL, y compris les métriques pour toutes les instances de base de données dans votre cluster de bases de données Aurora. Par exemple, vous pouvez effectuer les opérations suivantes :
+ **Get information about the type of instance (writer, reader) in the Aurora PostgreSQL DB cluster** (Obtenir des informations sur le type d’instance (écriture, lecture) dans le cluster de bases de données Aurora PostgreSQL) : vous pouvez obtenir ces informations en lisant les valeurs des colonnes suivantes :
+ `server_id` : contient le nom de l’instance que vous avez spécifié lorsque vous avez créé l’instance. Dans certains cas, comme pour l’instance principale (écriture), le nom est généralement créé pour vous en ajoutant *-instance-1* au nom spécifié pour votre cluster de bases de données Aurora PostgreSQL.
+ `session_id` : le champ `session_id` indique si l’instance est une instance de lecture ou d’écriture. Pour une instance d’enregistreur, `session_id` est toujours défini sur `"MASTER_SESSION_ID"`. Pour une instance de lecture, `session_id` est défini sur l’`UUID` de l’instance de lecture en question.
+ **Diagnose common replication issues, such as replica lag** (Diagnostiquer les problèmes de réplication courants, tels que le retard de réplica) : le retard de réplica est le temps, en millisecondes, pendant lequel le cache des pages d’une instance de lecture est en retard sur celui de l’instance d’enregistreur. Ce retard se produit parce que les clusters Aurora utilisent la réplication asynchrone, comme décrit dans [Réplication avec Amazon Aurora](Aurora.Replication.md). La valeur est indiquée dans la colonne `replica_lag_in_msec` des résultats renvoyés par cette fonction. Un retard peut également se produire lorsqu’une requête est annulée en raison de conflits avec la récupération sur un serveur de veille. Vous pouvez consulter `pg_stat_database_conflicts()` pour vérifier qu’un tel conflit est à l’origine du retard du réplica (ou non). Pour plus d’informations, consultez [The Statistics Collector](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-CONFLICTS-VIEW) (Collecteur de statistiques) dans la *documentation de PostgreSQL*. Pour en savoir plus sur la haute disponibilité et la réplication, consultez la [FAQ Amazon Aurora](https://aws.amazon.com/rds/aurora/faqs/#High_Availability_and_Replication).
Amazon CloudWatch enregistre les résultats `replica_lag_in_msec` dans le temps, en tant que métrique `AuroraReplicaLag`. Pour obtenir plus d’informations sur l’utilisation des métriques CloudWatch pour Aurora, consultez [Surveillance des métriques (Amazon Aurora) avec Amazon CloudWatch](monitoring-cloudwatch.md).
Pour en savoir plus sur le dépannage et les redémarrages des réplicas en lecture Aurora, consultez la section [Why did my Amazon Aurora read replica fall behind and restart?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-read-replica-restart/) (Pourquoi mon réplica en lecture Amazon Aurora a-t-il pris du retard et redémarré ?) dans le [Centre AWS Support](https://console.aws.amazon.com/support/home#/).
## Exemples
L’exemple suivant montre comment obtenir l’état de réplication de toutes les instances d’un cluster de bases de données Aurora PostgreSQL :
```
=> SELECT *
FROM aurora_replica_status();
```
L’exemple suivant montre l’instance d’enregistreur dans le cluster de bases de données Aurora PostgreSQL `docs-lab-apg-main` :
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role
FROM aurora_replica_status()
WHERE session_id = 'MASTER_SESSION_ID';
server_id | instance_role
------------------------+---------------
db-119-001-instance-01 | writer
```
L’exemple suivant répertorie toutes les instances de lecture d’un cluster :
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role
FROM aurora_replica_status()
WHERE session_id <> 'MASTER_SESSION_ID';
server_id | instance_role
------------------------+---------------
db-119-001-instance-02 | reader
db-119-001-instance-03 | reader
db-119-001-instance-04 | reader
db-119-001-instance-05 | reader
(4 rows)
```
L’exemple suivant répertorie toutes les instances, le retard de chaque instance par rapport à l’instance d’enregistreur et le temps écoulé depuis la dernière mise à jour :
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role,
replica_lag_in_msec AS replica_lag_ms,
round(extract (epoch FROM (SELECT age(clock_timestamp(), last_update_timestamp))) * 1000) AS last_update_age_ms
FROM aurora_replica_status()
ORDER BY replica_lag_in_msec NULLS FIRST;
server_id | instance_role | replica_lag_ms | last_update_age_ms
------------------------+---------------+----------------+--------------------
db-124-001-instance-03 | writer | [NULL] | 1756
db-124-001-instance-01 | reader | 13 | 1756
db-124-001-instance-02 | reader | 13 | 1756
(3 rows)
```