Beherrschen Sie die Lösung für die MySQL-Master-Slave-Verzögerung vollständig

Dieser Artikel vermittelt Ihnen relevantes Wissen über MySQL, in dem hauptsächlich Probleme im Zusammenhang mit der Lösung der Master-Slave-Verzögerung organisiert werden, einschließlich der Frage, was eine Master-Slave-Verzögerung ist, der Quelle der Master-Slave-Verzögerung und der Lösung der Master-Slave-Verzögerung Werfen wir einen Blick auf den folgenden Inhalt. Ich hoffe, er ist für alle hilfreich.

Empfohlenes Lernen: MySQL-Video-Tutorial

In früheren Projekten wurde die Lese-/Schreibtrennung basierend auf MySQL-Master-Slave-Replikation und AOP implementiert, und ich habe auch einen Blog geschrieben, um diesen Implementierungsprozess aufzuzeichnen. Da die MySQL-Master-Slave-Replikation konfiguriert ist, wird es natürlich zu einer Master-Slave-Verzögerung kommen, wie die Auswirkungen der Master-Slave-Verzögerung auf das Anwendungssystem minimiert werden können Implementierung der Lese-/Schreibtrennung, die Essenz der MySQL-Master-Slave-Replikation.

Zu diesem Thema habe ich schon früher darüber nachgedacht, einen Blog zu schreiben, um es zu teilen, aber ich habe es nie auf die Tagesordnung gesetzt. Kürzlich hat ein Leser eine Nachricht mit dieser Frage in „SpringBoot Implements MySQL Read-Write Separation“ hinterlassen, die mich auch dazu inspiriert hat, diesen Artikel zu schreiben. Zu diesem Thema habe ich viele Informationen und Blogs gelesen und durch meine eigene Praxis diesen Blog zusammengefasst, indem ich auf den Schultern des Chefs stand.

Was ist eine Master-Slave-Verzögerung?

Bevor wir besprechen, wie die Master-Slave-Verzögerung gelöst werden kann, wollen wir zunächst verstehen, was eine Master-Slave-Verzögerung ist.

Um die Master-Slave-Replikation abzuschließen, muss die Slave-Bibliothek den vom Dump-Thread in der Master-Bibliothek gelesenen Binlog-Inhalt über den E/A-Thread abrufen und ihn in ihr eigenes Relay-Protokoll und dann in den SQL-Thread schreiben Wenn die Slave-Bibliothek das Relay-Protokoll liest, entspricht das erneute Erstellen des Protokolls dem erneuten Ausführen von SQL und dem Aktualisieren Ihrer eigenen Datenbank, um Datenkonsistenz zu erreichen.

Zu den Zeitpunkten im Zusammenhang mit der Datensynchronisierung gehören hauptsächlich die folgenden drei:

1. Die Hauptbibliothek beendet die Ausführung einer Transaktion, schreibt sie in das Binlog und zeichnet diesen Moment als T1 auf.
2. Danach wird sie an die Slave-Bibliothek übergeben , und die Slave-Bibliothek empfängt diese Zeit im Binlog als T2.
3. Die Slave-Bibliothek führt diese Transaktion aus und zeichnet diese Zeit als T3 auf.

Die sogenannte Master-Slave-Verzögerung ist die Differenz zwischen dem Zeitpunkt, zu dem die Ausführung der Slave-Bibliothek abgeschlossen ist, und dem Zeitpunkt, zu dem die Ausführung der Hauptbibliothek für dieselbe Transaktion abgeschlossen ist, nämlich T3 - T1. T3 - T1。

可以在备库上执行 show slave status 命令，它的返回结果里面会显示 seconds_behind_master，用于表示当前备库延迟了多少秒。
seconds_behind_master 的计算方法是这样的：

1. 每个事务的 binlog 里面都有一个时间字段，用于记录主库上写入的时间；
2. 备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值，得到 seconds_behind_master。

在网络正常的时候，日志从主库传给从库所需的时间是很短的，即 T2 - T1 的值是非常小的。也就是说，网络正常情况下，主从延迟的主要来源是从库接收完 binlog 和执行完这个事务之间的时间差。

