Wie behebe ich Verzögerungen in meinem RDS-for-SQL-Server-Lesereplikat?

Kurzbeschreibung

Amazon RDS for SQL Server Enterprise Edition unterstützt die Erstellung eines Lesereplikats innerhalb derselben Region. Die Datenreplikation erfolgt asynchron und verwendet die Always-On-Technologie, um Daten von einem Master in eine Replikat-Instance zu replizieren. RDS for SQL Server greift nicht ein, um eine hohe Replikatverzögerung zwischen einer Quell-DB-Instance und ihren Lesereplikaten zu minimieren.

Auflösung

1.    Überprüfen Sie die Ressourcenauslastung auf dem Master und auf der Replikat-Instance mithilfe von Amazon CloudWatch. Verwenden Sie die Funktionen Erweiterte Überwachung und Performance-Insights, um die Ressourcennutzung detailliert zu überprüfen.

Wichtige Überlegungen zu Metriken auf den Master- und Replikat-Instances:

• Stellen Sie sicher, dass die CPU-Nutzung nicht gedrosselt wird. Wenn Sie eine Burstable-Instance-Klasse ausführen, stellen Sie sicher, dass CPU-Credits verfügbar sind oder dass Sie im Unlimited-Modus arbeiten.
• Stellen Sie sicher, dass ausreichend FreeableMemory vorhanden ist. Und stellen Sie sicher, dass ReadIOPS und WriteIOPS die bereitgestellten Grenzen erreichen. Stellen Sie sicher, dass ausreichend Burst-Balance verfügbar ist, wenn Sie ein GP2-Volume verwenden. Weitere Informationen finden Sie unter Wie behebe ich Probleme bei nicht genügend freiem Speicherplatz in meiner RDS-for-SQL-Server-Instance?
• Stellen Sie sicher, dass ReadThroughput und WriteThroughput die Klassengrenzen der Instance nicht erreichen.

2.    Es ist eine bewährte Methode, die Master- und Replikat-Instances mit derselben Instance-Klasse, demselben Speichertyp und derselben Anzahl von IOPS zu erstellen. Dadurch wird eine Replikatverzögerung aufgrund fehlender Ressourcen in der Replikat-Instance vermieden. Darüber hinaus kann das Lesereplikat je nach Workload nach oben oder unten skaliert werden, wenn die Auslastung im Vergleich zur Master-Instance minimal ist.

3.    Identifizieren Sie den Zeitrahmen, in dem die Replikatverzögerung zugenommen hat, und gehen Sie dann wie folgt vor:

Überprüfen Sie die Metriken WriteIOPS, WriteThroughput, NetworkReceiveThroughput und NetworkTrasmitThroughput auf der Master-Instance basierend auf der Startzeit des Replikats. Stellen Sie fest, ob die Verzögerung auf Schreibaktivitäten zurückzuführen ist. Überprüfen Sie dieselben Metriken im gleichen Zeitraum auf dem Lesereplikat.

Prüfen Sie, ob auf der Master-Instance Transaktionen mit langer Laufzeit vorhanden sind. Im Folgenden finden Sie eine Beispielabfrage zum Prüfstatus aktiver Transaktionen:

SELECT * FROM sys.sysprocesses WHERE open_tran = 1;

4.    Überprüfen Sie auf der Replikat-Instance, ob signifikante Wartezeiten oder Deadlocks für Sperren vorhanden sind. Deadlocks treten zwischen Select- und DDL/DML-Transaktionen auf und verursachen Verzögerungen beim Anwenden von Transaktionsprotokollen aus der Master-Instance.

Im Folgenden finden Sie eine Beispielabfrage, um nach Blockierungen zu suchen:

SELECT * FROM sys.sysprocesses WHERE blocked > 0;

5.    Führen Sie eine Abfrage zur Überprüfung auf Replikatverzögerung und maximale Replikatverzögerung durch.

Replikatverzögerung

SELECT AR.replica_server_name
     , DB_NAME (ARS.database_id) 'database_name'
     , AR.availability_mode_desc
     , ARS.synchronization_health_desc
     , ARS.last_hardened_lsn
     , ARS.last_redone_lsn
     , ARS.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states ARS
