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.
Optimierung der binären Protokollreplikation für Aurora MySQL
Im Folgenden erfahren Sie, wie Sie die Leistung der binären Protokollreplikation optimieren und damit zusammenhängende Probleme in Aurora MySQL beheben können.
Tipp
In dieser Erörterung wird davon ausgegangen, dass Sie mit dem Mechanismus der binären MySQL-Protokollreplikation und dessen Funktionsweise vertraut sind. Hintergrundinformationen finden Sie unter Replication Implementation (Implementierung der Replikation)
Binärprotokollreplikation mit mehreren Threads
Bei der Multithread-Replikation für binäre Protokolle liest ein SQL-Thread Ereignisse aus dem Relay-Log und stellt sie in die Warteschlange, damit SQL-Worker-Threads angewendet werden können. Die SQL-Worker-Threads werden vom Koordinator-Thread verwaltet. Die binären Protokollereignisse werden nach Möglichkeit parallel angewendet. Der Grad der Parallelität hängt von Faktoren wie Version, Parametern, Schemadesign und Workload-Merkmalen ab.
Die Multithread-Binärprotokollreplikation wird in Aurora MySQL Version 3 und in Aurora MySQL Version 2.12.1 und höher unterstützt. Damit ein Multithread-Replikat Binlog-Ereignisse effizient parallel verarbeiten kann, müssen Sie die Quelle für die Multithread-Binärprotokollreplikation konfigurieren, und die Quelle muss eine Version verwenden, die die Parallelitätsinformationen in ihren Binärprotokolldateien enthält.
Wenn eine Aurora MySQL-DB-Instance für die Verwendung der binären Protokollreplikation konfiguriert ist, verwendet die Replikat-Instance standardmäßig die Single-Thread-Replikation für Aurora MySQL-Versionen unter 3.04. Um die Multithread-Replikation zu aktivieren, aktualisieren Sie den replica_parallel_workers Parameter auf einen Wert, der höher ist als 1 in Ihrer benutzerdefinierten Parametergruppe.
Für Aurora MySQL Version 3.04 und höher erfolgt die Replikation standardmäßig in mehreren Threads, wobei die Einstellung auf replica_parallel_workers gesetzt ist. 4 Sie können diesen Parameter in Ihrer benutzerdefinierten Parametergruppe ändern.
Um die Widerstandsfähigkeit Ihrer Datenbank gegen unerwartete Unterbrechungen zu erhöhen, empfehlen wir, die GTID-Replikation auf der Quelle zu aktivieren und auf dem GTIDs Replikat zuzulassen. Um die GTID-Replikation zu ermöglichen, setzen Sie sowohl gtid_mode ON_PERMISSIVE auf der Quelle als auch auf dem Replikat auf. Weitere Informationen zu GTID-basierten Replikationen finden Sie unter Verwenden der GTID basierten Replikation.
Die folgenden Konfigurationsoptionen helfen Ihnen bei der Optimierung der Multithread-Replikation. Informationen zur Verwendung finden Sie unter Replikations- und binäre Protokollierungsoptionen und -Variablen
Optimale Parameterwerte hängen von mehreren Faktoren ab. Beispielsweise wird die Leistung für die Binärprotokollreplikation von Ihren Datenbank-Workload-Merkmalen und der DB-Instanzklasse beeinflusst, auf der das Replikat ausgeführt wird. Daher empfehlen wir, alle Änderungen an diesen Konfigurationsparametern gründlich zu testen, bevor Sie neue Parametereinstellungen auf eine Produktionsinstanz anwenden:
-
binlog_format recommended value— eingestellt aufROW -
binlog_group_commit_sync_delay -
binlog_group_commit_sync_no_delay_count -
binlog_transaction_dependency_history_size -
binlog_transaction_dependency_tracking— der empfohlene Wert istWRITESET -
replica_preserve_commit_order -
replica_parallel_type— der empfohlene Wert istLOGICAL_CLOCK -
replica_parallel_workers -
replica_pending_jobs_size_max -
transaction_write_set_extraction— der empfohlene Wert istXXHASH64
Ihr Schema und Ihre Workload-Merkmale sind Faktoren, die sich parallel auf die Replikation auswirken. Die häufigsten Faktoren sind die folgenden.
Fehlen von Primärschlüsseln — RDS kann keine Writeset-Abhängigkeit für Tabellen ohne Primärschlüssel einrichten. Mit dem
ROWFormat kann eine einzelne mehrzeilige Anweisung mit einem einzigen vollständigen Tabellenscan auf der Quelle ausgeführt werden. Dies führt jedoch zu einem vollständigen Tabellenscan pro Zeile, die auf dem Replikat geändert wurde. Das Fehlen von Primärschlüsseln verringert den Replikationsdurchsatz erheblich.Vorhandensein von Fremdschlüsseln — Wenn Fremdschlüssel vorhanden sind, kann Amazon RDS die Writeset-Abhängigkeit nicht für die Parallelität der Tabellen mit der FK-Beziehung verwenden.
Größe der Transaktionen — Wenn sich eine einzelne Transaktion über Dutzende oder Hunderte von Megabyte oder Gigabyte erstreckt, verbringen der Koordinator-Thread und einer der Worker-Threads möglicherweise viel Zeit damit, nur diese Transaktion zu verarbeiten. Während dieser Zeit können alle anderen Worker-Threads inaktiv bleiben, nachdem sie die Verarbeitung ihrer vorherigen Transaktionen abgeschlossen haben.
In Aurora MySQL Version 3.06 und höher können Sie die Leistung für binäre Protokollreplikate verbessern, wenn Sie Transaktionen für große Tabellen mit mehr als einem sekundären Index replizieren. Diese Funktion führt einen Threadpool ein, um sekundäre Indexänderungen parallel auf ein Binlog-Replikat anzuwenden. Die Funktion wird durch den aurora_binlog_replication_sec_index_parallel_workers DB-Cluster-Parameter gesteuert, der die Gesamtzahl der parallel Threads steuert, die für die Anwendung der sekundären Indexänderungen verfügbar sind. Der Parameter ist standardmäßig auf 0 (deaktiviert) gesetzt. Für die Aktivierung dieser Funktion ist kein Instanzneustart erforderlich. Um diese Funktion zu aktivieren, beenden Sie die laufende Replikation, legen Sie die gewünschte Anzahl parallel Worker-Threads fest und starten Sie die Replikation dann erneut.
Optimierung der Binlog-Replikation
In Aurora MySQL 2.10 und höher wendet Aurora automatisch eine Optimierung an, die als Binlog-I/O-Cache bekannt ist, auf die Binärlog-Replikation. Durch Zwischenspeichern der zuletzt festgeschriebenen Binlog-Ereignisse soll diese Optimierung die Leistung des Binlog-Dump-Threads verbessern und gleichzeitig die Auswirkungen auf Vordergrundtransaktionen auf der Binlog-Quell-Instance begrenzen.
Anmerkung
Dieser für diese Funktion verwendete Speicher ist unabhängig von der binlog_cache MySQL-Einstellung.
Diese Funktion gilt nicht für Aurora DB-Instances, die die db.t2- und db.t3-Instanceklassen verwenden.
Sie müssen keine Konfigurationsparameter anpassen, um diese Optimierung zu aktivieren. Insbesondere, wenn Sie den Konfigurationsparameter in früheren Aurora MySQL-Versionen aurora_binlog_replication_max_yield_seconds auf einen Wert ungleich Null angepasst haben, setzen Sie ihn für aktuell verfügbare Versionen wieder auf Null zurück.
aurora_binlog_io_cache_read_requestsMithilfe der Statusvariablen aurora_binlog_io_cache_reads können Sie überwachen, wie oft die Daten aus dem Binlog-I/O-Cache gelesen werden.
-
aurora_binlog_io_cache_read_requestszeigt die Anzahl der Binlog-I/O-Leseanfragen aus dem Cache an. -
aurora_binlog_io_cache_readszeigt die Anzahl der Binlog-I/O-Lesevorgänge an, die Informationen aus dem Cache abrufen.
Die folgende SQL-Abfrage berechnet den Prozentsatz der Binlog-Leseanforderungen, die die zwischengespeicherten Informationen nutzen. In diesem Fall ist es umso besser, je näher das Verhältnis an 100 liegt.
mysql> SELECT (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads') / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests') * 100 as binlog_io_cache_hit_ratio; +---------------------------+ | binlog_io_cache_hit_ratio | +---------------------------+ | 99.99847949080622 | +---------------------------+
Die Binlog-I/O-Cache-Funktion enthält auch neue Metriken im Zusammenhang mit den Binlog-Dump-Threads. Dump-Threads sind die Threads, die erstellt werden, wenn neue Binlog-Replikate mit der Binlog-Quell-Instance verbunden sind.
Die Metriken des Dump-Threads werden alle 60 Sekunden mit dem Präfix in das Datenbankprotokoll gedruck [Dump thread
metrics]. Die Metriken umfassen Informationen für jedes Binlog-Replikat wie Secondary_id, Secondary_uuid, den Namen der Binlog-Datei und die Position, die jedes Replikat liest. Zu den Metriken gehört auch Bytes_behind_primary, das den Abstand in Byte zwischen Replikationsquelle und Replikat darstellt. Diese Metrik misst die Verzögerung des Replikat-I/O-Threads. Diese Zahl unterscheidet sich von der Verzögerung des Replikat-SQL-Applier-Threads, der durch die seconds_behind_master Metrik auf dem Binlog-Replikat dargestellt wird. Sie können feststellen, ob Binlog-Replikate die Quelle aufholen oder zurückfallen, indem Sie überprüfen, ob die Entfernung abnimmt oder zunimmt.
