Lassen Sie uns über die Lösung für die MySQL-Master-Slave-Verzögerung sprechen

Dieser Artikel vermittelt Ihnen relevantes Wissen über die Master-Slave-Verzögerungsverarbeitungslösung in MySQL. MySQL-Master-Slave-Replikation und Lese-/Schreib-Trennung sind gängige Datenbankarchitekturen im Internet. Der am meisten kritisierte Teil dieser Architektur ist die Datenmenge In Szenarien mit viel Parallelität wird die Master-Slave-Verzögerung schwerwiegend sein. Ich hoffe, es hilft allen.

Warum ist die Master-Slave-Verzögerung so groß?

Antwort: MySQL verwendet einen einzelnen Thread, um RelayLog wiederzugeben.

Wie können wir die Wiedergabezeit optimieren und verkürzen?

Antwort: Die parallele Multithread-Wiedergabe von RelayLog kann die Zeit verkürzen.

Was ist falsch an der parallelen Multithread-Wiedergabe von RelayLog?

Antwort: Sie müssen überlegen, wie Sie das RelayLog aufteilen, damit mehrere Datenbankinstanzen und mehrere Threads das RelayLog ohne Inkonsistenz parallel wiedergeben können.

Warum gibt es Unstimmigkeiten?

Antwort: Wenn das RelayLog zufällig verschiedenen Wiedergabethreads zugewiesen wird, gehen Sie davon aus, dass es im RelayLog drei serielle Änderungsdatensätze gibt:

Kontosatzgeld = 100 aktualisieren, wobei uid = 58 ist;

Kontosatzgeld aktualisieren = 150 wobei uid=58;

Konto aktualisieren, Geld = 200 festlegen, wobei uid=58;

Bei serieller Single-Thread-Wiedergabe: Es kann sichergestellt werden, dass die Ausführungssequenz aller Slave-Bibliotheken und der Hauptbibliothek konsistent ist.

Voiceover: Das endgültige Geld wird 200 betragen.

Wenn mehrere Threads zufällig der Wiedergabe zugewiesen werden: Mehrere Wiedergabe-Threads führen diese drei Anweisungen gleichzeitig aus, es ist ungewiss, wer sie zuletzt ausführt, und die endgültigen Slave-Datenbankdaten können sich von denen der Master-Datenbank unterscheiden.

Voiceover: Mehrere Sklavenbibliotheken haben möglicherweise ein Geld von 100, 150, 200, ich bin mir nicht sicher.

Wie kann ich mehrere Slave-Bibliotheken und mehrere Threads zuweisen und wiedergeben, um konsistente Daten zu erhalten?

Antwort: Für Schreibvorgänge in derselben Bibliothek verwenden Sie denselben Thread, um RelayLog abzuspielen. Für Schreibvorgänge in verschiedenen Bibliotheken können mehrere Threads verwendet werden, um RelayLog gleichzeitig abzuspielen.

Wie geht das?

Antwort: Entwerfen Sie einen Hash-Algorithmus, hashen Sie (Datenbankname) % Thread-Nummer, hashen Sie den Bibliotheksnamen und modulieren Sie dann die Anzahl der Threads. Dies kann problemlos durchgeführt werden, indem Schreibvorgänge in derselben Bibliothek verarbeitet werden Das Gleiche Ein Wiederholungsthread wird seriell ausgeführt.

Voiceover: Die Wiedergabe auf verschiedenen Bibliotheken erfolgt parallel, was die Wiedergabe beschleunigt.

Was sind die Mängel dieses Plans?

Antwort: Viele Unternehmen verwenden „einzelne Datenbank mit mehreren Tabellen“ für MySQL. Wenn dies der Fall ist, gibt es immer noch nur eine Datenbank und die Wiedergabegeschwindigkeit von RelayLog kann nicht verbessert werden.

Erleuchtung: Aktualisieren Sie das DB-Architekturmodell „einzelne Datenbank und mehrere Tabellen“ auf das DB-Architekturmodell „mehrere Datenbanken und mehrere Tabellen“.

