Einführung und Analyse von drei Binlog-Formaten in MySQL

eins. Einführung in das Mysql Binlog-Format    

Das Mysql-Binlog-Protokoll hat drei Formate: Statement, MiXED und ROW!

1. Anweisung: Jede SQL-Anweisung, die Daten ändert, wird im Binärprotokoll aufgezeichnet.

Vorteile: Es ist nicht erforderlich, Änderungen in jeder Zeile aufzuzeichnen. Dadurch wird die Anzahl der Binlog-Protokolle reduziert, E/A gespart und die Leistung verbessert. (Wie viel Leistung und Protokollvolumen im Vergleich zu Zeilen eingespart werden kann, hängt von der SQL-Situation der Anwendung ab. Normalerweise ist die Protokollmenge, die durch Ändern oder Einfügen desselben Datensatzes im Zeilenformat generiert wird, immer noch geringer als die Protokollmenge, die durch eine Anweisung generiert wird. Wenn jedoch bedingte Aktualisierungsvorgänge, das Löschen ganzer Tabellen, Tabellenänderungen und andere Vorgänge berücksichtigt werden, generiert das ROW-Format eine große Menge an Protokollen. Wenn Sie also darüber nachdenken, Protokolle im ROW-Format zu verwenden, sollten Sie die tatsächliche Situation der Anwendung berücksichtigen, wie stark die Menge der generierten Protokolle ansteigt und welche IO-Leistungsprobleme dies mit sich bringt.)

Nachteile: Da nur die ausgeführten Anweisungen aufgezeichnet werden, müssen, damit diese Anweisungen auf dem Slave korrekt ausgeführt werden können, auch einige relevante Informationen jeder Anweisung während der Ausführung aufgezeichnet werden, um sicherzustellen, dass alle Anweisungen auf dem Slave dieselben Ergebnisse erzielen können wie bei der Ausführung auf dem Master. Darüber hinaus kann es bei der MySQL-Replikation, beispielsweise bei einigen spezifischen Funktionen, dazu kommen, dass der Slave mit dem Master übereinstimmt, was zu vielen damit verbundenen Problemen führt (beispielsweise bei der sleep()-Funktion, last_insert_id() und benutzerdefinierten Funktionen (udf)).

Anweisungen mit den folgenden Funktionen können ebenfalls nicht kopiert werden:

* DATEI LADEN()

* UUID()

* BENUTZER()

* GEFUNDENE_ZEILEN()

* SYSDATE() (sofern die Option --sysdate-is-now nicht beim Start aktiviert wurde)

Gleichzeitig erzeugt INSERT ...SELECT mehr Zeilensperren als RBR

2. Zeile: zeichnet die kontextbezogenen Informationen der SQL-Anweisung nicht auf, speichert nur, welcher Datensatz geändert wurde.

Vorteile: Binlog muss die kontextbezogenen Informationen der ausgeführten SQL-Anweisung nicht aufzeichnen, sondern nur aufzeichnen, wie der Datensatz geändert wurde. Daher zeichnet der Protokollinhalt auf Zeilenebene die Details jeder Datenänderungszeile klar auf. Und es wird kein Problem geben, dass die gespeicherte Prozedur, Funktion oder der Triggeraufruf und der Trigger in bestimmten Situationen nicht korrekt kopiert werden können

Nachteile: Wenn alle ausgeführten Anweisungen im Protokoll aufgezeichnet werden, werden sie als Änderungen an jeder Datensatzzeile aufgezeichnet, was zu einer großen Menge an Protokollinhalten führen kann. Wenn beispielsweise eine Aktualisierungsanweisung mehrere Datensätze ändert, wird jede Änderung im Binärprotokoll aufgezeichnet, was zu einer großen Menge an Binärprotokollen führt. Insbesondere bei der Ausführung von Anweisungen wie „Alter Table“ wird jeder Datensatz aufgrund der Änderung der Tabellenstruktur geändert, sodass jeder Datensatz der Tabelle im Protokoll aufgezeichnet wird.

3. Gemischte Ebene: Es handelt sich um eine Mischung der beiden oben genannten Ebenen. Allgemeine Anweisungsänderungen verwenden das Anweisungsformat, um das Binärprotokoll zu speichern. Beispielsweise können einige Funktionen und Anweisungen den Master-Slave-Replikationsvorgang nicht abschließen, sodass das Zeilenformat zum Speichern des Binärprotokolls verwendet wird. MySQL unterscheidet das aufzuzeichnende Protokollformat je nach ausgeführter SQL-Anweisung, d. h. es wird zwischen Anweisung und Zeile gewählt. Der Zeilenebenenmodus der neuen Version von MySQL wurde ebenfalls optimiert. Nicht alle Änderungen werden auf Zeilenebene aufgezeichnet. Wenn sich beispielsweise die Tabellenstruktur ändert, wird dies im Anweisungsmodus aufgezeichnet. Bei Anweisungen, die Daten ändern, wie etwa Aktualisieren oder Löschen, werden Änderungen an allen Zeilen weiterhin aufgezeichnet.

