Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# aurora\$1replica\$1status
<a name="aurora_replica_status"></a>

Zeigt den Status aller Aurora-PostgreSQL-Reader-Knoten an. 

## Syntax
<a name="aurora_replica_status-syntax"></a>

 

```
aurora_replica_status()
```

## Argumente
<a name="aurora_replica_status-arguments"></a>

Keine

## Rückgabetyp
<a name="aurora_replica_status-return-type"></a>

SETOF-Datensatz mit den folgenden Spalten:
+ `server_id` – Die DB-Instance-ID (Kennung). 
+ `session_id` – Eine eindeutige ID für die aktuelle Sitzung, die wie folgt für die primäre Instance und Reader-Instances zurückgegeben wird:
  + Für die primäre Instance ist `session_id` immer ``MASTER_SESSION_ID’`.
  + Für Reader-Instances ist `session_id` immer die `UUID` (Universally Unique Identifier, eindeutige Kennung) der Reader-Instance.
+ `durable_lsn` – Die Log-Sequenznummer (LSN), die im Speicher abgelegt wurde.
  + Für das primäre Volume die dauerhafte LSN des primären Volumes (VDL), die derzeit in Kraft ist.
  + Für alle sekundären Volumes die VDL des primären Volumes, auf das das sekundäre Volume erfolgreich angewendet wurde.
**Anmerkung**  
Eine Log-Sequenznummer (LSN) ist eine eindeutige Sequenznummer, die einen Datensatz im Datenbanktransaktionslog identifiziert. LSNs sind so angeordnet, dass eine größere LSN für eine Transaktion steht, die zu einem späteren Zeitpunkt in der Sequenz stattgefunden hat.
+ `highest_lsn_rcvd` – Die höchste (neueste) LSN, die die DB-Instance von der Writer-DB-Instance empfangen hat.
+ `current_read_lsn` – Die LSN des letzten Snapshots, die auf alle Reader angewendet wurde. 
+ `cur_replay_latency_in_usec` – Die Anzahl der Mikrosekunden, die voraussichtlich benötigt werden, um das Protokoll auf der sekundären Instance wiederzugeben. 
+ `active_txns` – Die Anzahl der derzeit aktiven Transaktionen.
+ `is_current` – Nicht verwendet.
+ `last_transport_error` – Fehlercode für die letzte Replikation.
+ `last_error_timestamp` – Zeitstempel des letzten Replikationsfehlers.
+ `last_update_timestamp` – Zeitstempel der letzten Aktualisierung auf den Replikatstatus. Ab Aurora PostgreSQL 13.9 ist der `last_update_timestamp`-Wert für die DB-Instance, mit der Sie verbunden sind, auf `NULL` festgelegt.
+ `feedback_xmin` – Der Hot Standby feedback\$1xmin des Replikats. Die minimale (älteste) aktive Transaktions-ID, die von der DB-Instance verwendet wird.
+ `feedback_epoch` – Die Epoche, die die DB-Instance beim Erzeugen der Hot-Standby-Informationen verwendet.
+ `replica_lag_in_msec` – Zeit, die die Leser-Instance in Millisekunden hinter der Schreiber-Instance zurückbleibt
+ `log_stream_speed_in_kib_per_second` – Der Durchsatz des Protokollstreams in Kilobyte pro Sekunde.
+ `log_buffer_sequence_number` – Die Sequenznummer des Protokollpuffers.
+ `oldest_read_view_trx_id` – Nicht verwendet.
+ `oldest_read_view_lsn` – Die älteste LSN, die von der DB-Instance zum Lesen aus dem Speicher verwendet wird.
+ `pending_read_ios` – Die ausstehenden Seiten-Lesevorgänge, die noch im Replikat anstehen. 
+ `read_ios` – Die Gesamtzahl der Lesevorgänge auf dem Replikat.
+ `iops` – Nicht verwendet.
+ `cpu` – CPU-Auslastung des Aurora-Speicher-Daemon für jeden Knoten im Cluster. Weitere Informationen zur CPU-Auslastung durch die Instance finden Sie unter [Metriken auf Instance-Ebene für Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).

## Nutzungshinweise
<a name="aurora_replica_status-usage-notes"></a>

Alle derzeit verfügbaren Aurora-PostgreSQL-Versionen unterstützen diese Funktion. Die Funktion `aurora_replica_status` gibt Werte aus dem Replikatstatus-Manager eines Aurora-PostgreSQL-DB-Clusters zurück. Sie können diese Funktion verwenden, um Informationen über den Status der Replikation auf Ihrem Aurora-PostgreSQL-DB-Cluster zu erhalten, einschließlich Metriken für alle DB-Instances in Ihrem Aurora-DB-Cluster. Sie können z. B. Folgendes tun:
+ **Informationen über die Art der Instance (Writer, Reader) im Aurora-PostgreSQL-DB-Cluster abrufen** – Diese Informationen erhalten Sie, indem Sie sich die Werte der folgenden Spalten ansehen: 
  + `server_id` – Enthält den Namen der Instance, die Sie beim Erstellen der Instance festgelegt haben. In einigen Fällen, z. B. für die primäre (Writer-)Instance, wird der Name normalerweise durch Anhängen von *-instance-1* an den Namen, den Sie für Ihren Aurora-PostgreSQL-DB-Cluster festlegen, für Sie erstellt.
  + `session_id` – Das Feld `session_id` gibt an, ob es sich bei der Instance um einen Reader oder einen Writer handelt. Für eine Writer-Instance ist `session_id` immer auf `"MASTER_SESSION_ID"` festgelegt. Für eine Reader-Instance ist `session_id` auf die `UUID` des spezifischen Readers festgelegt.
+ **Häufige Replikationsprobleme wie Replikatverzögerung, diagnostizieren** – Replikatverzögerung ist die Zeit in Millisekunden, die der Seiten-Cache einer Reader-Instance hinter dem Cache der Writer-Instance zurückbleibt. Diese Verzögerung tritt auf, weil Aurora-Cluster eine asynchrone Replikation verwenden, wie unter [Replikation mit Amazon Aurora](Aurora.Replication.md)beschrieben. Diese ist in der Spalte `replica_lag_in_msec` in den von dieser Funktion zurückgegebenen Ergebnissen zu sehen. Verzögerungen können auch auftreten, wenn eine Abfrage aufgrund von Konflikten mit der Wiederherstellung auf einem Standby-Server abgebrochen wird. Unter `pg_stat_database_conflicts()` können Sie nachsehen, ob ein solcher Konflikt die Replikatverzögerung verursacht (oder nicht). Weitere Informationen finden Sie unter [Die Statistikerfassung](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-CONFLICTS-VIEW) in der *PostgreSQL-Dokumentation*. Weitere Informationen zu Hochverfügbarkeit und Replikation finden Sie unter [Amazon Aurora FAQs](https://aws.amazon.com/rds/aurora/faqs/#High_Availability_and_Replication). 

  Amazon CloudWatch speichert `replica_lag_in_msec` Ergebnisse im Laufe der Zeit als `AuroraReplicaLag` Metrik. Informationen zur Verwendung von CloudWatch Metriken für Aurora finden Sie unter [Überwachung von Amazon Aurora Aurora-Metriken mit Amazon CloudWatch](monitoring-cloudwatch.md) 

Weitere Informationen zur Fehlerbehebung bei Aurora-Lesereplikaten und Neustarts finden Sie unter [Warum ist mein Amazon-Aurora-Lesereplikat in den Rückstand geraten und wurde neu gestartet?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-read-replica-restart/) im [AWS Support Center](https://console.aws.amazon.com/support/home#/). 

## Beispiele
<a name="aurora_replica_status-examples"></a>

Im folgenden Beispiel wird veranschaulicht, wie Sie den Replikationsstatus aller Instances in einem Aurora-PostgreSQL-DB-Cluster abrufen:

```
=> SELECT * 
FROM aurora_replica_status();
```

Das folgende Beispiel zeigt die Writer-Instance im Aurora-PostgreSQL-DB-Cluster `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
```

Im folgenden Beispiel werden alle Reader-Instances in einem Cluster aufgeführt:

```
=> 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)
```

Im folgenden Beispiel werden alle Instances aufgeführt und es wird angegeben, wie weit jede Instance hinter dem Writer zurückbleibt und wie lange seit dem letzten Update: 

```
=> 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)
```