Detaillierte Erläuterung des Binlog-Protokollanalysetools zur Überwachung von MySQL: Canal

Canal ist ein Open-Source-Projekt von Alibaba, das mit Java entwickelt wurde. Der Hauptzweck besteht darin, inkrementelle Datenabonnements und -nutzungen basierend auf der inkrementellen Protokollanalyse der MySQL-Datenbank bereitzustellen. Derzeit wird hauptsächlich MySQL unterstützt.

GitHub-Adresse: https://github.com/alibaba/canal

Bevor wir die internen Prinzipien von Canal vorstellen, wollen wir zunächst das Prinzip der MySQL-Master/Slave-Synchronisierung verstehen:

Der MySQL-Master startet den Binärprotokollmechanismus und schreibt Datenänderungen in das Binärprotokoll (das als Binärprotokollereignisse bezeichnet wird und mit „show binlog events“ angezeigt werden kann). Der MySQL-Slave (E/A-Thread) kopiert die Binärprotokollereignisse des Masters in sein Relayprotokoll. Der MySQL-Slave (SQL-Thread) spielt die Ereignisse im Relayprotokoll erneut ab, um die Datenänderungen in seinen eigenen Daten widerzuspiegeln.

So funktioniert Canal:

Canal simuliert das Interaktionsprotokoll des MySQL-Slaves, gibt sich als MySQL-Slave aus und sendet das Dump-Protokoll an den MySQL-Master. Der MySQL-Master empfängt die Dump-Anforderung und beginnt, das Binärprotokoll an den Slave (also Canal) zu senden. Canal analysiert das Binärprotokollobjekt (ursprünglich ein Bytestream).

Kurz gesagt: Canal erhält Daten, indem er vorgibt, ein MySQL-Slave zu werden und die MySQL-Binlog-Protokolle abhört. Nachdem Sie MySQL-Binlog auf Zeilenmodus eingestellt haben, können Sie jedes ausgeführte Insert/Update/Delete-Skript sowie die Daten vor und nach der Änderung abrufen. Basierend auf dieser Funktion kann Canal Änderungen in MySQL-Daten effizient abrufen. Kanalarchitektur:

Hinweis: Der Server stellt eine laufende Canal-Instanz dar, die einer JVM-Instanz und einer Datenwarteschlange entspricht (1 Server entspricht 1..n Instanzen).

EventParser: Datenquellenzugriff, Slave-Protokoll simulieren und mit Master interagieren, Protokollanalyse

EventSink: Parser und Store-Connector, hauptsächlich für die Datenfilterung, -verarbeitung und -verteilung

EventStore: verantwortlich für die Speicherung

MemoryMetaManager: Inkrementeller Abonnement- und Verbrauchsinformationsmanager

Entwurf des Ereignisparsers:

Der gesamte Parserprozess kann grob in die folgenden Schritte unterteilt werden:

Connection erhält die Protokollposition der letzten erfolgreichen Analyse (beim ersten Start erhält es die anfänglich angegebene Position oder die Binärprotokollposition der aktuellen Datenbank). Connection stellt eine Verbindung her und sendet eine BINLOG_DUMP-Anforderung an den MySQL-Master. MySQL beginnt mit dem Pushen von Binärprotokollen. Die empfangenen Binärprotokolle werden durch BinlogParser analysiert und einige spezifische Informationen werden hinzugefügt. Fügen Sie beispielsweise Feldnamen, Feldtypen, Primärschlüsselinformationen, Verarbeitung von vorzeichenlosen Typen usw. hinzu. Übergeben Sie die analysierten Daten zur Datenspeicherung an die EventSink-Komponente (dies ist ein Sperrvorgang, bis die Speicherung erfolgreich ist) und zeichnen Sie die Position des binären Protokolls regelmäßig auf, damit das inkrementelle Abonnement nach dem Neustart fortgesetzt werden kann.

Wenn der Masterknoten, der synchronisiert werden muss, abstürzt, können Sie mit der Synchronisierung der Binlog-Protokolle von seinen anderen Slaveknoten fortfahren, um einen Einzelpunktausfall zu vermeiden. Entwurf des Event-Sinks:

Die Hauptfunktionen von EventSink sind wie folgt:

