In Teil I haben wir ein High Availability (HA)-Framework für MySQL-Hosting vorgestellt und verschiedene Komponenten und ihre Funktionalität besprochen. Jetzt werden wir in Teil II die Details der halbsynchronen MySQL-Replikation und die zugehörigen Konfigurationseinstellungen besprechen, die uns dabei helfen, Redundanz und Konsistenz der Daten in unserem HA-Setup sicherzustellen. Schauen Sie auf jeden Fall wieder bei Teil III vorbei, in dem wir verschiedene Fehlerszenarien besprechen, die auftreten könnten, und die Art und Weise, wie das Framework auf diese Bedingungen reagiert und sich von diesen erholt.
Was ist halbsynchrone MySQL-Replikation?
Einfach ausgedrückt, in einer semisynchronen MySQL-Replikationskonfiguration schreibt der Master Transaktionen erst an die Speicher-Engine, nachdem er eine Bestätigung von mindestens einem der Slaves erhalten hat. Die Slaves würden eine Bestätigung erst bereitstellen, nachdem die Ereignisse empfangen und in die Relaisprotokolle kopiert und auch auf die Festplatte geleert wurden. Dies garantiert, dass für alle Transaktionen, die festgeschrieben und an den Client zurückgegeben werden, die Daten auf mindestens 2 Knoten vorhanden sind. Der Begriff „halb“ in halbsynchron (Replikation) ist auf die Tatsache zurückzuführen, dass der Master die Transaktionen festschreibt, sobald die Ereignisse empfangen und in das Relaisprotokoll geschrieben werden, aber nicht unbedingt in die Datendateien auf dem Slave festgeschrieben werden. Dies steht im Gegensatz zur vollständig synchronen Replikation, bei der die Transaktion sowohl auf dem Slave als auch auf dem Master festgeschrieben wurde, bevor die Sitzung zum Client zurückkehrt.
Semisynchrone Replikation, die nativ in MySQL verfügbar ist, hilft dem HA-Framework, Datenkonsistenz und Redundanz für festgeschriebene Transaktionen sicherzustellen. Im Falle eines Ausfalls des Masters wären alle Transaktionen, die auf dem Master festgeschrieben wurden, auf mindestens einen der Slaves repliziert worden (in den Relay-Protokollen gespeichert). Infolgedessen wäre ein Failover zu diesem Slave verlustfrei, da der Slave auf dem neuesten Stand ist (nachdem die Relay-Protokolle des Slaves vollständig gelöscht wurden).
Replikation und halbsynchrone zugehörige Einstellungen
Lassen Sie uns einige der wichtigsten MySQL-Einstellungen besprechen, die verwendet werden, um ein optimales Verhalten für hohe Verfügbarkeit und Datenkonsistenz in unserem Framework sicherzustellen.
Verwaltung der Ausführungsgeschwindigkeit der Sklaven
Die erste Überlegung besteht darin, das 'semi'-Verhalten der semisynchronen Replikation zu handhaben, das nur garantiert, dass die Daten empfangen und vom E/A-Thread des Slave, aber nicht unbedingt vom SQL-Thread festgeschrieben. Standardmäßig ist der SQL-Thread in einem MySQL-Slave Single-Threaded und kann nicht mit dem Master Schritt halten, der Multi-Threaded ist. Die offensichtliche Auswirkung davon ist, dass im Falle eines Master-Ausfalls der Slave nicht auf dem neuesten Stand ist, da sein SQL-Thread immer noch die Ereignisse im Relay-Protokoll verarbeitet. Dies verzögert den Failover-Prozess, da unser Framework erwartet, dass der Slave vollständig auf dem neuesten Stand ist, bevor er heraufgestuft werden kann. Dies ist notwendig, um die Datenkonsistenz zu wahren. Um dieses Problem anzugehen, aktivieren wir Multi-Thread-Slaves mit der Option slave_parallel_workers, um die Anzahl paralleler SQL-Threads festzulegen, um Ereignisse in den Relay-Logs zu verarbeiten.
Außerdem konfigurieren wir die folgenden Einstellungen, die sicherstellen, dass der Slave nicht in einen Zustand eintritt, in dem sich der Master nicht befand:
- slave-parallel-type =LOGICAL_CLOCK
- slave_preserve_commit_order =1
Dies bietet uns eine stärkere Datenkonsistenz. Mit diesen Einstellungen werden wir in der Lage sein, eine bessere Parallelisierung und Geschwindigkeit auf dem Slave zu erreichen, aber wenn es zu viele parallele Threads gibt, erhöht sich auch der Aufwand für die Koordination zwischen den Threads und kann die Vorteile leider zunichte machen.
Eine weitere Konfiguration, die wir verwenden können, um die Effizienz der parallelen Ausführung auf den Slaves zu erhöhen, ist die Abstimmung von binlog_group_commit_sync_delay auf dem Master. Indem Sie dies auf master setzen, enthalten die Binärlog-Einträge auf dem Master und damit die Relay-Log-Einträge auf dem Slave Batches von Transaktionen, die von den SQL-Threads parallel verarbeitet werden können. Dies wird ausführlich in J-F Gagnés Blog erklärt, wo er dieses Verhalten als „den Master verlangsamen, um den Slave zu beschleunigen“ bezeichnet .
Wenn Sie Ihre MySQL-Bereitstellungen über die ScaleGrid-Konsole verwalten, haben Sie die Möglichkeit, die Replikationsverzögerung der Slaves kontinuierlich zu überwachen und Echtzeitwarnungen zu erhalten. Außerdem können Sie die oben genannten Parameter dynamisch anpassen, um sicherzustellen, dass die Slaves Hand in Hand mit dem Master arbeiten, wodurch Ihre Zeit für einen Failover-Prozess minimiert wird.
MySQL High Availability Framework erklärt – Teil IIClick To Tweet
Wichtige halbsynchrone Replikationsoptionen
Die semisynchrone MySQL-Replikation kann konstruktionsbedingt auf den asynchronen Modus zurückgreifen, basierend auf den Slave-Bestätigungs-Timeout-Einstellungen oder basierend auf der Anzahl der semisynchron-fähigen Slaves, die zu einem beliebigen Zeitpunkt verfügbar sind. Der asynchrone Modus bietet per Definition keine Garantie dafür, dass festgeschriebene Transaktionen an den Slave repliziert werden, und daher würde ein Verlust des Masters zum Verlust der nicht replizierten Daten führen. Das Standarddesign des ScaleGrid HA-Frameworks besteht darin, ein Zurückfallen in den asynchronen Modus zu vermeiden. Sehen wir uns die Konfigurationen an, die dieses Verhalten beeinflussen.
-
rpl_semi_sync_master_wait_for_slave_count
Diese Option wird verwendet, um die Anzahl der Slaves zu konfigurieren, die eine Bestätigung senden müssen, bevor ein semisynchroner Master die Transaktion festschreiben kann. In der 3-Knoten-Master-Slave-Konfiguration setzen wir dies auf 1, damit wir immer sicher sein können, dass die Daten in mindestens einem Slave verfügbar sind, und gleichzeitig Leistungseinbußen beim Warten auf die Bestätigung von beiden Slaves vermeiden.
-
rpl_semi_sync_master_timeout
Diese Option wird verwendet, um die Zeitspanne zu konfigurieren, die ein semisynchroner Master auf eine Bestätigung von einem Slave wartet, bevor er wieder in den asynchronen Modus wechselt. Wir setzen dies auf einen relativ hohen Timeout-Wert, sodass es keinen Fallback zum asynchronen Modus gibt.
Da wir mit 2 Slaves arbeiten und rpl_semi_sync_master_wait_for_slave_count auf 1 gesetzt ist, haben wir festgestellt, dass mindestens einer der Slaves innerhalb einer angemessenen Zeit und der Master bestätigt schaltet bei vorübergehenden Netzwerkunterbrechungen nicht in den asynchronen Modus um.
-
rpl_semi_sync_master_wait_no_slave
Dies steuert, ob der Master auf den Ablauf der von rpl_semi_sync_master_timeout konfigurierten Timeout-Periode wartet, selbst wenn die Slave-Anzahl während der Timeout-Periode auf weniger als die von rpl_semi_sync_master_wait_for_slave_count konfigurierte Anzahl von Slaves fällt. Wir behalten den Standardwert ON bei, damit der Master nicht auf die asynchrone Replikation zurückgreift.
Auswirkungen des Verlustes aller halbsynchronen Slaves
Wie wir oben gesehen haben, verhindert unser Framework, dass der Master zur asynchronen Replikation wechselt, wenn alle Slaves ausfallen oder für den Master unerreichbar werden. Die direkte Auswirkung davon ist, dass Schreibvorgänge auf dem Master blockiert werden, was sich auf die Verfügbarkeit des Dienstes auswirkt. Dies ist im Wesentlichen wie durch das CAP-Theorem über die Beschränkungen jedes verteilten Systems beschrieben. Das Theorem besagt, dass wir bei Vorhandensein einer Netzwerkpartition entweder Verfügbarkeit oder Konsistenz wählen müssen, aber nicht beides. Netzwerkpartitionen können in diesem Fall als MySQL-Slaves betrachtet werden, die vom Master getrennt sind, weil sie entweder ausgefallen oder nicht erreichbar sind.
Unser Konsistenzziel besteht darin, sicherzustellen, dass die Daten für alle festgeschriebenen Transaktionen auf mindestens zwei Knoten verfügbar sind. Folglich bevorzugt das ScaleGrid HA-Framework in solchen Fällen die Konsistenz der Verfügbarkeit. Weitere Schreibvorgänge werden von Clients nicht akzeptiert, obwohl der MySQL-Master weiterhin die Leseanforderungen bedient. Dies ist eine bewusste Designentscheidung, die wir als Standardverhalten getroffen haben, das natürlich basierend auf den Anwendungsanforderungen konfigurierbar ist.
Stellen Sie sicher, dass Sie den ScaleGrid-Blog abonnieren, damit Sie Teil III nicht verpassen, in dem wir weitere Fehlerszenarien und Wiederherstellungsmöglichkeiten des MySQL-HA-Frameworks diskutieren werden . Bleiben Sie dran!!
