So entwerfen Sie die Architektur des MySQL-Binlog-Speichersystems

1. Einführung in Kingbus

1.1 Was ist Kingbus?

Kingbus ist ein verteiltes MySQL-Binlog-Speichersystem, das auf dem Raft-Protokoll mit starker Konsistenz basiert. Es kann als MySQL-Slave fungieren, um Binlog vom echten Master zu synchronisieren und in einem verteilten Cluster zu speichern. Gleichzeitig fungiert es auch als MySQL-Master, um das Binlog im Cluster mit anderen Slaves zu synchronisieren. Kingbus hat die folgenden Funktionen:

Kompatibel mit dem MySQL-Replikationsprotokoll, synchronisiert das Binlog auf dem Master über Gtid und unterstützt den Slave beim Abrufen des Binlogs vom Kingbus über Gtid.

Überregionale Datenreplikation: Kingbus unterstützt die überregionale Datenreplikation über das Raft-Protokoll. Es wird garantiert, dass die in den Cluster geschriebenen Binlog-Daten über mehrere Knoten hinweg stark konsistent sind und die Binlog-Reihenfolge vollständig mit der auf dem Master übereinstimmt.

Hohe Verfügbarkeit: Da Kingbus auf dem starken Konsensprotokoll Raft basiert, kann eine hohe Verfügbarkeit des gesamten Binlog-Pull- und Push-Dienstes erreicht werden, wenn mehr als die Hälfte der Knoten im Cluster überleben.

1.2 Welche Probleme kann Kingbus lösen?

Kingbus kann den Netzwerkübertragungsverkehr des Masters reduzieren. In einer Replikationstopologie mit einem Master und mehreren Slaves muss der Master Binlog an jeden Slave senden. Wenn zu viele Slaves vorhanden sind, erreicht der Netzwerkverkehr wahrscheinlich die Obergrenze der Netzwerkkarte des Masters. Wenn der Master beispielsweise Vorgänge wie das Löschen einer großen Tabelle oder Online-DDL ausführt, kann sofort eine große Anzahl von Binlog-Ereignissen generiert werden. Wenn 10 Slaves mit dem Master verbunden sind, wird der Netzwerkkartenverkehr auf dem Master um das Zehnfache verstärkt . Wenn der Master eine Gigabit-Netzwerkkarte verwendet, kann die Netzwerkkarte voll sein, wenn mehr als 10 MB/S Datenverkehr generiert werden. Durch die Verbindung mit dem Master über Kingbus können Slaves auf mehrere Maschinen verteilt werden, um den Übertragungsverkehr auszugleichen.

Um den Master-Failover-Prozess zu vereinfachen, müssen Sie lediglich einen mit dem Kingbus verbundenen Slave zum Master hochstufen und den Kingbus zum neuen Master umleiten. Andere Slaves sind weiterhin mit dem Kingbus verbunden und die Replikationstopologie bleibt unverändert.

Sparen Sie den vom Master zum Speichern von Binlog-Dateien verwendeten Speicherplatz. Im Allgemeinen verwendet MySQL teurere SSDs. Wenn die Binlog-Datei viel Platz beansprucht, müssen die in MySQL gespeicherten Daten reduziert werden. Sie können die Anzahl der auf dem Master gespeicherten Binlog-Dateien reduzieren, indem Sie alle Binlogs in Kingbus speichern

Unterstützen Sie die heterogene Replikation. Stellen Sie eine Verbindung zu Kingbus über den Open-Source-Kanal von Alibaba her. Kingbus überträgt das Binlog kontinuierlich an den Kanal, schiebt es dann in die Kafka-Nachrichtenwarteschlange und speichert es schließlich in Hive Analyse des Geschäfts.

2. Kingbus-Gesamtstruktur

Die Gesamtstruktur von Kingbus ist in der folgenden Abbildung dargestellt:

Der Speicher ist für die Speicherung von Raft-Protokolleinträgen und Metadaten verantwortlich. Sie unterscheiden sich durch unterschiedliche Header-Informationen. Der Datenteil des Raft-Protokolls ist daher nicht erforderlich von Protokollen separat, sparen Sie Speicherplatz. Da Kingbus einige Metainformationen speichern muss, z. B. Abstimmungsinformationen für Raft-Knoten und den spezifischen Inhalt einiger spezieller Binlog-Ereignisse (FORMAT_DESCRIPTION_EVENT).

Raft repliziert die Lead-Wahl, Protokollreplikation und andere Funktionen des Kingbus-Clusters mithilfe der etcd-Raft-Bibliothek.

Der Binlog-Syncer läuft nur auf dem Lead-Knoten des Raft-Clusters. Im gesamten Cluster gibt es nur einen Syncer. Der Syncer gibt vor, ein Slave zu sein und stellt eine Master-Slave-Replikationsverbindung zum Master her. Der Master filtert die Binlog-Ereignisse, die der Syncer akzeptiert hat, basierend auf dem vom Syncer gesendeten „executed_gtid_set“ und sendet nur Binlog-Ereignisse, die der Syncer nicht akzeptiert hat Dieses Replikationsprotokoll ist vollständig kompatibel mit dem MySQL-Master-Slave-Replikationsmechanismus. Nachdem der Syncer das Binlog-Ereignis empfangen hat, führt er eine Verarbeitung entsprechend dem Binlog-Ereignistyp durch, kapselt dann das Binlog-Ereignis in eine Nachricht und sendet sie an den Raft-Cluster. Durch den Raft-Algorithmus kann dieses Binlog-Ereignis auf mehreren Knoten gespeichert werden und eine starke Konsistenz erreichen.

