aurora_replica_status

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

Syntax

aurora_replica_status()

Argumente

Keine

Rückgabetyp

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 fortlaufende Nummer, die einen Datensatz im Datenbank-Transaktionsprotokoll identifiziert. LSNs werden so angeordnet, dass eine größere LSN eine Transaktion darstellt, die später in der Sequenz auftritt.

• 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_xmin 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 Reader-Instance in Millisekunden hinter der Writer-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 – Die CPU-Auslastung durch den Replikatprozess. Beachten Sie, dass dies nicht die CPU-Auslastung durch die Instance, sondern durch den Prozess ist. Weitere Informationen zur CPU-Auslastung durch die Instance finden Sie unter Metriken auf Instance-Ebene für Amazon Aurora.

Nutzungshinweise

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 Aurorabeschrieben. 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 in der PostgreSQL-Dokumentation. Weitere Informationen zu Hochverfügbarkeit und Replikation finden Sie unter Häufig gestellte Fragen zu Amazon Aurora.

  Amazon CloudWatch speichert replica_lag_in_msec-Ergebnisse im Laufe der Zeit als AuroraReplicaLag-Metrik. Weitere Informationen zur Verwendung der CloudWatch-Metriken für Aurora finden Sie unter Überwachen von Amazon Aurora-Metriken mit Amazon CloudWatch.

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? im AWS Support Center.

Beispiele

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)