Optimieren einer binären Protokollreplikation für Aurora MySQL - Amazon Aurora
Multithread-Replikation für binäre ProtokolleOptimieren einer Binlog-ReplikationIn-Memory-Relay-Protokoll

Optimieren einer 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) in der MySQL-Dokumentation.

Multithread-Replikation für binäre Protokolle

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-Eigenschaften ab.

Die Multithread-Replikation für binäre Protokolle wird in Aurora-MySQL-Version 3 und 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-Replikation für binäre Protokolle konfigurieren, und die Quelle muss eine Version verwenden, die die Parallelitätsinformationen in ihren Binärprotokolldateien enthält.

Wenn eine DB-Instance von Aurora MySQL 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 niedriger als 3.04. Zum Aktivieren der Multithread-Replikation aktualisieren Sie den Parameter replica_parallel_workers in Ihrer benutzerdefinierten Parametergruppe auf einen Wert größer als 1.

Für Aurora-MySQL-Version 3.04 und höher erfolgt die Replikation standardmäßig mit mehreren Threads, wobei replica_parallel_workers auf 4 gesetzt ist. Sie können diesen Parameter in Ihrer benutzerdefinierten Parametergruppe ändern.

Zum Erhöhen der Ausfallsicherheit Ihrer Datenbank gegen unerwartete Unterbrechungen empfehlen wir, die GTID-Replikation in der Quelle und GTIDs im Replikat zuzulassen. Zum Zulassen der GTID-Replikation setzen Sie gtid_mode sowohl in der Quelle als auch im Replikat auf ON_PERMISSIVE. 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 im MySQL-Verweishandbuch. Weitere Informationen zur Multithread-Replikation finden Sie im MySQL-Blog Verbesserung des parallelen Anwenders durch schreibsatzbasierte Abhängigkeitsverfolgung.

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-Instance-Klasse beeinflusst, auf der das Replikat ausgeführt wird. Daher empfehlen wir Ihnen, alle Änderungen an diesen Konfigurationsparametern gründlich zu testen, bevor Sie neue Parametereinstellungen auf eine Produktions-Instance anwenden:

  • binlog_format recommended value – festlegen auf ROW

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

  • binlog_transaction_dependency_history_size

  • binlog_transaction_dependency_tracking – empfohlener Wert ist WRITESET

  • replica_preserve_commit_order

  • replica_parallel_type – empfohlener Wert ist LOGICAL_CLOCK

  • replica_parallel_workers

  • replica_pending_jobs_size_max

  • transaction_write_set_extraction – empfohlener Wert ist XXHASH64

Ihr Schema und Ihre Workload-Eigenschaften sind Faktoren, die sich parallel auf die Replikation auswirken. Zu den häufigsten Faktoren zählen folgende:

  • Fehlen von Primärschlüsseln – RDS kann keine Schreibsatzabhängigkeit für Tabellen ohne Primärschlüssel einrichten. Mit dem ROW-Format kann eine einzelne mehrzeilige Anweisung mit einem einzigen vollständigen Tabellenscan in der Quelle ausgeführt werden. Dies führt jedoch zu einem vollständigen Tabellenscan pro Zeile, die im 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 Schreibsatzabhä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 Thread-Pool ein, um sekundäre Indexänderungen parallel auf ein Binlog-Replikat anzuwenden. Die Funktion wird durch den DB-Cluster-Parameter aurora_binlog_replication_sec_index_parallel_workers gesteuert, der die Gesamtzahl der parallelen Threads steuert, die für die Anwendung der sekundären Indexänderungen verfügbar sind. Der Parameter ist standardmäßig auf 0 (deaktiviert) eingestellt. Für die Aktivierung dieser Funktion ist kein Instance-Neustart erforderlich. Zum Aktivieren dieser Funktion beenden Sie die laufende Replikation, legen die gewünschte Anzahl paralleler Worker-Threads fest und starten die Replikation dann erneut.

