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 My SQL

Im Folgenden erfahren Sie, wie Sie die Leistung der Binärprotokollreplikation optimieren und damit verbundene Probleme in Aurora My beheben könnenSQL.

Replikation von Binärprotokollen mit mehreren Threads

Bei der binären Protokollreplikation mit mehreren SQL Threads liest ein Thread Ereignisse aus dem Relay-Log und stellt sie in eine Warteschlange, damit SQL Worker-Threads sie anwenden können. Die SQL Worker-Threads werden von einem Koordinator-Thread verwaltet. Die binären Protokollereignisse werden nach Möglichkeit parallel angewendet.

Die Multithread-Binärprotokollreplikation wird in Aurora My SQL Version 3 und in Aurora My SQL Version 2.12.1 und höher unterstützt.

Wenn eine Aurora My SQL DB-Instance für die Verwendung der binären Protokollreplikation konfiguriert ist, verwendet die Replica-Instance standardmäßig die Single-Thread-Replikation für Aurora SQL My-Versionen unter 3.04. Um die Multithread-Replikation zu aktivieren, aktualisieren Sie den replica_parallel_workers-Parameter in Ihrer benutzerdefinierten Parametergruppe auf einen Wert größer als Null.

Für Aurora My SQL Version 3.04 und höher ist die Replikation standardmäßig Multithreading-fähig, wobei die Einstellung auf replica_parallel_workers gesetzt ist. 4 Sie können diesen Parameter in Ihrer benutzerdefinierten Parametergruppe ändern.

Die folgenden Konfigurationsoptionen helfen Ihnen bei der Optimierung der Multithread-Replikation. Informationen zur Verwendung finden Sie unter Optionen und Variablen für die Replikation und die binäre Protokollierung im SQL Referenzhandbuch.

Die optimale Konfiguration hängt 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. Wir empfehlen daher, alle Änderungen an diesen Konfigurationsparametern gründlich zu testen, bevor Sie neue Parametereinstellungen auf eine Produktionsinstanz anwenden:

In Aurora My SQL 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 My SQL 2.10 und höher wendet Aurora automatisch eine Optimierung an, die als Binlog-I/O-Cache bezeichnet wird, auf die binäre Protokollreplikation. 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.

Sie müssen keine Konfigurationsparameter anpassen, um diese Optimierung zu aktivieren. Insbesondere, wenn Sie den Konfigurationsparameter in früheren SQL Versionen von Aurora My 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.

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 SQL Replikat-Applier-Threads, die durch die seconds_behind_master Metrik im 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.