Eingehende Analyse von MySQL 5.7: Halbsynchrone Replikationstechnologie
Geschichte der Ableitung der Replikationsarchitektur
Bevor wir darüber sprechen Wir werfen zunächst einen Blick auf die Geschichte der Replikationsarchitektur von MySQL. Die MySQL-Replikation ist in vier Typen unterteilt:
Gewöhnliche Replikation, asynchrone und synchrone. Sie ist einfach zu erstellen und weit verbreitet. Diese Architektur ist seit der Geburt von MySQL sehr gut und kann als sehr ausgereift bezeichnet werden. Allerdings sind die Daten in dieser Architektur asynchron, sodass die Gefahr eines Datenbankverlusts besteht.
halbsynchrone Replikation, halbsynchron. Leistung und Funktionalität liegen irgendwo zwischen asynchron und vollständig synchron. Es wurde aus MySQL5.5 geboren, um die Leistung, Vor- und Nachteile der beiden oben genannten Architekturen zu kompromittieren.
Synchronisierungsreplikation, vollständige Synchronisierung. Derzeit befindet sich die offizielle 5.7-Vollsynchronisierungstechnologie auf Basis der Gruppenreplikation in der Laborversion und ist nicht weit von der formalen Integration entfernt. Die vollständige Synchronisierungstechnologie bietet mehr Garantien für die Datenkonsistenz. Ich glaube, dass dies eine wichtige Richtung für die zukünftige Synchronisationstechnologie ist und es sich lohnt, darauf zu blicken.
MySQL-Cluster. Basierend auf der NDB-Engine ist sie einfach zu erstellen und relativ stabil. Sie ist die zuverlässigste Architektur für den Datenschutz in MySQL und derzeit die einzige Architektur mit vollständiger Datensynchronisierung und keinem Datenverlust. Allerdings bin ich in meinem Geschäft wählerisch und habe viele Einschränkungen.
Halbsynchrone Replikation
Wir sprechen heute über die zweite Architektur. Wir wissen, dass die normale Replikation, also die asynchrone Replikation von MySQL, für die Datenreplikation auf dem MySQL-Binärprotokoll, also dem Binärprotokoll, basiert. Beispielsweise gibt es zwei Maschinen, eine ist der Master und die andere ist der Slave.
Normale Replikation ist: Transaktion eins (t1) wird in den Binlog-Puffer geschrieben; der Dumper-Thread benachrichtigt den Slave, dass es eine neue Transaktion t1 gibt; io-Thread empfängt t1 und schreibt in Ihr eigenes Relay-Protokoll; der SQL-Thread des Slaves schreibt in die lokale Datenbank. Zu diesem Zeitpunkt können sowohl der Master als auch der Slave diese neue Transaktion sehen. Selbst wenn der Master stirbt, kann der Slave zum neuen Master befördert werden.
Die abnormale Kopie ist: Transaktion eins (t1) wird in den Binlog-Puffer geschrieben; der Dumper-Thread benachrichtigt den Slave, dass es eine neue Transaktion t1 gibt; Slave war aufgrund eines instabilen Netzwerks nicht verfügbar. t1 wurde empfangen; der Master ist gestorben, der Slave wurde zum neuen Master befördert und t1 ging verloren.
Das große Problem ist: Die Master- und Slave-Transaktionsaktualisierungen sind nicht synchronisiert. Selbst wenn keine Netzwerk- oder anderen Systemanomalien vorliegen, muss der Slave die Transaktion ausführen, wenn das Geschäft gleichzeitig abläuft Batch-Transaktionen werden nacheinander verarbeitet, was zu großen Verzögerungen führt.
Um die Mängel der oben genannten Szenarien auszugleichen, hat MySQL seit 5.5 die Halbsynchronisierung eingeführt. Das heißt, nachdem der Dumper-Thread des Masters den Slave benachrichtigt hat, wird eine Bestätigung hinzugefügt, das heißt, ob der Flag-Code von t1 erfolgreich empfangen wurde. Das heißt, zusätzlich zum Senden von t1 an den Slave ist der Dumper-Thread auch für den Empfang der Bestätigung des Slaves verantwortlich. Wenn eine Ausnahme auftritt und keine Bestätigung empfangen wird, wird automatisch auf die normale Replikation zurückgestuft, bis die Ausnahme behoben ist.
Wir können die neuen Probleme sehen, die durch die Halbsynchronisation entstehen:
Wenn eine Ausnahme auftritt, wird sie auf die normale Replikation herabgestuft. Dann wird die Wahrscheinlichkeit einer Dateninkonsistenz auf der Slave-Maschine verringert, aber nicht vollständig beseitigt.
Der Host-Dumper-Thread nimmt mehr Arbeit in Anspruch, was offensichtlich die Leistung der gesamten Datenbank verringert.
Im Eingehende Analyse von MySQL 5.7: halbsynchrone Replikationstechnologie-Modus, der in MySQL 5.5 und 5.6 verwendet wird, das heißt, wenn der Slave die Transaktion nicht empfängt, also bevor sie in das Relay-Protokoll und das Netzwerk geschrieben wird ist abnormal oder instabil. Wenn der Master auflegt, wechselt das System zum Slave und die Daten auf beiden Seiten sind inkonsistent. In diesem Fall verfügt der Slave über eine Transaktionsdaten weniger.
Mit der Veröffentlichung von MySQL 5.7 wurde die halbsynchrone Replikationstechnologie auf eine neue verlustfreie halbsynchrone Replikationsarchitektur aktualisiert und ihre Reife, Datenkonsistenz und Ausführungseffizienz verbessert deutlich verbessert.
Verbesserungen der Datenreplikationseffizienz in MySQL 5.7
Die Master-Slave-Konsistenz wurde verbessert und unterstützt das Warten auf ACK vor dem Festschreiben der Transaktion
Neu Version Semi-Sync fügt den Parameter rpl_semi_sync_master_wait_point hinzu, um zu steuern, wie die Master-Datenbank Transaktionen festschreibt, bevor sie im Semi-Sync-Modus erfolgreich an die Sitzungstransaktion zurückgegeben wird.
Dieser Parameter hat zwei Werte:
-
AFTER_COMMIT (5.6 Standardwert)
Master schreibt jede Transaktion in Binlog und übergibt sie zur Aktualisierung an den Slave Festplatte (Relay-Protokoll) und die Hauptdatenbank schreibt gleichzeitig die Transaktion fest. Der Master wartet auf die Rückmeldung des Slaves, um das Relay-Protokoll zu erhalten. Erst nach Erhalt der Bestätigung gibt der Master das Commit-OK-Ergebnis an den Client zurück.
-
AFTER_SYNC (Standard in 5.7, aber nicht in 5.6)
Master schreibt jede Transaktion in Binlog und übergibt Go to Slave und Flush auf die Festplatte (Relay-Protokoll). Nachdem der Master auf die Rückmeldung des Slaves gewartet hat, um die Bestätigung des Relay-Protokolls zu erhalten, übermittelt er die Transaktion und gibt das Commit-OK-Ergebnis an den Client zurück. Selbst wenn die Hauptbibliothek abstürzt, werden alle Transaktionen, die in der Hauptbibliothek festgeschrieben wurden, garantiert mit dem Relay-Protokoll des Slaves synchronisiert.
Daher wurde mit 5.7 der After_sync-Modus eingeführt. Der Hauptvorteil besteht darin, das Problem der durch Eingehende Analyse von MySQL 5.7: halbsynchrone Replikationstechnologie verursachten Dateninkonsistenz zu lösen Modus, alle Commits Alle Daten wurden repliziert und die Datenkonsistenz wird während des Failovers verbessert.
Leistungsverbesserung, Unterstützung für asynchrones Senden von Binlog und Empfangen von Bestätigungen
Die alte Version von Semi-Sync ist aufgrund von Dump The durch Dump-Threads eingeschränkt Der Thread übernimmt zwei verschiedene und sehr häufige Aufgaben: das Übertragen des Binlogs an den Slave und das Warten auf Rückmeldung vom Slave. Darüber hinaus muss der Dump-Thread auf die Rückkehr des Slaves warten, bevor er die nächste Ereignistransaktion überträgt. Der Dump-Thread ist zum Engpass bei der Verbesserung der Leistung der gesamten Halbsynchronisation geworden. In Geschäftsszenarien mit hoher Parallelität wirkt sich ein solcher Mechanismus auf die Gesamt-TPS der Datenbank aus.
Um die oben genannten Probleme zu lösen, wird in der 5.7-Version des Semi-Sync-Frameworks speziell ein unabhängiger Ack-Collector-Thread verwendet, um Rückmeldungsinformationen vom Slave zu empfangen. Auf diese Weise gibt es zwei unabhängig voneinander arbeitende Threads auf dem Master, die gleichzeitig Binlog an den Slave senden und Feedback vom Slave erhalten können.
Leistungsverbesserung, Kontrolle der Anzahl erfolgreicher Slave-Schreibtransaktionsrückmeldungen, die von der Masterbibliothek empfangen werden
MySQL 5.7 fügt den Parameter rpl_semi_sync_Eingehende Analyse von MySQL 5.7: halbsynchrone Replikationstechnologie hinzu , die verwendet werden kann, um zu steuern, wie viele Feedbacks zu erfolgreichen Slave-Schreibtransaktionen die Hauptbibliothek akzeptiert, was Flexibilität für den Wechsel der Hochverfügbarkeitsarchitektur bietet.
Wie in der Abbildung gezeigt, muss der Master bei einem Zählwert von 2 auf Bestätigungen von zwei Slaves warten.
Leistungsverbesserung, Binlog-Mutex-Verbesserung
Die alte Version der halbsynchronen Replikation fügt dem Binlog in der Hauptübermittlungs-Binlog-Schreibsitzung und dem Dump-Thread, der das Binlog liest, eine Mutex-Sperre hinzu Dies führt dazu, dass das Lesen und Schreiben von Binlog-Dateien serialisiert wird und es zu Parallelitätsproblemen kommt.
MySQL 5.7 hat die Binlog-Sperre in den folgenden zwei Aspekten optimiert:
1. Die Mutex-Sperre des Dump-Threads für Binlog wurde hinzugefügt.
Die Sicherheitsmarge wurde hinzugefügt Lesesicherheit von Binlog
Leistungsverbesserung, Gruppenübermittlung
MySQL 5.7 führt einen neuen variablen Slave-Parallel-Typ ein, der konfigurierbar ist Werte sind:
1. DATABASE (Standardwert vor 5.7), parallele Replikationsmethode basierend auf Bibliothek
2, parallele Replikationsmethode basierend auf Gruppenübermittlung; 🎜>MySQL Version 5.6 unterstützt auch die sogenannte parallele Replikation, ihre Parallelität basiert jedoch nur auf DATABASE, also auf Bibliotheken. Wenn in der MySQL-Datenbankinstanz des Benutzers mehrere DATENBANKEN vorhanden sind, kann dies tatsächlich von großem Nutzen für die Geschwindigkeit der Slave-Replikation sein. Wenn die Benutzerinstanz nur über eine Datenbank verfügt, ist eine parallele Wiedergabe nicht möglich und die Leistung ist sogar schlechter der ursprüngliche Einzelthread Unterschied.
MySQL 5.7 fügt einen neuen Parallelmodus hinzu: Transaktionen, die gleichzeitig in die COMMIT-Phase eintreten, erhalten dieselbe Sequenznummer. Diese Transaktionen mit derselben Sequenznummer können gleichzeitig in der Standby-Datenbank ausgeführt werden.
MySQL 5.7 implementiert tatsächlich die parallele Replikation. Der Hauptgrund dafür ist, dass die Wiedergabe des Slave-Servers mit der des Hosts übereinstimmt. Das heißt, die parallele Wiedergabe erfolgt auf dem Slave genau so, wie sie ausgeführt wird parallel auf dem Master-Server. Es gibt keine Einschränkungen mehr für die bibliotheksbasierte parallele Replikation und es gibt keine besonderen Anforderungen für das binäre Protokollformat (ebenso wie es keine Anforderungen für die bibliotheksbasierte parallele Replikation gibt).
Daher ist die Sequenz, die in der folgenden Sequenz gleichzeitig sein kann (die erste Nummer ist last_committed und die nächste Nummer ist sequence_number):
Parallelregeln für Standby-Datenbanken: Beim Verteilen von a Transaktion, deren last_committed-Sequenznummer kleiner als die minimale sequence_number der aktuell ausgeführten Transaktion ist, ist die Ausführung zulässig. Deshalb:
trx1 1…..2
trx2 1………….3
trx3 1…………………….4
trx4 2……………………….5
trx5 3…………………………..6
trx6 3………………………………7
trx7 6………………………………..8
Nach dem Login kopieren
1. Nachdem trx1 ausgeführt wurde, kann last_commit 2. Nachdem trx1 ausgeführt wurde, kann last_commit 3. Nachdem die Ausführung von trx2 abgeschlossen ist, kann last_commit
Übersicht
Wir glauben, dass die Optimierung der halbsynchronen Replikationstechnologie in MySQL Version 5.7 deren Reife und Ausführung erheblich verbessert hat Effizienz. Wir empfehlen, dass Sie bei der Verwendung von MySQL 5.7 als Produktionsumgebung die Halbsynchronisierungstechnologie als Datenreplikationslösung für hohe Verfügbarkeit und Lese-/Schreibtrennung verwenden können.
Das obige ist der detaillierte Inhalt vonEingehende Analyse von MySQL 5.7: halbsynchrone Replikationstechnologie. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