Voiceover: In Internet-Geschäftsszenarien mit großen Datenmengen und großer Parallelität bietet das „Multi-Datenbank“-Modell auch viele weitere Vorteile, wie zum Beispiel:

(1) Sehr praktische Instanzerweiterung: Datenbankadministratoren können problemlos verschiedene Bibliotheken erweitern je nach Instanz unterschiedlich;

(2) Bibliotheksisolation nach Geschäft: Geschäftsentkopplung, Geschäftsisolation, Reduzierung der Kopplung und gegenseitigen Beeinflussung

(3) Es ist sehr praktisch, Mikrodienste aufzuteilen: Es ist praktisch, dass jeder Dienst seine eigene hat eigene Instanz

Wie kann im Szenario „einzelne Datenbank und mehrere Tabellen“ die parallele Multithread-Wiedergabe von RelayLog optimiert werden?

Antwort: Auch wenn nur eine Datenbank vorhanden ist, werden Transaktionen gleichzeitig in der Hauptdatenbank ausgeführt. Da sie parallel in der Hauptdatenbank ausgeführt werden können, sollten sie auch parallel in der Slave-Datenbank ausgeführt werden können.

Neue Idee: Teilen Sie Transaktionen, die parallel in der Hauptdatenbank ausgeführt werden, in eine Gruppe ein und nummerieren Sie sie. Die Wiedergabe dieser Transaktionen in der Slave-Datenbank kann parallel ausgeführt werden (die Ausführung von Transaktionen in der Hauptdatenbank geht alle in die Vorbereitung ein Bitte beachten Sie, dass es keine Konflikte zwischen Transaktionen gibt, da sonst kein Commit möglich wäre. Ja, das ist genau das, was MySQL tut.

Lösung: GTID-basierte parallele Replikation.

Ab MySQL 5.7 werden die von der Gruppe übermittelten Informationen in der GTID gespeichert. Mit dem Tool mysqlbinlog können Sie die Informationen in der Gruppenübermittlung anzeigen:

20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=1
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=2
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=3
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=4

Im Vergleich zum Originalprotokoll gibt es mehr last_committed und sequence_number.

Was ist last_committed?

Antwort: Dies ist die Nummer der zuletzt übermittelten Transaktion. Wenn sie denselben last_committed haben, bedeutet dies, dass sie sich in einer Gruppe befinden und gleichzeitig wiedergegeben werden können.

Zusammenfassung

Die parallele MySQL-Replikation, die Methode zur Verkürzung der Master-Slave-Synchronisationsverzögerung, verkörpert einige der folgenden Architekturideen:

Multithreading ist eine gängige Methode zur Verkürzung der Ausführungszeit

Voiceover: Beispielsweise können viele Crontabs Multithreading verwenden, um Daten aufzuteilen und parallel auszuführen.

Wenn Multithreads Aufgaben gleichzeitig versenden, muss die Idempotenz gewährleistet sein: MySQL bietet zwei Methoden: „idempotent gemäß der Bibliothek“ und „idempotent gemäß commit_id“, von denen es sich zu lernen lohnt;

Voiceover: Zum Beispiel Gruppennachrichten kann auf der Gruppen-ID basieren und ist idempotent; Benutzernachrichten können entsprechend der Benutzer-ID idempotent sein.

Speziell für die MySQL-Master-Slave-Synchronisationsverzögerung:

mysql5.5: Parallele Replikation wird nicht unterstützt, jeder sollte die MySQL-Version aktualisieren;

mysql5.6: Parallele Replikation wird laut Bibliothek empfohlen „Multi-Datenbank“-Architektur;

mysql5.7: Paralleles Kopieren gemäß GTID

Empfohlenes Lernen: mysql-Video-Tutorial

Das obige ist der detaillierte Inhalt vonLassen Sie uns über die Lösung für die MySQL-Master-Slave-Verzögerung sprechen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!