Datenfilterung: Unterstützt Platzhalterfiltermodus, Tabellennamen, Feldinhalte usw.

Datenrouting/-verteilung: Lösen Sie das 1:n-Problem (ein Parser entspricht mehreren Speichern)

Datenzusammenführung: Lösung von n:1 (mehrere Parser entsprechen einem Geschäft)

Datenverarbeitung: zusätzliche Verarbeitung vor dem Betreten des Geschäfts, wie z. B. Zusammenführung von Daten 1:n Geschäft

Um Datenbankressourcen rational zu nutzen, werden allgemeine Unternehmen im Allgemeinen nach dem Schema isoliert und dann eine Datenquellenweiterleitung auf der oberen MySQL- oder DAO-Ebene durchgeführt, um die Auswirkungen des physischen Standorts der Datenbank auf die Entwicklung abzuschirmen. Alibaba verwendet hauptsächlich Cobar/TDDL, um das Problem der Datenquellenweiterleitung zu lösen. Daher werden im Allgemeinen mehrere Schemas auf einer Datenbankinstanz bereitgestellt und jedes Schema wird von einem oder mehreren Geschäftspartnern überwacht.

Daten n:1-Dienst

Wenn der Datenumfang eines Unternehmens ein bestimmtes Niveau erreicht, wird dies zwangsläufig zu Problemen der horizontalen und vertikalen Aufteilung führen. Wenn diese aufgeteilten Daten verarbeitet werden müssen, müssen mehrere Speicher für die Verarbeitung verknüpft werden. Es gibt mehrere Verbrauchsstandorte, und es kann nicht garantiert werden, dass der Datenverbrauch so geordnet wie möglich verläuft. Daher müssen die aufgeteilten inkrementellen Daten in bestimmten Geschäftsszenarien zusammengeführt werden, z. B. durch Sortieren und Zusammenführen nach Zeitstempel/globaler ID. Gestaltung des Event-Stores:

Unterstützt mehrere Speichermodi, wie etwa den Speichermodus. Zum Speichern von Nachrichten wird ein Memory-Ring-Design verwendet, welches auf der Implementierungsidee des RingBuffer von Disruptor basiert. RingBuffer-Design:

Es sind drei Cursor definiert:

put: Die letzte Schreibposition des Sink-Moduls zur Datenspeicherung (der Cursor, der Daten synchron schreibt)

get: die letzte Extraktionsposition, die durch das Datenabonnement erhalten wurde (der Cursor der synchron erhaltenen Daten)

ack: Der letzte Verbrauchsort des erfolgreichen Datenverbrauchs

Lassen Sie uns den RingBuffer begradigen, indem wir uns an der Implementierung des RingBuffer von Disruptor orientieren:

Hinweise zur Implementierung:

Der Put/Get/Ack-Cursor wird zum Inkrementieren verwendet und im Long-Typ gespeichert. Die Beziehung zwischen den dreien ist die Get-Operation put>=get>=ackbuffer, und zwar über die Modulo- oder &-Operation. (&-Operation: Cursor & (Größe - 1), Größe muss ein Exponent von 2 sein, was effizienter ist)

Instanzdesign:

Die Instanz stellt eine tatsächlich laufende Datenwarteschlange dar, einschließlich EventPaser, EventSink, EventStore und anderen Komponenten. Der CanalInstanceGenerator wird abstrahiert, wobei hauptsächlich die Methode des Konfigurationsmanagements berücksichtigt wird:

Manager-Methode: Stellen Sie eine Verbindung zu Ihrem eigenen internen Webkonsolen-/Managersystem her. (Derzeit hauptsächlich unternehmensintern genutzt)

Spring-Methode: Basierend auf Spring-XML + Eigenschaften definieren und Spring-Konfiguration erstellen. Serverdesign:

Der Server stellt eine laufende Instanz von Canal dar. Um eine komponentenbasierte Nutzung zu ermöglichen, werden zwei Implementierungen von Embeded (eingebettet) und Netty (Netzwerkzugriff) abstrahiert.

Inkrementelles Abonnement-/Verbrauchsdesign:

Das spezifische Protokollformat finden Sie unter: CanalProtocol.proto. Datenobjektformat: EntryProtocol.proto