2. Grundkonfiguration und Formateinstellung von Binlog

1. Grundlegende Vorbereitung

Das MySQL BInlog-Protokollformat kann durch das Attribut binlog_format der MySQL my.cnf-Datei angegeben werden. Zum Beispiel die folgenden:

binlog_format = MIXED //binlog-Protokollformat

log_bin = Verzeichnis/mysql-bin.log //binlog-Protokollname

expire_logs_days = 7 //Bereinigungszeit für das Ablaufen des Binlogs

max_binlog_size 100m //Größe jeder Binlog-Protokolldatei

2. Auswahl des Binlog-Protokollformats

Mysql verwendet standardmäßig das Statement-Log-Format und MIXED wird empfohlen.

Aufgrund einiger spezieller Verwendungszwecke können Sie die Verwendung von ROWED in Betracht ziehen, z. B. das Synchronisieren von Datenänderungen über Binlog-Protokolle, wodurch viele damit verbundene Vorgänge eingespart werden. Die Verarbeitung von Binlog-Daten wird sehr einfach, und im Vergleich zu gemischten Daten ist auch das Parsen sehr einfach (vorausgesetzt natürlich, dass der durch das erhöhte Protokollvolumen verursachte IO-Overhead im tolerierbaren Bereich liegt).

3. Auswahl des MySQLBinlog-Formats

MySQL-Auswahlprinzip für das Protokollformat: Wenn Sie INSERT, UPDATE, DELETE und andere direkte Tabellenoperationen verwenden, wird das Protokollformat gemäß der Einstellung von binlog_format aufgezeichnet. Wenn Sie Verwaltungsanweisungen wie GRANT, REVOKE, SET PASSWORD verwenden, wird ohnehin der SBR-Modus zum Aufzeichnen verwendet.

drei. Mysql Binlog-Protokollanalyse

Zeigen Sie das spezifische MySQL-Protokoll über den Befehl MysqlBinlog wie folgt an:

///

ZEITSTEMPEL FESTLEGEN=1350355892/*!*/;

BEGINNEN

/*!*/;

# bei 1643330

#121016 10:51:32 Server-ID 1 End-Log-Pos 1643885 Abfrage Thread-ID = 272571 Exec-Zeit = 0 Fehlercode = 0

ZEITSTEMPEL FESTLEGEN=1350355892/*!*/;

In T_test einfügen….)

/*!*/;

# bei 1643885

#121016 10:51:32 Server-ID 1 end_log_pos 1643912 Xid = 0

BEGEHEN /*!*/;

///

1. Zeit, Dinge anzufangen:

ZEITSTEMPEL FESTLEGEN=1350355892/*!*/;

BEGINNEN

2. SQLevent-Startpunkt

#bei 1643330: Der Startpunkt des Ereignisses, beginnend bei 1643330 Bytes.

3. Der Zeitpunkt, zu dem sqlevent auftritt

#121016 10:51:32: ist die Zeit, zu der das Ereignis aufgetreten ist.

4.Server-ID

Server-ID 1: die Server-ID des Masters

5. SQLevent-Endpunkt und aufgewendete Zeit, Fehlercode

end_log_pos 1643885: ist der Endpunkt des Ereignisses und endet mit 1643885 Bytes.

execTime 0: aufgewendete Zeit

error_code=0: Fehlercode

Xid: Ereignis zeigt die festgeschriebene XA-Transaktion an

Gemischte Protokollbeschreibung:

Während des Slave-Protokollsynchronisierungsprozesses generiert das MIXED-Protokollformat für Zeitfunktionen wie jetzt eine entsprechende Zeitzeichenfolge unix_timestamp()*1000 im Protokoll. Wenn der Slave die Synchronisierung abgeschlossen hat, verwendet er die Zeit, zu der das sqlEvent auftritt, um die Datengenauigkeit sicherzustellen. Darüber hinaus kann der Slave für einige Funktionsfunktionen die entsprechende Datensynchronisierung abschließen. Für einige der oben angegebenen UDF-Funktionen, die dazu führen, dass der Slave die Situation nicht erkennt, werden diese Binlogs im ROW-Format gespeichert, um sicherzustellen, dass das generierte Binlog vom Slave zum Abschließen der Datensynchronisierung verwendet werden kann.

Das Obige sind einige Informationen, die während der Recherche gesammelt wurden, bevor ein Modul entwickelt wurde, das die Datensynchronisierung über MySQL-Binlog abschließt. Bitte korrigieren Sie mich, wenn etwas falsch ist!

Zusammenfassen

Dies ist das Ende dieses Artikels über die Einführung und Analyse der drei Formate von Binlog in MySQL. Weitere Informationen zu den drei Formaten von Binlog in MySQL finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!