由于主从延迟的存在，我们可能会发现，数据刚写入主库，结果却查不到，因为可能还未同步到从库。主从延迟越严重，该问题也愈加明显。

主从延迟的来源

主库和从库在执行同一个事务的时候出现时间差的问题，主要原因包括但不限于以下几种情况：

• 有些部署条件下，从库所在机器的性能要比主库性能差。
• 从库的压力较大，即从库承受了大量的请求。
• 执行大事务。因为主库上必须等事务执行完成才会写入 binlog，再传给备库。如果一个主库上语句执行 10 分钟，那么这个事务可能会导致从库延迟 10 分钟。
• 从库的并行复制能力。

主从延迟的解决方案

解决主从延迟主要有以下方案：

1. 配合 semi-sync 半同步复制；
2. 一主多从，分摊从库压力；
3. 强制走主库方案（强一致性）；
4. sleep 方案：主库更新后，读从库之前先 sleep 一下；
5. 判断主备无延迟方案（例如判断 seconds_behind_master
Sie können den Befehl show Slave Status auf der Standby-Datenbank ausführen. Als Ergebnis wird seconds_behind_master angezeigt, der angibt, wie viele Sekunden die aktuelle Standby-Datenbank hat verzögert.
seconds_behind_master wird wie folgt berechnet:
6. Im Binlog jeder Transaktion gibt es ein Zeitfeld, das zum Aufzeichnen der in die Hauptdatenbank geschriebenen Zeit verwendet wird.

Abrufen von Standby-Datenbank Der Wert des Zeitfelds der aktuell ausgeführten Transaktion wird berechnet und die Differenz zwischen diesem und der aktuellen Systemzeit wird berechnet, um seconds_behind_master zu erhalten.

Wenn das Netzwerk normal ist, ist die zum Übertragen von Protokollen von der Master-Datenbank zur Slave-Datenbank erforderliche Zeit sehr kurz, d. h. der Wert von T2 - T1 ist sehr klein. Mit anderen Worten: Unter normalen Netzwerkbedingungen ist die Hauptquelle der Master-Slave-Verzögerung der Zeitunterschied zwischen dem Empfang des Binlogs durch die Slave-Bibliothek und der Ausführung der Transaktion.

Aufgrund der Master-Slave-Verzögerung stellen wir möglicherweise fest, dass die Daten gerade erst in die Master-Datenbank geschrieben wurden, das Ergebnis jedoch nicht gefunden werden kann, da es möglicherweise noch nicht mit der Slave-Datenbank synchronisiert wurde. Je gravierender die Master-Slave-Verzögerung ist, desto offensichtlicher wird dieses Problem. Die Ursache der Master-Slave-Verzögerung

Bei der Ausführung derselben Transaktion liegt ein Zeitunterschiedsproblem zwischen der Master-Bibliothek und der Slave-Bibliothek vor. Die Hauptgründe sind unter anderem die folgenden Situationen:

🎜Unter Einige Bereitstellungsbedingungen: 🎜Die Leistung der Slave-Bibliothek ist schlechter als die Leistung der Hauptdatenbank🎜. 🎜🎜🎜Die Slave-Datenbank steht unter größerem Druck🎜, das heißt, die Slave-Datenbank ist einer großen Anzahl von Anfragen ausgesetzt. 🎜🎜🎜Große Dinge ausführen🎜. Denn die Hauptdatenbank muss warten, bis die Transaktionsausführung abgeschlossen ist, bevor sie in das Binlog geschrieben und dann an die Standby-Datenbank übergeben wird. Wenn die Ausführung einer Anweisung in einer Master-Datenbank 10 Minuten dauert, kann diese Transaktion zu einer Verzögerung von 10 Minuten in der Slave-Datenbank führen. 🎜🎜🎜Parallele Kopierfähigkeit aus der Bibliothek🎜. 🎜

