Die Replikation in MySQL gibt es schon seit langer Zeit und wurde im Laufe der Jahre stetig verbessert. Es war eher eine Evolution als eine Revolution. Das ist vollkommen verständlich, da die Replikation ein wichtiges Feature ist, auf das sich viele verlassen – es muss funktionieren.
In den letzten MySQL-Versionen haben wir Verbesserungen der Replikationsleistung durch die Unterstützung der parallelen Anwendung von Transaktionen festgestellt. In MySQL 5.6 wurde die Parallelisierung auf Schemaebene durchgeführt – alle Transaktionen, die in separaten Schemas ausgeführt wurden, konnten auf einmal ausgeführt werden. Dies war eine schöne Verbesserung für Workloads mit mehreren Schemas auf einem einzelnen Server, und die Last wurde mehr oder weniger gleichmäßig auf die Schemas verteilt.
In MySQL 5.7 wurde eine weitere Parallelisierungsmethode hinzugefügt, die sogenannte „logische Uhr“. Es ermöglichte ein gewisses Maß an Parallelität auf einem Slave, selbst wenn alle Ihre Daten in einem einzigen Schema gespeichert wurden. Kurz gesagt basierte es auf der Tatsache, dass einige Transaktionen aufgrund einer durch die Hardware hinzugefügten Latenz zusammen festgeschrieben würden. Sie könnten diese Latenz sogar manuell hinzufügen, um eine bessere Parallelisierung auf den Slaves mit binlog_group_commit_sync_delay zu erreichen.
Diese Lösung war wirklich nett, aber nicht ohne Nachteile. Jede Verzögerung beim Festschreiben einer Transaktion kann sich letztendlich auf benutzerseitige Teile der Anwendung auswirken. Sicher, Sie können Verzögerungen im Bereich von mehreren Millisekunden einstellen, aber selbst dann ist es eine zusätzliche Latenz, die die App verlangsamt.
Verbesserungen der Replikationsleistung in MySQL 8.0
MySQL 8.0, das sich derzeit (August 2017) noch im Beta-Stadium befindet, bringt einige nette Verbesserungen für die Replikation. Ursprünglich wurde es für Group Replication (GR) entwickelt, aber da GR unter der Haube eine regelmäßige Replikation verwendet, profitierte die „normale“ MySQL-Replikation davon. Die von uns erwähnte Verbesserung sind Abhängigkeitsverfolgungsinformationen, die im Binärlog gespeichert sind. Was passiert ist, dass MySQL 8.0 jetzt eine Möglichkeit hat, Informationen darüber zu speichern, welche Zeilen von einer bestimmten Transaktion betroffen waren (sogenanntes Writeset), und es vergleicht Writesets von verschiedenen Transaktionen. Dadurch ist es möglich, diejenigen Transaktionen zu identifizieren, die bei derselben Teilmenge von Zeilen nicht funktioniert haben, und diese können daher parallel angewendet werden. Dies kann es ermöglichen, den Parallelisierungsgrad im Vergleich zur Implementierung von MySQL 5.7 um ein Vielfaches zu erhöhen. Was Sie beachten müssen, ist, dass ein Slave schließlich eine andere Ansicht der Daten sehen wird, eine, die nie auf dem Master angezeigt wurde. Dies liegt daran, dass Transaktionen möglicherweise in einer anderen Reihenfolge als auf dem Master angewendet werden. Dies sollte jedoch kein Problem darstellen. Die aktuelle Implementierung der Multithread-Replikation in MySQL 5.7 kann dieses Problem ebenfalls verursachen, es sei denn, Sie aktivieren ausdrücklich die Slave-Preserve-Commit-Order.
Um dieses neue Verhalten zu steuern, eine Variable binlog_transaction_dependency_tracking wurde vorgestellt. Es kann drei Werte annehmen:
- COMMIT_ORDER:Dies ist die Standardeinstellung, sie verwendet den in MySQL 5.7 verfügbaren Standardmechanismus.
- WRITESET:Es ermöglicht eine bessere Parallelisierung und der Master beginnt, Writeset-Daten im Binärlog zu speichern.
- WRITESET_SESSION:Dies stellt sicher, dass Transaktionen auf dem Slave in der richtigen Reihenfolge ausgeführt werden und das Problem mit einem Slave, der einen Datenbankstatus sieht, der auf dem Master nie gesehen wurde, beseitigt wird. Es reduziert die Parallelisierung, kann aber immer noch einen besseren Durchsatz als die Standardeinstellungen bieten.
Benchmark
Im Juli schrieb Vitor Oliveira auf mysqlhighavailability.com einen Beitrag, in dem er versuchte, die Leistung neuer Modi zu messen. Er nutzte das Best-Case-Szenario – keinerlei Haltbarkeit – um den Unterschied zwischen alten und neuen Modi zu demonstrieren. Wir haben uns entschieden, den gleichen Ansatz zu verwenden, diesmal in einem realistischeren Setup:binäres Log aktiviert mit log_slave_updates. Die Haltbarkeitseinstellungen wurden auf den Standardwerten belassen (also sync_binlog=1 – das ist der neue Standard in MySQL 8.0, Doublewrite-Puffer aktiviert, InnoDB-Prüfsummen aktiviert usw.). Die einzige Ausnahme in der Haltbarkeit war innodb_flush_log_at_trx_commit auf 2 gesetzt
Wir haben m4.2xl-Instanzen, 32 GB, 8 Kerne verwendet (also wurde slave_parallel_workers auf 8 gesetzt). Wir haben auch das Skript sysbench, oltp_read_write.lua verwendet. 16 Millionen Zeilen in 32 Tabellen wurden auf 1000 GB gp2-Volume gespeichert (das sind 3000 IOPS). Wir haben die Leistung aller Modi für 1, 2, 4, 8, 16 und 32 gleichzeitige Sysbench-Verbindungen getestet. Der Prozess war wie folgt:Slave stoppen, 100.000 Transaktionen ausführen, Slave starten und berechnen, wie lange es dauert, die Slave-Verzögerung zu beseitigen.
Zunächst einmal wissen wir nicht wirklich, was passiert ist, als Sysbench mit nur 1 Thread ausgeführt wurde. Jeder Test wurde fünfmal nach einem Aufwärmlauf durchgeführt. Diese spezielle Konfiguration wurde zweimal getestet – die Ergebnisse sind stabil:Singlethread-Workload war am schnellsten. Wir werden es weiter untersuchen, um zu verstehen, was passiert ist.
Ansonsten entsprechen die restlichen Ergebnisse unseren Erwartungen. COMMIT_ORDER ist am langsamsten, besonders bei geringem Datenverkehr, 2-8 Threads. WRITESET_SESSION ist in der Regel leistungsstärker als COMMIT_ORDER, aber langsamer als WRITESET für wenig gleichzeitigen Datenverkehr.
Wie kann es mir helfen?
Der erste Vorteil liegt auf der Hand:Wenn Ihre Arbeitslast auf der langsamen Seite ist, Ihre Slaves jedoch dazu neigen, bei der Replikation zurückzufallen, können sie von einer verbesserten Replikationsleistung profitieren, sobald der Master auf 8.0 aktualisiert wird. Zwei Anmerkungen hier:Erstens - dieses Feature ist abwärtskompatibel und auch 5.7-Slaves können davon profitieren. Zweitens – eine Erinnerung daran, dass sich 8.0 noch im Beta-Stadium befindet. Wir empfehlen Ihnen nicht, Beta-Software in der Produktion zu verwenden, obwohl dies dringend erforderlich ist, um dies zu testen. Diese Funktion kann Ihnen nicht nur helfen, wenn Ihre Sklaven hinterherhinken. Sie können vollständig aufgeholt werden, aber wenn Sie einen neuen Slave erstellen oder einen vorhandenen neu bereitstellen, wird dieser Slave hinterherhinken. Die Möglichkeit, den „WRITESET“-Modus zu verwenden, beschleunigt die Bereitstellung eines neuen Hosts erheblich.
Alles in allem wird diese Funktion eine viel größere Wirkung haben, als Sie vielleicht denken. Angesichts all der Benchmarks, die Regressionen in der Leistung zeigen, wenn MySQL Verkehr mit geringer Parallelität verarbeitet, ist alles, was dazu beitragen kann, die Replikation in solchen Umgebungen zu beschleunigen, eine enorme Verbesserung.
Wenn Sie Zwischenmaster verwenden, ist dies ebenfalls ein Merkmal, auf das Sie achten sollten. Jeder zwischengeschaltete Master fügt etwas Serialisierung hinzu, wie Transaktionen gehandhabt und ausgeführt werden – in der realen Welt ist die Arbeitslast auf einem zwischengeschalteten Master fast immer weniger parallel als auf dem Master. Die Verwendung von Writesets zur Ermöglichung einer besseren Parallelisierung verbessert nicht nur die Parallelisierung auf dem Zwischen-Master, sondern kann auch die Parallelisierung auf allen seinen Slaves verbessern. Es ist sogar möglich (obwohl es ernsthafte Tests erfordern würde, um sicherzustellen, dass alle Teile richtig passen), einen 8.0-Zwischenmaster zu verwenden, um die Replikationsleistung Ihrer Slaves zu verbessern (bitte denken Sie daran, dass MySQL 5.7-Slave Writeset-Daten verstehen und trotzdem verwenden kann). es kann es nicht selbst erzeugen). Natürlich klingt die Replikation von 8.0 auf 5.7 ziemlich schwierig (und das liegt nicht nur daran, dass 8.0 noch Beta ist). Unter bestimmten Umständen kann dies funktionieren und die CPU-Auslastung auf Ihren 5.7-Slaves beschleunigen.
Andere Änderungen in der MySQL-Replikation
Die Einführung von Writesets ist zwar am interessantesten, aber nicht die einzige Änderung, die bei der MySQL-Replikation in MySQL 8.0 vorgenommen wurde. Lassen Sie uns einige andere, ebenfalls wichtige Änderungen durchgehen. Wenn Sie zufällig einen Master verwenden, der älter als MySQL 5.0 ist, unterstützt 8.0 sein binäres Protokollformat nicht. Wir erwarten nicht viele solcher Setups, aber wenn Sie ein sehr altes MySQL mit Replikation verwenden, ist es definitiv an der Zeit für ein Upgrade.
Standardwerte wurden geändert, um sicherzustellen, dass die Replikation so absturzsicher wie möglich ist:master_info_repository und relay_log_info_repository sind auf TABELLE eingestellt. Expire_log_days wurde ebenfalls geändert - jetzt ist der Standardwert 30. Zusätzlich zu expire_log_days wurde eine neue Variable hinzugefügt, binlog_expire_log_seconds , was eine feinkörnigere Binlog-Rotationsrichtlinie ermöglicht. Einige zusätzliche Zeitstempel wurden dem Binärlog hinzugefügt, um die Beobachtbarkeit von Replikationsverzögerungen zu verbessern und Mikrosekunden-Granularität einzuführen.
Dies ist auf keinen Fall eine vollständige Liste der Änderungen und Funktionen im Zusammenhang mit der MySQL-Replikation. Wenn Sie mehr erfahren möchten, können Sie die MySQL-Änderungsprotokolle überprüfen. Stellen Sie sicher, dass Sie alle überprüft haben - bisher wurden Funktionen in allen 8.0-Versionen hinzugefügt.
Wie Sie sehen können, verändert sich die MySQL-Replikation immer noch und wird besser. Wie wir zu Beginn gesagt haben, muss es ein langsamer Prozess sein, aber es ist wirklich großartig zu sehen, was vor uns liegt. Es ist auch schön zu sehen, wie die Arbeit für die Gruppenreplikation nach unten sickert und in der „normalen“ MySQL-Replikation wiederverwendet wird.