Der Binlog-Server ist ein Master, der das Replikationsprotokoll implementiert. Der Binlog-Server kann eine Verbindung zu dem vom Binlog-Server überwachten Port herstellen MySQL-Replikationsprotokoll. Wenn kein Binlog-Ereignis an den Slave gesendet wird, sendet der Binlog-Server regelmäßig Heartbeat-Ereignisse an den Slave, um die Replikationsverbindung aufrechtzuerhalten.

Der API-Server ist für die Verwaltung des gesamten Kingbus-Clusters verantwortlich, einschließlich der folgenden:

Rafting-Cluster-Mitgliedschaftsvorgang, Cluster-Status anzeigen, Knoten hinzufügen, Knoten entfernen, Knoteninformationen aktualisieren usw.

Binlog-Syncer-bezogene Vorgänge: Starten Sie einen Binlog-Syncer, stoppen Sie den Binlog-Syncer und überprüfen Sie den Binlog-Syncer-Status.

Vorgänge im Zusammenhang mit dem Binlog-Server: Starten eines Binlog-Servers, Stoppen des Binlog-Servers und Überprüfen des Binlog-Serverstatus. Verschiedene Anomalien in der Serverschicht wirken sich nicht auf die Raft-Schicht aus. Der Server kann als Plug-In verstanden werden, das bei Bedarf gestartet und gestoppt werden kann. Wenn Sie Kingbus in Zukunft erweitern, müssen Sie lediglich den Server mit der entsprechenden Logik implementieren. Wenn Sie beispielsweise einen Kafka-Protokollserver implementieren, können Sie die Nachrichten in Kingbus über den Kafka-Client nutzen.

​3.Kingbus-Kernimplementierung

3.1 Kernimplementierung des Speichers

Es gibt zwei Protokollformen im Speicher: Eines ist das Raft-Protokoll (im Folgenden als Raft-Protokoll bezeichnet), das vom Raft-Algorithmus generiert und verwendet wird, und das andere ist ein Benutzerformularprotokoll (dh ein MySQL-Binlog-Ereignis). . Bei der Gestaltung des Speichers werden zwei Protokollformen zu einem Protokolleintrag kombiniert. Es unterscheidet sich nur durch unterschiedliche Header-Informationen. Der Speicher besteht aus Datendateien und Indexdateien, wie in der folgenden Abbildung dargestellt:

Das Segment hat eine feste Größe (1 GB) und kann nur zusätzlich geschrieben werden. Der Name lautet first_raft_index-last_raft_index und gibt den Raft-Indexbereich des Segments an.

Nur das letzte Segment kann geschrieben werden und sein Dateiname lautet first_raft_index-inprogress. Andere Segmente sind schreibgeschützt.

Schreibgeschützte Segmente und entsprechende Indexdateien werden über mmap geschrieben und gelesen.

Der Indexinhalt des letzten Segments wird sowohl auf der Festplatte als auch im Speicher gespeichert. Das Lesen des Index erfordert nur das Lesen aus dem Speicher.

3.2 Nutzung der etcd-Raft-Bibliothek

Die Etcd-Raft-Bibliothek ist Single-Threaded, wenn angewendete Protokolle, festgeschriebene Einträge usw. verarbeitet werden. Informationen zu bestimmten Funktionen finden Sie unter dem Link. Die Verarbeitungszeit dieser Funktion muss so kurz wie möglich sein. Wenn die Verarbeitungszeit die Raft-Wahlzeit überschreitet, wird der Cluster neu gewählt. Dieser Punkt erfordert besondere Aufmerksamkeit.

3.3 Kernimplementierung des Binlog-Syncers

Die Hauptaufgabe des Binlog-Syncers ist:

Pull-Binlog-Ereignis

Binlog-Ereignis analysieren und verarbeiten

Senden Sie Binlog-Ereignisse an den Raft-Cluster. Offensichtlich kann der Pipeline-Mechanismus verwendet werden, um die Verarbeitungsgeschwindigkeit des gesamten Prozesses zu verbessern. Kingbus verwendet für die Verarbeitung jeder Phase eine separate Goroutine und verbindet verschiedene Phasen über Pipelines. Da der Binlog-Syncer die Binlog-Ereignisse einzeln empfängt, kann der Master nach dem Aufhängen des Syncers erneut verbunden werden. Zu diesem Zeitpunkt muss der Binlog-Syncer möglicherweise unvollständig sein Mit seinen einzigartigen Fähigkeiten implementiert Kingbus die Funktion der Transaktionsintegritätsanalyse, die vollständig unter Bezugnahme auf den MySQL-Quellcode implementiert ist.

3.4 Kernimplementierung des Binlog-Servers

Der Binlog-Server implementiert die Funktion eines Masters. Wenn der Slave eine Replikationsverbindung mit dem Binlog-Server herstellt, sendet der Slave relevante Befehle, und der Binlog-Server muss auf diese Befehle antworten. Senden Sie abschließend das Binlog-Ereignis an den Slave. Für jeden Slave startet der Binlog-Server eine Goroutine, um das Raft-Protokoll kontinuierlich zu lesen, die relevanten Header-Informationen zu entfernen und es in ein Binlog-Ereignis umzuwandeln, das dann an den Slave gesendet wird.

Das obige ist der detaillierte Inhalt vonSo entwerfen Sie die Architektur des MySQL-Binlog-Speichersystems. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!