🎜Lösungen für Master-Slave-Verzögerung🎜🎜Um die Master-Slave-Verzögerung zu lösen, gibt es hauptsächlich die folgenden Lösungen: 🎜🎜🎜🎜Zusammenarbeit mit halbsynchroner halbsynchroner Replikation🎜; 🎜🎜🎜Ein Master und mehrere Slaves, um den Druck auf die Slave-Datenbank zu teilen; 🎜🎜Erzwingen Sie die Master-Bibliothekslösung (starke Konsistenz); Master-Slave-Lösung ohne Verzögerung (z. B. ist der Parameter seconds_behind_master code> bereits gleich 0, Vergleichsseite); 🎜🎜🎜Parallele Replikation🎜 – löst das Problem der Kopierverzögerung aus der Bibliothek 🎜🎜 🎜Hier stellen wir hauptsächlich mehrere Lösungen vor, die ich im Projekt verwende, nämlich 🎜Halbsynchrone Replikation, Echtzeitbetrieb erzwingt die Verwendung der Hauptbibliothek und parallele Replikation🎜. 🎜🎜🎜halbsynchrone, halbsynchrone Replikation🎜🎜🎜MySQL verfügt über drei Synchronisationsmodi, nämlich: 🎜<p><strong>„Asynchrone Replikation“</strong>: Die Standardreplikation von MySQL ist asynchron, nachdem die vom Client übermittelte Transaktion sofort ausgeführt wurde, und es ist ihr egal, ob die Slave-Datenbank sie empfangen und verarbeitet hat. Sobald die Hauptdatenbank ausfällt, werden die in der Hauptdatenbank übermittelten Transaktionen aus Netzwerkgründen möglicherweise nicht an die Slave-Datenbank übertragen, wenn zu diesem Zeitpunkt ein Failover durchgeführt wird zum Master kann es dazu kommen, dass die Daten auf dem neuen Master unvollständig sind. </p> <p><strong>„Vollständig synchrone Replikation“</strong>: Dies bedeutet, dass die Hauptbibliothek die Transaktion übermittelt und die Ergebnisse an den Client zurückgibt, wenn die Hauptbibliothek eine Transaktion abgeschlossen hat und alle Slave-Bibliotheken die Transaktion ausgeführt haben. Da Sie vor der Rückkehr warten müssen, bis alle Slave-Bibliotheken die Transaktion abgeschlossen haben, wird die Leistung der vollständig synchronen Replikation zwangsläufig ernsthaft beeinträchtigt. </p> <p><strong>„Halbsynchrone Replikation“</strong>: Es handelt sich um einen Typ zwischen vollständig synchroner Replikation und vollständig asynchroner Replikation. Die Hauptbibliothek muss nur darauf warten, dass mindestens eine Slave-Bibliothek die Relay-Protokolldatei empfängt und in diese schreibt Es muss nicht darauf gewartet werden, dass alle Slave-Bibliotheken ACK an die Master-Bibliothek zurücksenden. Erst nachdem die Hauptbibliothek diese Bestätigung erhalten hat, kann sie eine Bestätigung „Transaktion abgeschlossen“ an den Client zurücksenden. </p> <p><strong>Die Standardreplikation von MySQL ist asynchron, daher kommt es zu einer gewissen Verzögerung bei den Daten zwischen der Master-Datenbank und der Slave-Datenbank. Noch wichtiger ist, dass die asynchrone Replikation zu Datenverlust führen kann. Eine vollständig synchrone Replikation verlängert jedoch die Zeit bis zum Abschluss einer Transaktion und verringert die Leistung. Deshalb habe ich mich der halbsynchronen Replikation zugewandt. </strong>Ab MySQL 5.5 unterstützt MySQL die halbsynchrone Replikation in Form eines Plug-Ins<strong>. </strong></p>Im Vergleich zur asynchronen Replikation verbessert die halbsynchrone Replikation die Datensicherheit und reduziert die Master-Slave-Verzögerung. Natürlich gibt es immer noch eine gewisse Verzögerung. Diese Verzögerung beträgt mindestens eine TCP/IP-Roundtripzeit. Daher wird die <p>halbsynchrone Replikation am besten in Netzwerken mit geringer Latenz eingesetzt<strong>. </strong></p> <blockquote>Es ist zu beachten, dass: <p></p> <ul>Sowohl die Master-Bibliothek als auch die Slave-Bibliothek eine halbsynchrone Replikation ermöglichen müssen, um eine halbsynchrone Replikation durchzuführen. Andernfalls kehrt die Master-Bibliothek zur standardmäßigen asynchronen Replikation zurück. <li>Wenn während des Wartevorgangs die Wartezeit das konfigurierte Timeout überschritten hat und von keiner Slave-Bibliothek eine Bestätigung empfangen wird, wird die Hauptbibliothek zu diesem Zeitpunkt automatisch auf asynchrone Replikation umgestellt. Wenn mindestens ein halbsynchroner Slave-Knoten aufholt, wechselt die Master-Datenbank automatisch zur halbsynchronen Replikation. <li> </ul> </blockquote>Potenzielle Probleme bei der halbsynchronen Replikation<h4></h4>Bei der herkömmlichen halbsynchronen Replikation (eingeführt in MySQL 5.5) schreibt die Masterdatenbank Daten in Binlog und wartet nach der Ausführung von Commit zum Festschreiben der Transaktion immer auf eine Bestätigung aus der Slave-Datenbank, also der Slave-Datenbank. Nachdem die Bibliothek das Relay-Protokoll geschrieben hat, schreibt sie die Daten auf die Festplatte und gibt dann eine Bestätigung an die Hauptbibliothek zurück. Erst nachdem die Hauptbibliothek diese Bestätigung erhalten hat, kann sie eine „Transaktion abgeschlossen“ zurückgeben. Bestätigung an den Kunden. <p></p> <p><img src="https://img.php.cn/upload/article/000/000/067/cbef40562254d59aabda3ee32efe155e-0.jpg" alt="Beherrschen Sie die Lösung für die MySQL-Master-Slave-Verzögerung vollständig"></p>Es tritt ein Problem auf, das heißt, die Hauptbibliothek hat die Transaktion tatsächlich an die Speicher-Engine-Schicht übergeben, und die Anwendung kann bereits erkennen, dass sich die Daten geändert haben, und wartet nur auf die Rückgabe. Wenn <p>die Hauptdatenbank zu diesem Zeitpunkt nicht verfügbar ist<strong>, hat die Slave-Datenbank das Relay-Protokoll möglicherweise nicht geschrieben und es kommt zu einer Dateninkonsistenz zwischen der Master- und der Slave-Datenbank. </strong><strong>Um die oben genannten Probleme zu lösen, führt </strong>MySQL 5.7 eine verbesserte halbsynchrone Replikation ein</p>. Für das obige Bild wird „Warten auf Slave-Dump“ auf „Storage Commit“ eingestellt, d schreibt in das Relay-Protokoll und dann Die Daten werden auf die Festplatte geschrieben, und dann wird ACK an die Hauptbibliothek zurückgegeben, um die Hauptbibliothek darüber zu informieren, dass sie den Festschreibungsvorgang ausführen kann, und dann sendet die Hauptbibliothek die Transaktion an die Transaktions-Engine Erst dann kann die Anwendung die Datenänderungen sehen. <p><strong></strong><strong></strong></p> Natürlich wird auch die bisherige Halbsynchronisationslösung unterstützt. MySQL 5.7.2 führt einen neuen Parameter <p> zur Steuerung ein. Dieser Parameter hat zwei Werte: <img src="https://img.php.cn/upload/article/000/000/067/cbef40562254d59aabda3ee32efe155e-1.png" alt="Beherrschen Sie die Lösung für die MySQL-Master-Slave-Verzögerung vollständig"></p> <blockquote>AFTER_SYNC: Dies ist ein neues Halbsynchronisationsschema, das vor dem Speicher-Commit auf den Slave-Dump wartet. <p><code>rpl_semi_sync_master_wait_pointAFTER_COMMIT: Dies ist die alte halbsynchrone Lösung.

