Schnelle Wiederherstellung nach Failover mit der Cluster-Cacheverwaltung für Aurora PostgreSQL

Verwenden Sie bei einem Failover zur schnellen Wiederherstellung der Writer-DB-Instance in den Aurora PostgreSQL-Clustern die Cluster-Cacheverwaltung für Amazon Aurora PostgreSQL. Die Cluster-Cacheverwaltung stellt bei einem Failover die Anwendungsleistung sicher.

Bei einem typischen Failover kommt es möglicherweise zu einem temporären, aber erheblichen Leitungsabfall. Dieser Abfall ist darauf zurückzuführen, dass der Puffercache beim Start der Failover-DB-Instance leer ist. Ein leerer Cache wird auch als kalter Cache bezeichnet. Ein kalter Cache beeinträchtigt die Leistung, da die DB-Instance vom langsameren Datenträger lesen muss, statt die im Puffercache gespeicherten Werte nutzen zu können.

Mit der Cluster-Cacheverwaltung legen Sie eine bestimmte Reader-DB-Instance als Failover-Ziel fest. Die Cluster-Cacheverwaltung stellt sicher, dass die Daten im Cache des designierten Readers mit den Cachedaten der Writer-DB-Instance synchronisiert werden. Der vorab gefüllte Cache des designierten Readers wird als warmer Cache bezeichnet. Wenn ein Failover auftritt, verwendet der designierte Reader Werte in seinem warmen Cache, sobald er auf die neue Writer-DB-Instance hochgestuft wird. Dank dieses Ansatzes wird die Wiederherstellungsleistung Ihrer Anwendung deutlich verbessert.

Die Cluster-Cacheverwaltung erfordert, dass die zugeordnete Reader-Instance den gleichen Instance-Klassentyp und dieselbe Größe (zum Beispiel db.r5.2xlarge oder db.r5.xlarge) hat wie der Writer. Denken Sie daran, wenn Sie Ihre Aurora PostgreSQL-DB-Cluster erstellen, damit Ihr Cluster während eines Failovers wiederhergestellt werden kann. Eine Auflistung der Instance-Klassentypen und -größen finden Sie unter Hardware-Spezifikationen für DB-Instance-Klassen für Aurora.

Konfigurieren der Cluster-Cache-Verwaltung

Führen Sie die folgenden Prozesse der Reihe nach aus, um die Cluster-Cache-Verwaltung zu konfigurieren.

Aktivieren der Cluster-Cache-Verwaltung

Um die Cluster-Cache-Verwaltung zu aktivieren, führen Sie die im Folgenden beschriebenen Schritte aus,.

aws rds modify-db-cluster-parameter-group \
    --db-cluster-parameter-group-name my-db-cluster-parameter-group \
    --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"

aws rds modify-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name my-db-cluster-parameter-group ^
    --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"

Festlegen der Prioritätsstufe für das Hochstufen für die Writer-DB-Instance

Für die Cluster-Cache-Verwaltung muss die Prioritätsstufe für das Hochstufen für die Writer-DB-Instance des Aurora PostgreSQL-DB-Clusters tier-0 sein. Die Prioritätsstufe für das Hochstufen gibt die Reihenfolge an, in der ein Aurora-Reader nach einem Ausfall zur Writer-DB-Instance hochgestuft wird. Gültige Werte sind 0 – 15, wobei 0 die erste und 15 die letzte Prioritätsstufe darstellt. Weitere Informationen zur Hochstufungspriorität finden Sie unter Fehlertoleranz für einen Aurora-DB-Cluster.

aws rds modify-db-instance \
    --db-instance-identifier writer-db-instance \
    --promotion-tier 0 \
    --apply-immediately

aws rds modify-db-instance ^
    --db-instance-identifier writer-db-instance ^
    ---promotion-tier 0  ^
    --apply-immediately

Festlegen der Prioritätsstufe für das Hochstufen für eine Reader-DB-Instance

Sie dürfen nur eine Reader-DB-Instance für die Cluster-Cache-Verwaltung einrichten. Wählen Sie dazu einen Reader aus dem Aurora PostgreSQL-Cluster aus, der dieselbe Instance-Klasse und -Größe hat wie die Writer-DB-Instance. Wenn der Writer beispielsweise db.r5.xlarge verwendet, dann wählen Sie einen Reader aus, der denselben Instance-Klassentyp und dieselbe Größe verwendet. Legen Sie dann die Prioritätsstufe für das Hochstufen auf 0 fest.

Die Prioritätsstufe für das Hochstufen gibt die Reihenfolge an, in der ein Aurora-Reader nach einem Ausfall zur Writer-DB-Instance hochgestuft wird. Gültige Werte sind 0 – 15, wobei 0 die erste und 15 die letzte Prioritätsstufe darstellt.

aws rds modify-db-instance \
    --db-instance-identifier reader-db-instance \
    --promotion-tier 0 \
    --apply-immediately

aws rds modify-db-instance ^
    --db-instance-identifier reader-db-instance ^
    ---promotion-tier 0  ^
    --apply-immediately

Überwachung des Puffercaches

Nach dem Einrichten der Cluster-Cache-Verwaltung können Sie den Synchronisierungsstatus zwischen dem Puffercache der Writer-DB-Instance und dem Warm-Puffercache des jeweiligen Readers überwachen. Um den Inhalt des Puffercache sowohl auf der Writer-DB-Instance als auch auf der angegebenen Reader-DB-Instance zu untersuchen, verwenden Sie das PostgreSQL-Modul pg_buffercache. Weitere Informationen finden Sie in der PostgreSQL pg_buffercache-Dokumentation.

Verwendung der aurora_ccm_status-Funktion

Die Cluster-Cacheverwaltung stellt außerdem die Funktion aurora_ccm_status zur Verfügung. Verwenden Sie die Funktion aurora_ccm_status auf der Writer-DB-Instance, um die folgenden Informationen zum Verlauf des Cache-Warmings auf dem designierten Reader abzurufen.

Das folgende Beispiel veranschaulicht, wie ein Teil der Ausgabe mithilfe der Funktion aurora_ccm_status in eine aktive Rate und einen aktiven Prozentsatz konvertiert wird.

SELECT buffers_sent_last_minute*8/60 AS warm_rate_kbps, 
   100*(1.0-buffers_sent_last_scan::float/buffers_found_last_scan) AS warm_percent 
   FROM aurora_ccm_status();

Problembehandlung bei der CCM-Konfiguration

Wenn Sie den apg_ccm_enabled Cluster-Parameter aktivieren, wird die Cluster-Cache-Verwaltung automatisch auf Instance-Ebene auf der Writer-DB-Instance und einer Reader-DB-Instance auf dem Aurora PostgreSQL-DB-Cluster aktiviert. Die Writer- und Reader-Instance sollten denselben Instance-Klassentyp und dieselbe Größe verwenden. Ihre Priorität in der Beförderungsstufe ist auf festgelegt0. Für andere Reader-Instances im DB-Cluster sollte eine Heraufstufungsstufe ungleich Null gelten, und die Cluster-Cache-Verwaltung ist für diese Instances deaktiviert.

Die folgenden Gründe können zu Problemen bei der Konfiguration und zur Deaktivierung der Cluster-Cache-Verwaltung führen: