Eine kurze Analyse der parallelen WriteSet-Replikation von MySQL

【Historischer Hintergrund】

Ich arbeite seit drei Jahren als MySQL-DBA und habe die Entwicklung von MySQL von „grundsätzlich verfügbar“ über „MySQL kann auf Randsystemen verwendet werden“ bis hin zu „Oh Scheiße! Warum verwendest du kein MySQL?“ miterlebt.

Wie das Sprichwort sagt! „Das Schicksal einer Datenbank hängt sowohl vom historischen Prozess als auch von ihrem eigenen Kampf ab!“ Ich werde hier nicht auf den „historischen Prozess“ eingehen. Was den „Selbstkampf“ betrifft, möchte ich nur über mehrere wichtige Zeitknoten der parallelen Replikation sprechen.

Im Allgemeinen hat MySQL bisher drei Schlüsselzeitknoten für die parallele Replikation erlebt: "Datenbankübergreifende Parallelität", "Gruppen-Commit" und "Schreibsatz". Man kann sagen, dass jede Generation ihre eigenen Talente hat und die vorherigen Wellen am Strand sterben. Im Allgemeinen sind die späteren viel besser als die vorherigen!

[Bibliotheksübergreifende Parallelität]

Die theoretische Grundlage für die Parallelität zwischen Datenbanken ist folgende: In einer Instanz können mehrere Bibliotheken (Schemata) vorhanden sein, und es besteht keine Abhängigkeit zwischen verschiedenen Bibliotheken. Daher wird für jede Bibliothek (Schema) auf der Slave-Seite ein separater SQL-Thread gestartet. Auf diese Weise kann die Effizienz der Master-Slave-Replikation durch parallele Multithread-Replikation verbessert werden.

Diese Theorie klingt gut, aber tatsächlich gibt es nur eine Geschäftsbibliothek für eine Instanz, sodass diese Art der Parallelität zwischen Bibliotheken nutzlos ist. Das heißt, diese Methode ist auf relativ wenige Szenarien anwendbar und dieser Mangel wurde erst durch die „Gruppenübermittlung“ behoben!

【Gruppeneinreichung】

Die theoretische Grundlage des Gruppen-Commits lautet wie folgt: Wenn mehrere Transaktionen gleichzeitig festgeschrieben werden können, weist dies indirekt darauf hin, dass bei den Sperren dieser Transaktionen kein Konflikt vorliegt, d. h. sie verfügen jeweils über unterschiedliche Sperren und beeinflussen sich nicht gegenseitig. Logischerweise betrachten wir mehrere Transaktionen als Gruppe und weisen sie SQL-Threads zur Ausführung in Einheiten von „Gruppen“ auf dem Slave zu, sodass mehrere SQL-Threads parallel ausgeführt werden können. Die Granularität der Parallelität basiert nicht auf der Datenbank, der Effekt ist besser als bei „Parallelität zwischen Datenbanken“.

Dies bringt tatsächlich einige Probleme mit sich, da ein gewisses Maß an Parallelität in der Datenbank erforderlich ist. Andernfalls kann es in jeder Gruppe nur eine Transaktion geben, was sich nicht von der seriellen Transaktion unterscheidet. Um dieses Problem zu lösen, bietet MySQL zwei Parameter, die vor dem Senden warten möchten, damit die Gruppe so viele Transaktionen wie möglich enthält, um die Effizienz der parallelen Replikation zu verbessern.

„ binlog_group_commit_sync_no_delay_count “ legt eine niedrigere Grenze fest, das heißt, eine Gruppe muss vor dem Commit über genügend Transaktionen verfügen, um zu verhindern, dass die Gruppe nie über genügend Transaktionen verfügt.

Für mehrere Transaktionen stellt MySQL auch einen weiteren Parameter „ binlog_group_commit_sync_delay “ basierend auf der Zeit bereit. Dieser Parameter gibt an, wie lange maximal gewartet werden soll. Nach dieser Zeit wird die Transaktion festgeschrieben, auch wenn die Transaktion nicht abgeschlossen ist.

Persönliche Erfahrung! Besonders schwierig ist es, für diese beiden Parameter geeignete Werte zu finden. Selbst wenn sie heute geeignet sind, können sie nach einigen Tagen, wenn sich das Geschäft ändert, ungeeignet werden. Es wäre großartig, wenn MySQL selbst einen adaptiven Effekt erzielen könnte. Dieser adaptive Effekt kann nur durch WriteSet erzielt werden (WriteSet wird nicht durch automatisches Anpassen dieser beiden Parameter erzielt, sondern verwendet einen völlig anderen Lösungsansatz).

【Schreibsatz】