1. In MySQL 5.5 - 5.6 im After_Commit-Modus ist die Hauptbibliothek ausgefallen, nachdem die Client-Transaktion auf der Ebene der Speicher-Engine übermittelt wurde, während die Hauptbibliothek auf die Bestätigung von der Slave-Bibliothek wartet. Obwohl das Ergebnis zu diesem Zeitpunkt nicht an den aktuellen Client zurückgegeben wird, wurde die Transaktion übermittelt, und andere Clients lesen die übermittelte Transaktion. Wenn die Slave-Datenbank die Transaktion nicht empfängt oder nicht in das Relay-Protokoll schreibt und die Master-Datenbank ausgefallen ist und dann zur Standby-Datenbank wechselt, verschwinden die zuvor gelesenen Transaktionen und es treten Phantom-Lesevorgänge auf, d. h. die Daten wird verloren gehen.

2. Der Standardwert von MySQL 5.7 ist after_sync. Die Master-Datenbank schreibt jede Transaktion in das Binlog, übergibt sie an die Slave-Datenbank und schreibt sie auf die Festplatte (Relay-Log). Die Hauptbibliothek wartet, bis die Slave-Bibliothek eine Bestätigung zurückgibt, schreibt dann die Transaktion fest und gibt das Commit-OK-Ergebnis an den Client zurück. Selbst wenn die Hauptbibliothek abstürzt, kann garantiert werden, dass alle in der Hauptbibliothek übermittelten Transaktionen mit dem Relay-Protokoll der Slave-Bibliothek synchronisiert werden, wodurch das Problem des Phantomlesens und des Datenverlusts gelöst wird, der durch den After_Commit-Modus verursacht wird Die Konsistenz wird während des Failovers verbessert. Verbessern . Denn wenn die Slave-Datenbank nicht erfolgreich schreibt, wird die Master-Datenbank die Transaktion nicht festschreiben. Darüber hinaus kann das Warten auf ACK von der Slave-Bibliothek vor dem Festschreiben auch Transaktionen ansammeln, was sich positiv auf die Übermittlung von Gruppenfestschreibungsgruppen auswirkt und die Leistung verbessert.

   Angenommen, die Hauptbibliothek hängt, bevor die Speicher-Engine festgeschrieben wird, ist die Transaktion jedoch offensichtlich fehlgeschlagen, da das entsprechende Binlog bereits einen Synchronisierungsvorgang durchgeführt hat Wenn die Bibliothek diese Binlogs empfangen hat und die Ausführung erfolgreich ist, ist dies gleichbedeutend mit zusätzlichen Daten in der Slave-Datenbank (die Slave-Datenbank verfügt über diese Daten, die Hauptdatenbank jedoch nicht), was ebenfalls ein Problem darstellt, die zusätzlichen Daten jedoch im Allgemeinen kein ernstes Problem. Es kann garantiert werden, dass keine Daten verloren gehen. Es ist besser, mehr Daten zu haben, als Daten zu verlieren.

   Ein Master, mehrere Slaves
   Wenn die Slave-Datenbank eine große Anzahl von Abfrageanforderungen durchführt, verbrauchen die Abfragevorgänge in der Slave-Datenbank viele CPU-Ressourcen, was sich auf die Synchronisierungsgeschwindigkeit auswirkt und eine Master-Slave-Verzögerung verursacht. Dann können wir mehrere weitere Slave-Bibliotheken verbinden und diese Slave-Bibliotheken den Lesedruck teilen lassen.
   Kurz gesagt, es geht darum, Maschinen hinzuzufügen. Die Methode ist einfach und grob, bringt aber auch gewisse Kosten mit sich.

   Erzwingen Sie die Hauptdatenbanklösung

   Wenn einige Vorgänge strenge Anforderungen an Echtzeitdaten stellen und die neuesten Echtzeitdaten widerspiegeln müssen, z. B. Finanzsysteme mit Geld, Online-Echtzeitsysteme oder nach dem Schreiben von If Das Geschäft soll sofort wieder gelesen werden, dann müssen wir die Trennung von Lesen und Schreiben aufgeben und solche Leseanfragen auch in die Hauptbibliothek gehen lassen, damit es kein Verzögerungsproblem gibt.
   Dadurch geht natürlich auch die Leistungssteigerung verloren, die uns die Trennung von Lesen und Schreiben bringt, sodass entsprechende Kompromisse erforderlich sind.

   Parallele Replikation

   Im Allgemeinen umfasst die MySQL-Master-Slave-Replikation drei Threads, die alle einzelne Threads sind: Binlog Dump-Thread, IO-Thread und SQL-Thread. Replikationsverzögerungen treten im Allgemeinen an zwei Stellen auf:
   SQL-Threads sind zu beschäftigt (der Hauptgrund);
   • Netzwerk-Jitter verursachen Verzögerungen bei der E/A-Thread-Replikation (sekundäre Gründe).
   Die Ausführung von Protokollen in der Standby-Datenbank ist die Logik des SQL-Threads in der Standby-Datenbank, der das Relay-Protokoll (Relay-Protokoll) ausführt, um Daten zu aktualisieren.
   Vor MySQL-Version 5.6 unterstützte MySQL nur die Single-Thread-Replikation. Daher traten schwerwiegende Master-Slave-Verzögerungsprobleme auf, wenn die Parallelität der Hauptdatenbank und TPS hoch waren.

   Ab MySQL 5.6 gibt es das Konzept mehrerer SQL-Threads, die Daten gleichzeitig wiederherstellen können, also die parallele Replikationstechnologie. Dies kann das MySQL-Master-Slave-Verzögerungsproblem sehr gut lösen.

   Von der Single-Thread-Replikation bis zur neuesten Version der Multi-Thread-Replikation hat die Entwicklung mehrere Versionen durchlaufen. Tatsächlich bestehen alle Multithread-Replikationsmechanismen letzten Endes darin, den sql_thread mit nur einem Thread in mehrere Threads aufzuteilen, was bedeutet, dass sie alle dem folgenden Multithreading-Modell entsprechen:

   coordinator ist der ursprüngliche sql_thread, aber Jetzt aktualisiert es die Daten nicht mehr direkt, sondern ist nur noch für das Lesen des Transitprotokolls und die Verteilung von Transaktionen verantwortlich. Was das Protokoll tatsächlich aktualisiert, wird zum Arbeitsthread. Die Anzahl der Worker-Threads wird durch den Parameter bestimmt. slave_parallel_workers

   Da Arbeitsthreads gleichzeitig ausgeführt werden, muss der Koordinator bei der Verteilung die folgenden zwei Grundanforderungen erfüllen, um die Transaktionsisolation sicherzustellen und Probleme mit der Aktualisierungsabdeckung zu vermeiden:
   1. Zwei Transaktionen in derselben Zeile aktualisieren, müssen an die verteilt werden derselbe Arbeiter (um Update-Abdeckung zu vermeiden) .
   2. Die gleiche Transaktion kann nicht aufgeteilt werden und muss im selben Worker platziert werden (um die Transaktionsisolation sicherzustellen).
   Alle Versionen der Multithread-Replikation folgen diesen beiden Grundprinzipien.
   Im Folgenden finden Sie eine tabellenweise Verteilungsstrategie und eine zeilenweise Verteilungsstrategie, die zum Verständnis der Iteration der offiziellen MySQL-Version der parallelen Replikationsstrategie beitragen können:
   • Verteilung nach Tabellenstrategie: Zwei Transaktionen können parallel laufen, wenn sie unterschiedliche Tabellen aktualisieren. Da die Daten in der Tabelle gespeichert werden, stellt die Verteilung nach Tabelle sicher, dass nicht zwei Worker dieselbe Zeile aktualisieren.
     • Das tabellenbasierte Verteilungsschema funktioniert gut in Szenarien, in denen mehrere Tabellen gleichmäßige Lasten haben, aber der Nachteil ist: Wenn eine Hotspot-Tabelle angetroffen wird, zum Beispiel wenn alle Aktualisierungstransaktionen eine bestimmte Tabelle betreffen, werden alle Transaktionen zugewiesen Wenn derselbe Worker verwendet wird, handelt es sich um eine Single-Threaded-Replikation.
   • Zeilenweise Verteilungsstrategie: Wenn zwei Transaktionen nicht dieselben Zeilen aktualisieren, können sie in der Standby-Datenbank parallelisiert werden. Offensichtlich erfordert dieser Modus, dass das Binlog-Format zeilenweise sein muss.
     • Die zeilenweise parallele Replikationslösung löst das Problem von Hotspot-Tabellen und weist einen höheren Grad an Parallelität auf. Der Nachteil ist jedoch: Im Vergleich zur tabellenweisen Parallelverteilungsstrategie ist die zeilenweise Parallelität Die Strategie erfordert mehr Berechnungen bei der Bestimmung der Thread-Ressource.

   Parallele Replikationsstrategie der MySQL 5.6-Version

   MySQL 5.6-Version unterstützt die parallele Replikation, aber die unterstützte Granularität ist Basisparallelität (basierend auf dem Schema).

   Die Kernidee ist : Wenn Tabellen unter verschiedenen Schemata gleichzeitig übermittelt werden, wirken sich die Daten nicht gegenseitig aus, d. h. die Slave-Bibliothek kann einen Thread ähnlich der SQL-Thread-Funktion verschiedenen Schemata im Relay-Protokoll zuweisen Wiederholen Sie das Relay-Protokoll. Transaktionen, die von der Hauptdatenbank festgeschrieben wurden, werden mit den Daten in der Hauptdatenbank konsistent gehalten.

   Wenn in der Hauptdatenbank mehrere DBs vorhanden sind, kann die Verwendung dieser Strategie die Geschwindigkeit der Replikation aus der Slave-Datenbank erheblich verbessern. Normalerweise gibt es jedoch mehrere Tabellen in einer einzelnen Datenbank, sodass die datenbankbasierte Parallelität keine Auswirkungen hat und eine parallele Wiedergabe überhaupt nicht möglich ist, sodass diese Strategie nicht häufig verwendet wird.

   Parallele Replikationsstrategie von MySQL 5.7

   MySQL 5.7 führt eine auf Gruppenübermittlung basierende parallele Replikation ein, und der Parameter slave_parallel_workers 设置并行线程数，由参数 slave-parallel-type steuert die parallele Replikationsstrategie:

   • ist als DATABASE konfiguriert, was bedeutet, dass Datenbank für Datenbank parallel verwendet wird Strategie der MySQL 5.6-Version;
   • Konfiguriert als LOGICAL_CLOCK, was die Verwendung einer parallelen Replikationsstrategie basierend auf der Gruppenübermittlung anzeigt.

   Mit dem Gruppen-Commit-Mechanismus von Binlog kann geschlossen werden, dass von einer Gruppe übermittelte Transaktionen ausgeführt werden können parallel, weil: parallel ausgeführt werden kann. In derselben Gruppe übermittelte Transaktionen ändern definitiv nicht dieselbe Zeile (aufgrund des Sperrmechanismus von MySQL), da die Transaktion den Sperrkonflikttest bestanden hat .

   Der spezifische Prozess der parallelen Replikation basierend auf der Gruppenübermittlung ist wie folgt:

   Transaktionen, die gemeinsam in einer Gruppe übermittelt werden, haben dieselbe Commit_ID, und die Commit_ID der nächsten Gruppe wird direkt in das Binlog geschrieben
   Übertragung Beim Erreichen der Standby-Datenbankanwendung werden Transaktionen mit derselben commit_id zur Ausführung an mehrere Worker verteilt.
   2. Nachdem alle Ausführungen dieser Gruppe abgeschlossen sind, löscht der Koordinator einen Stapel von Ausführungen.

   Alle Transaktionen im Vorbereitungs- und Commit-Status können parallel auf der Standby-Datenbank ausgeführt werden.

   Zwei relevante Parameter, die von der Binlog-Gruppe übermittelt werden:
   binlog_group_commit_sync_delay-Parameter, der die Anzahl der Mikrosekunden angibt, die vor dem Aufruf von fsync Flush verzögert werden sollen;
   • binlog_group_commit_sync_no_delay_count-Parameter, der angibt, wie oft er vor dem Aufruf von fsync akkumuliert wird.
   Diese beiden Parameter werden verwendet, um die Zeit vom Binlog-Schreiben bis zum Fsync bewusst zu verlängern und dadurch die Anzahl der Binlog-Schreibvorgänge auf die Festplatte zu reduzieren. In der parallelen Replikationsstrategie von MySQL 5.7 können sie verwendet werden, um mehr „Transaktionen in der Vorbereitungsphase gleichzeitig“ zu erstellen. Sie können erwägen, die Werte dieser beiden Parameter anzupassen, um den Zweck der Verbesserung der Parallelität der Standby-Datenbankreplikation zu erreichen.
   Empfohlenes Lernen:

   MySQL-Video-Tutorial

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