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.
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.
Anmerkung
Die Verwaltung des Cluster-Cache wird für Aurora-PostgreSQL-DB-Cluster, die Teil der globalen Aurora-Datenbanken sind, nicht unterstützt. Es wird empfohlen, dass kein Workload auf dem angegebenen Tier-0-Leser ausgeführt wird.
Inhalt
Konfigurieren der Cluster-Cache-Verwaltung
Führen Sie die folgenden Prozesse der Reihe nach aus, um die Cluster-Cache-Verwaltung zu konfigurieren.
Themen
Anmerkung
Warten Sie nach Abschluss dieser Schritte mindestens 1 Minute ab, damit die Cluster-Cache-Verwaltung voll einsatzbereit ist.
Aktivieren der Cluster-Cache-Verwaltung
Um die Cluster-Cache-Verwaltung zu aktivieren, führen Sie die im Folgenden beschriebenen Schritte aus,.
So aktivieren Sie die Cluster-Cacheverwaltung:
-
Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/
. -
Wählen Sie im Navigationsbereich Parameter groups (Parametergruppen) aus.
-
Wählen Sie die Parametergruppe für Ihren Aurora PostgreSQL-DB-Cluster in der Liste aus.
Der DB-Cluster muss eine andere als die Standardparametergruppe verwenden, da die Werte in dieser Gruppe nicht geändert werden können.
-
Wählen Sie für Parameter group actions (Parametergruppenaktionen) die Option Bearbeiten.
-
Legen Sie den Wert des Cluster-Parameters
apg_ccm_enabledauf 1 fest. -
Wählen Sie Änderungen speichern aus.
Verwenden Sie zum Aktivieren der Cluster-Cacheverwaltung für einen Aurora-PostgreSQL-DB-Cluster den AWS CLI modify-db-cluster-parameter-group-Befehl mit den folgenden erforderlichen Parametern:
-
--db-cluster-parameter-group-name -
--parameters
Beispiel
Für Linux, macOSoder Unix:
aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-namemy-db-cluster-parameter-group\ --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"
Windows:
aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-namemy-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.
So legen Sie die Prioritätsstufe für das Hochstufen auf die Writer-DB-Instance auf „tier-0“ fest
Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/
. -
Wählen Sie im Navigationsbereich Databases (Datenbanken) aus.
-
Wählen Sie die Writer-DB-Instance des Aurora PostgreSQL-DB-Clusters aus.
-
Wählen Sie Modify aus. Die Seite Modify DB Instance (DB-Instance ändern) wird angezeigt.
-
Wählen Sie im Bereich Zusätzliche Konfiguration für Failover priority (Failover-Priorität) die Option tier-0 aus.
-
Klicken Sie auf Weiter und überprüfen Sie die Zusammenfassung aller Änderungen.
-
Wählen Sie Apply immediately (Sofort anwenden) aus, um die Änderungen nach dem Speichern sofort zu übernehmen.
-
Klicken Sie auf Modify DB Instance (DB-Instance ändern), um Ihre Änderungen zu speichern.
Um die Prioritätsstufe für das Hochstufen auf 0 für die Writer-DB-Instance mithilfe der festzulegenAWS CLI, rufen Sie den modify-db-instance Befehl mit den folgenden erforderlichen Parametern auf:
-
--db-instance-identifier -
--promotion-tier -
--apply-immediately
Beispiel
Für Linux, macOSoder Unix:
aws rds modify-db-instance \ --db-instance-identifierwriter-db-instance\ --promotion-tier 0 \ --apply-immediately
Windows:
aws rds modify-db-instance ^ --db-instance-identifierwriter-db-instance^ ---promotion-tier 0 ^ --apply-immediately
Festlegen der Prioritätsstufe für das Hochstufen für eine Reader-DB-Instance
Sie müssen nur eine Reader-DB-Instance für die Cluster-Cache-Verwaltung festlegen. 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.
So legen Sie die Prioritätsstufe für das Hochstufen auf die Reader-DB-Instance auf „tier-0“ fest
Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/
. -
Wählen Sie im Navigationsbereich Databases (Datenbanken) aus.
-
Wählen Sie eine Reader-DB-Instance aus dem Aurora PostgreSQL-DB-Cluster aus, der der Instance-Klasse der Writer-DB-Instance entspricht.
-
Wählen Sie Modify aus. Die Seite Modify DB Instance (DB-Instance ändern) wird angezeigt.
-
Wählen Sie im Bereich Zusätzliche Konfiguration für Failover priority (Failover-Priorität) die Option tier-0 aus.
-
Klicken Sie auf Weiter und überprüfen Sie die Zusammenfassung aller Änderungen.
-
Wählen Sie Apply immediately (Sofort anwenden) aus, um die Änderungen nach dem Speichern sofort zu übernehmen.
-
Klicken Sie auf Modify DB Instance (DB-Instance ändern), um Ihre Änderungen zu speichern.
Um die Prioritätsstufe für das Hochstufen auf 0 für die Reader-DB-Instance mithilfe der festzulegenAWS CLI, rufen Sie den modify-db-instance Befehl mit den folgenden erforderlichen Parametern auf:
-
--db-instance-identifier -
--promotion-tier -
--apply-immediately
Beispiel
Für Linux, macOSoder Unix:
aws rds modify-db-instance \ --db-instance-identifierreader-db-instance\ --promotion-tier 0 \ --apply-immediately
Windows:
aws rds modify-db-instance ^ --db-instance-identifierreader-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.
-
buffers_sent_last_minute– Die Anzahl der Puffer, die in der letzten Minute an den designierten Reader gesendet wurden. buffers_found_last_minute– Die Anzahl der Puffer, auf die in der letzten Minute häufig zugegriffen wurde.-
buffers_sent_last_scan– Die Anzahl der Puffer, die während des letzten vollständigen Scanvorgangs des Puffercaches an den designierten Reader gesendet wurden. -
buffers_found_last_scan– Die Anzahl der Puffer, die häufig aufgerufen wurden und die während des letzten vollständigen Scanvorgangs des Puffercaches gesendet werden mussten. Puffer, die bereits im Cache des designierten Readers abgelegt wurden, werden nicht gesendet. -
buffers_sent_current_scan– Die Anzahl der Puffer, die während des aktuellen Scanvorgangs bisher gesendet wurden. -
buffers_found_current_scan– Die Anzahl der Puffer, die während des aktuellen Scanvorgangs häufig aufgerufen wurden. -
current_scan_progress– Die Anzahl der Puffer, die während des aktuellen Scanvorgangs bisher besucht wurden.
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();
Fehlerbehebung 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ätsstufe für das Hochstufen ist auf festgelegt0. Andere Reader-Instances im DB-Cluster sollten eine Hochstufungsstufe ungleich Null haben und die Cluster-Cache-Verwaltung ist für diese Instances deaktiviert.
Die folgenden Gründe können zu Problemen in der Konfiguration führen und die Cluster-Cache-Verwaltung deaktivieren:
Wenn keine einzelne Reader-DB-Instance auf Hochstufungsstufe 0 festgelegt ist.
Wenn die Writer-DB-Instance nicht auf Hochstufungsstufe 0 festgelegt ist.
Wenn mehr als eine Reader-DB-Instance auf Hochstufungsstufe 0 festgelegt ist.
Wenn der Writer und eine Reader-DB-Instance mit Hochstufungsstufe 0 nicht dieselbe Instance-Größe haben.