Welches Problem löst WriteSet? Natürlich ist das Problem der „Gruppeneinreichung“ gelöst! Das ist dasselbe wie nichts zu sagen, also geben wir ein (akademischeres) Beispiel: Angenommen, Sie haben am ersten Tag die Zeile mit der ID == 1 aktualisiert, und am zweiten Tag haben Sie die Zeile mit der ID == 2 aktualisiert, und am dritten Tag kam ein Slave, um Ihre Daten zu synchronisieren! Aufgrund der Natur des „Gruppen-Commits“ werden diese beiden Aktualisierungen in unterschiedliche „Gruppen“ gepackt, das heißt, es gibt zwei Gruppen; da es in jeder Gruppe nur eine Transaktion gibt, sind sie logisch seriell!

Als DBA können Sie sehen, dass diese beiden tatsächlich in dieselbe Gruppe gepackt werden können, da sie nicht miteinander in Konflikt stehen und selbst wenn sie in dieselbe Gruppe gepackt werden, führt dies nicht zu Dateninkonsistenzen. Sie haben also zwei Möglichkeiten

Methode 1): Schwester, du bist mutig genug, „binlog_group_commit_sync_no_delay_count“ auf 2 zu setzen, das heißt, eine Gruppe muss mindestens zwei Transaktionen enthalten, und „ binlog_group_commit_sync_delay “ auf mehr als 24 Stunden zu setzen! Wenn Sie es wirklich tun, können Sie nach Hause gehen, Ihre Datenbank ist zu langsam (das erste Update hat einen Tag gewartet), um abgeschlossen zu werden!

Methode 2): Bitten Sie MySQL, in einem kleinen Notizbuch aufzuzeichnen, was es kürzlich geändert hat. Wenn die jetzt zu ändernden Daten nicht mit den vorherigen Daten in Konflikt stehen, können sie in dieselbe Gruppe gepackt werden. Wenn wir immer noch unser vorheriges Beispiel verwenden, da die ID des am zweiten Tag geänderten Werts == 2 ist, steht sie nicht mit der des ersten Tages in Konflikt, sodass die Aktualisierung des zweiten Tages und die Aktualisierung des ersten Tages vollständig in dieselbe Gruppe gepackt werden können. Auf diese Weise gibt es zwei Transaktionen in der Gruppe, und wenn der Slave sie am dritten Tag erneut wiedergibt, tritt ein paralleler Effekt ein.

Dieses kleine Notizbuch ist so toll, kann es größer gemacht werden? sicherlich! Der Parameter binlog_transaction_dependency_history_size ist die Kapazität des kleinen Notizbuchs. Verfügt mein MySQL über dieses kleine Notizbuch? Wenn Ihr MySQL neuer als mysql-5.7.22 ist, ist das kleine Notizbuch integriert.

Das heißt, "WriteSet" basiert auf der Grundlage der riesigen "Gruppenübermittlung" und ist eine selbstanpassende Verpackung und Gruppierung auf dem Master, sodass Sie dem Master nur zwei Parameter hinzufügen müssen

binlog_transaction_dependency_tracking = WRITESET # COMMIT_ORDER   
Transaktionsschreibsatzextraktion = XXHASH64

Nachdem wir nun die Theorie behandelt haben, schauen wir uns die Praxis an.

【WriteSet-Übung】

Ich werde nicht näher darauf eingehen, wie man eine parallele Replikationsumgebung auf der Basis von WriteSet erstellt, also wie man auf dem Master zwei weitere Parameter hinzufügt als beim normalen „Gruppen-Commit“. Ich werde nur die Verhaltensänderungen unter den beiden parallelen Replikationsmodi beschreiben.

1): Das Ziel-SQL, das wir ausführen möchten, ist wie folgt

Datenbank tempdb erstellen;
verwenden Sie Tempdb;
Tabelle „Person“ erstellen (ID „int“, ungleich null, Auto-Inkrement, Primärschlüssel, Name „int“).

in Person(Name) Werte(1) einfügen;
in Person(Name) Werte(2) einfügen;
in Person(Name) Werte(3) einfügen;
in Person(Name) Werte(5) einfügen;

2): Schauen Sie sich die Gruppierung der obigen SQL nach Gruppenübermittlung an

3): Sehen Sie, wie write_set die Gruppenübermittlung optimiert

Sie können sehen, dass jeder Insert parallel ausgeführt werden kann, sodass sie in derselben Gruppe gruppiert werden (dasselbe last_committed); last_committed, sequence_number, diese beiden Werte werden im Binlog aufgezeichnet. Beim Parsen des Binlogs verwende ich normalerweise die folgenden Optionen

mysqlbinlog -vvv --base64-output='Zeilen dekodieren' mysql-bin.000002

【Zusammenfassen】

WriteSet ist eine neue parallele Replikationsimplementierung, die auf der Methode „Group Commit“ basiert. Es ist flexibler als „Group Commit“. Aufgrund der erhöhten Parallelität weist WriteSet natürlich eine bessere Leistung auf als „Group Commit“. Wenn einige WriteSets Konflikte nicht lösen können, können sie problemlos in den Modus „Group Commit“ wechseln.

Oben finden Sie eine kurze Analyse der Details der parallelen Replikation von MySQL WriteSet. Weitere Informationen zur parallelen Replikation von MySQL WriteSet finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!