Optimieren einer 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-Instance-Klassen verwenden.

Sie müssen keine Konfigurationsparameter anpassen, um diese Optimierung zu aktivieren. Insbesondere wenn Sie den Konfigurationsparameter aurora_binlog_replication_max_yield_seconds in früheren Aurora-MySQL-Versionen auf einen Wert ungleich null eingestellt hatten, setzen Sie ihn für derzeit verfügbare Versionen auf null zurück.

Die Statusvariablen aurora_binlog_io_cache_reads und aurora_binlog_io_cache_read_requests helfen Ihnen zu überwachen, wie oft die Daten aus dem Binlog-E/A-Cache gelesen werden.

  • aurora_binlog_io_cache_read_requests zeigt die Anzahl der Binlog-I/O-Leseanfragen aus dem Cache an.

  • aurora_binlog_io_cache_reads zeigt 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.

In-Memory-Relay-Protokoll

In Aurora-MySQL-Version 3.10 und höher führt Aurora eine Optimierung ein, die als In-Memory-Relay-Protokoll bekannt ist, um den Replikationsdurchsatz zu verbessern. Diese Optimierung verbessert die E/A-Leistung des Relay-Protokolls, indem dessen gesamte Zwischeninhalte im Speicher zwischengespeichert werden. Dadurch wird die Verzögerung beim Festschreiben reduziert, indem die E/A-Operationen im Speicher minimiert werden, da der Inhalt des Relay-Protokolls im Speicher weiterhin leicht zugänglich ist.

Standardmäßig ist die In-Memory-Relay-Protokollfunktion automatisch für von Aurora verwaltete Replikationsszenarien (einschließlich Blau/Grün-Bereitstellungen, Aurora-Aurora-Replikationen und regionsübergreifende Replikate) aktiviert, wenn das Replikat eine der folgenden Konfigurationen erfüllt:

  • Singlethread-Replikationsmodus (replica_parallel_workers = 0)

  • Multithread-Replikation mit aktiviertem GTID-Modus:

    • Automatische Positionierung aktiviert

    • GTID-Modus im Replikat auf ON gesetzt

  • Dateibasierte Replikation mit replica_preserve_commit_order = ON

Die In-Memory-Relay-Protokollfunktion wird für Instance-Klassen unterstützt, die größer als t3.large sind, ist aber für Aurora Serverless-Instances nicht verfügbar. Der zirkuläre Puffer des Relay-Protokolls hat eine feste Größe von 128 MB. Zum Überwachen des Speicherverbrauchs dieser Funktion können Sie die folgende Abfrage ausführen:

SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache';

Die In-Memory-Relay-Protokollfunktion wird durch den Parameter aurora_in_memory_relaylog gesteuert, der entweder auf DB-Cluster- oder Instance-Ebene festgelegt werden kann. Sie können diese Funktion dynamisch aktivieren oder deaktivieren, ohne Ihre Instance neu starten zu müssen:

  1. Stoppen Sie die laufende Replikation.

  2. Setzen Sie aurora_in_memory_relaylog in der Parametergruppe auf ON (zum Aktivieren) oder OFF (zum Deaktivieren).

  3. Starten Sie die Replikation neu.

Beispiel:

CALL mysql.rds_stop_replication;
set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group
CALL mysql.rds_start_replication;

Selbst wenn aurora_in_memory_relaylog auf ON gesetzt ist, kann die In-Memory-Relay-Protokollfunktion unter bestimmten Bedingungen immer noch deaktiviert sein. Verwenden Sie den folgenden Befehl, um den aktuellen Status der Funktion zu überprüfen:

SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status';

Wenn die Funktion unerwartet deaktiviert wird, können Sie den Grund ermitteln, indem Sie Folgendes ausführen:

SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason';

Dieser Befehl gibt eine Meldung zurück, in der erklärt wird, warum die Funktion derzeit deaktiviert ist.