INNER JOIN sys.availability_replicas AR ON ARS.replica_id = AR.replica_id
--WHERE DB_NAME(ARS.database_id) = 'database_name'
ORDER BY AR.replica_server_name;

Stellen Sie sicher, dass der Wert last_hardened_lsn auf dem Lesereplikat fortschreitet.

Maximale Replikatverzögerung

Für SQL Server ist die Replikatverzögerungsmetrik die maximale Verzögerung von Datenbanken, die zurückgefallen sind, in Sekunden. Wenn Sie beispielsweise zwei Datenbanken mit einer Verzögerung von 5 Sekunden bzw. 10 Sekunden haben, beträgt die Replikatverzögerung 10 Sekunden. Die Replikatverzögerungsmetrik gibt den Wert der folgenden Abfrage zurück. Führen Sie die Abfrage auf der Master-Instance aus.

select max(secondary_lag_seconds) max_lag  from sys.dm_hadr_database_replica_states;

6.    Nachdem Sie die Erstellung des Lesereplikats initiiert haben, wird ein Snapshot von der Master-Instance erstellt und dann wiederhergestellt, um eine Lesereplikat-Instance zu erstellen. Transaktionsprotokolle werden wiedergegeben, um die Daten mit der Master-Instance zu synchronisieren. Nachdem Sie jedoch eine neue Instance erstellt haben, kommt es bei dieser Instance zu einem verzögerten Laden, was zu einer Replikatverzögerung führt. Dies ist erwartetes Verhalten. Um die Auswirkungen des langsamen Ladens zu minimieren, verwenden Sie während der Erstellung des Lesereplikats Speicher vom Typ IO1 und konvertieren Sie ihn dann bei Bedarf zurück in GP2.

7.    Führen Sie Transaktionen in Batches auf der Master-Instance aus. Dadurch werden lange Transaktionen vermieden und die Größe der Transaktionslogdatei wird minimal gehalten. Starten Sie die Replikat-Instance nicht neu, es sei denn, dies ist bei hoher Replikatverzögerung erforderlich, da dies die Wiedergabe von Transaktionsprotokollen weiter verzögert.

8.    Eine Änderung der Instance-Klasse auf der Master- oder Replikati-Instance kann zu einer vorübergehenden Replikatverzögerung führen. Dies ist ein erwartetes Verhalten, da Protokolle von der Master-Instance verarbeitet werden.

Das Ändern des Speichertyps oder der Speichergröße wirkt sich länger auf die Replikatverzögerung aus, bis die Speicheroptimierung abgeschlossen ist. Es ist nicht möglich herauszufinden, wie viel Prozent der Speicheroptimierung auf RDS-Instances abgeschlossen sind.

9.    Wenn das Lesereplikat den Status Speicher voll erreicht, werden die Transaktionsprotokolle von der Master-Instance nicht verarbeitet und die Replikatverzögerung nimmt zu.

Wenn Sie vermuten, dass der Speicherplatz auf TempDB oder temporäre Tabellen zurückzuführen ist, starten Sie die Replikat-Instance neu, um vorübergehend Speicherplatz freizugeben.

10.    Wenn Sie keinen Fortschritt beim Replikatverzögerungsstatus feststellen, überprüfen Sie den Status der Benutzerdatenbanken auf der Replikat-Instance. Um Protokolle erneut abzuspielen, muss der Datenbankstatus Online sein.

Beachten Sie Folgendes:

• Neu erstellte Datenbanken werden erst in die Verzögerungsberechnung einbezogen, wenn sie im Lesereplikat zugänglich sind.
• Replikatverzügerung gibt -1 zurück, wenn RDS die Verzögerung nicht ermitteln kann, z. B. während der Einrichtung des Replikats oder wenn sich das Lesereplikat im Fehlerstatus befindet.

---

Ähnliche Informationen

Arbeiten mit Lesereplikaten für Microsoft SQL Server in Amazon RDS