Eintrag
  Kopfbereich
    logfileName [Name der Binärprotokolldatei]
    logfileOffset [Binlog-Position]
    executeTime [Zeitstempel der im Binärprotokoll aufgezeichneten Änderung]
    schemaName [Datenbankinstanz]
    tableName [Tabellenname]
    eventType [Typ einfügen/aktualisieren/löschen]
  entryType [Transaktionskopfzeile BEGIN/Transaktionsende END/Daten ROWDATA]
  storeValue [Byte-Daten, erweiterbar, entsprechender Typ ist RowChange]

Zeilenänderung
isDdl [Ob es sich um einen DDL-Änderungsvorgang handelt, z. B. Tabelle erstellen/Tabelle löschen]
sql [spezifisches DDL-SQL]
rowDatas [spezifisches Einfügen/Aktualisieren/Löschen von Änderungsdaten, kann mehrere haben, 1 Binlog-Ereignis kann mehreren Änderungen entsprechen, z. B. Stapelverarbeitung]
beforeColumns [Array vom Typ „Spalte“]
afterColumns [Array vom Typ „Spalte“]

Spalte
index [Spaltennummer]
sqlType [JDBC-Typ]
Name [Spaltenname]
isKey [Ist es der Primärschlüssel]
aktualisiert [Gab es Änderungen?]
isNull [Ist der Wert null]
Wert [spezifischer Inhalt, beachten Sie, dass es sich um Text handelt]

Ergänzende Erklärung zum obigen:

1. Es kann den Feldinhalt vor und nach der Datenbankänderung bereitstellen und den Namen, den isKey und andere Informationen vervollständigen, die nicht im Binlog enthalten sind

2. Kann DDL-Änderungsanweisungen bereitstellen

Kanal-HA-Mechanismus:

Der HA-Implementierungsmechanismus von Canal basiert auf Zookeeper, der hauptsächlich in die HA des Canal-Servers und des Canal-Clients unterteilt ist. Kanalserver: Um die Anzahl der Anfragen für MySQL-Dumps zu reduzieren, kann sich auf jedem Server nur eine Instanz gleichzeitig im Ausführungszustand befinden und die anderen im Standby-Zustand.

Kanal-Client: Um die Reihenfolge zu gewährleisten, kann eine Instanz immer nur von einem Kanal-Client gleichzeitig abgerufen/bestätigt/zurückgesetzt werden, da sonst die Empfangsreihenfolge durch die Clients nicht garantiert werden kann. Diagramm der Canal Server HA-Architektur:

Allgemeine Schritte:

• Wenn der Canal-Server eine Canal-Instanz starten möchte, versucht er zunächst, das Urteil mit Zookeeper zu starten (Implementierung: Erstellen Sie einen EPHEMERAL-Knoten, und jeder, der ihn erfolgreich erstellt, darf ihn starten).
• Nachdem der Zookeeper-Knoten erfolgreich erstellt wurde, startet der entsprechende Canal-Server die entsprechende Canal-Instanz. Die nicht erfolgreich erstellte Canal-Instanz befindet sich im Standby-Zustand.
• Sobald Zookeeper feststellt, dass der von Canal-Server A erstellte Knoten verschwindet, benachrichtigt er sofort andere Canal-Server, Schritt 1 erneut auszuführen und erneut einen Canal-Server zum Starten der Instanz auszuwählen.
• Bei jeder Verbindung fragt der Canal-Client zunächst Zookeeper, wer die Canal-Instanz gerade gestartet hat, und stellt dann eine Verbindung zu ihm her. Wenn die Verbindung nicht verfügbar ist, wird erneut versucht, eine Verbindung herzustellen.

Die Canal-Client-Methode ähnelt der Canal-Server-Methode und verwendet auch die Zookeeper-Methode zum Vorwegnehmen von EPHEMERAL-Knoten zur Steuerung.

Dies ist das Ende dieses Artikels über die detaillierte Analyse des Binlog-Protokolltools zur Überwachung von MySQL: Canal. Weitere relevante MySQL-Binlog-Protokollinhalte finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder durchsuchen Sie die folgenden verwandten Artikel weiter. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!