Was sind MySQL-Binlog-Protokolle und Master-Slave-Replikation?

1. Einführung in das Binlog-Protokoll

Binlog ist die Abkürzung für Binary Log, also Binärprotokoll. Zu den drei Hauptfunktionen von Binlog gehören die Konvertierung zufälliger E/A in sequentielle E/A für Persistenz, die Realisierung der Master-Slave-Replikation und die Unterstützung der Datenwiederherstellung. Dieser Artikel konzentriert sich auf Probleme im Zusammenhang mit der Master-Slave-Replikation.

Das Binlog-Protokoll besteht aus einer Indexdatei und vielen Protokolldateien. Jede Protokolldatei besteht aus einer magischen Zahl und einem Ereignis. Jede Protokolldatei endet mit einem Ereignis vom Typ Rotate.

Für jedes Ereignis kann es in zwei Teile unterteilt werden: Ereigniskopf und Ereigniskörper:

Die Struktur des Ereigniskopfes ist wie folgt:

Die Struktur des Ereigniskörpers Enthält feste Größe und abnehmbare Größe. Ändern Sie die Größe in zwei Teile.

Was das Format von Binlog-Protokollen betrifft, müssen Sie nur über ein einfaches Verständnis verfügen. Interessierte Schüler können es gründlich lernen. 2. Master-Slave-Replikation zur Slave-Bibliothek

Slave Der IO-Thread der Bibliothek schreibt den Inhalt des Binlog-Protokolls in das Relay-Log

Der SQL-Thread der Bibliothek nimmt das Relay-Log und spielt es in der Datenbank ab

2.2 GTID

• GTID bezieht sich auf das globale Transaktionsflag, das zur Kennzeichnung der Master-Slave-Synchronisationssituation verwendet wird.
  Wenn der Masterknoten eine Transaktion festschreibt, wird die GTID generiert und im Binlog-Protokoll aufgezeichnet. Wenn der E/A-Thread der Slave-Bibliothek das Binlog-Protokoll liest, speichert er es in seinem eigenen Relaylog und setzt diesen Wert auf gtid_next, die nächste zu lesende GTID. Beim Lesen dieses gtid_next aus der Bibliothek wird dort verglichen Ist diese GTID in Ihrem Binlog-Protokoll:

• Wenn dieser Eintrag vorhanden ist, bedeutet dies, dass die Transaktion mit dieser GTID ausgeführt wurde und ignoriert werden kann (idempotent).

• Wenn kein solcher Datensatz vorhanden ist, führt der Slave die GTID-Transaktion aus und zeichnet sie in seinem eigenen Binlog-Protokoll auf.

2.3 Replikationsmodell

Asynchrone Replikation:
• Der Master muss nicht warten, bis der Slave die Daten erfolgreich an das Relay-Protokoll übermittelt die Transaktion. Dieser Modus beeinträchtigt die Datenkonsistenz.

• Synchronische Replikation:

  Jedes Mal, wenn der Benutzer eine Operation durchführt, muss sichergestellt werden, dass sowohl der Master als auch der Slave erfolgreich ausgeführt wurden, bevor sie an den Benutzer zurückgegeben werden.

Halbsynchrone Replikation:
• Es ist nicht erforderlich, dass der Slave erfolgreich ausgeführt wird, aber er kann den Master benachrichtigen, nach erfolgreichem Empfang des Master-Protokolls zurückzukehren.

• 2.4 MGR-ModusVerteilter Konsensalgorithmus Paxos. Ein Datenbankcluster besteht aus mindestens 3 oder mehr Knoten. Die Übermittlung von Transaktionen muss von mehr als der Hälfte der Knoten genehmigt werden, bevor der Multi-Write-Modus unterstützt wird.

MGR ist eine Share-Nothing-Replikationslösung, die auf dem verteilten Paxos-Protokoll basiert. Jede Instanz verfügt über eine unabhängige vollständige Kopie der Daten. Der Cluster überprüft automatisch die Knoteninformationen und synchronisiert die Daten. Es stehen sowohl der Single-Master-Modus als auch der Multi-Master-Modus zur Verfügung. Der Single-Master-Modus kann den Master automatisch auswählen, nachdem die Hauptdatenbank ausgefallen ist. Der Multi-Master-Modus unterstützt das Schreiben mit mehreren Knoten. Der Cluster bietet Fehlertoleranz, solange die meisten Knoten normal laufen.

• 2.5 Parallele WiedergabeDie Transaktionswiedergabe ist der Prozess der Ausführung des Relay-Protokolls aus dem SQL-Thread der Bibliothek, um die Effizienz dieses Prozesses zu verbessern und Transaktionen auszuführen, die gleichzeitig ausgeführt werden können.

Parallele Wiedergabe basierend auf logischer Uhr

Da MySQL selbst über ACID-Eigenschaften verfügt, werden die Transaktionen von der Master-Datenbank zur Slave-Datenbank synchronisiert, solange sich die logische Zeit ihrer Ausführung überschneidet, dann werden die beiden Transaktionen synchronisiert synchronisiert. Kann sicher parallele Wiedergabe durchführen.

Parallele Wiedergabe basierend auf writeSet

speichert den Transaktionssatz über einen bestimmten Datenblockbereich innerhalb eines bestimmten Zeitraums in einer HashMap. Konflikte treten nicht zwischen Transaktionen innerhalb derselben Gruppe oder zwischen Transaktionen mit überlappenden logischen Uhren auf, und andernfalls ist es unmöglich festzustellen, ob ein Konflikt vorliegt.

Das obige ist der detaillierte Inhalt vonWas sind MySQL-Binlog-Protokolle und Master-Slave-Replikation?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!