In MySQL-Hochverfügbarkeitsarchitekturen ist die primäre Datenbankreplikation eine sehr verbreitete Art.
Wenn die primäre Datenbank ausfällt, kann man eine Slave-Datenbank als neue primäre Datenbank upgraden, um die Verfügbarkeit des Dienstes sicherzustellen. Gleichzeitig kann die QPS des gesamten Clusters durch die Erweiterung der Slave-Bibliothek verbessert werden.
Unter der Master-Slave-Replikationsarchitektur verwendet MySQL Binlog, um Master-Slave-Datenkonsistenz zu erreichen.
Wie in der obigen Abbildung gezeigt, hat die MySQL-Master-Slave-Replikation hauptsächlich folgende Schritte
1. Master loggt die Änderungen am Binärprotokoll
2. Der Slave io_thread das Binlog der Hauptbibliothek anfordern und das resultierende Binlog-Log in das Relay-Log schreiben
3. Sklaven sql_thread Ereignisse im Relaislogbuch wiederholen
Neben der Funktion als Link für MySQL-Master-Slave-Replikation erfüllt binlog auch andere Zwecke. Zum Beispiel:
1. Verwenden Sie das Mysqlbinlog-Tool, um die Binlog-Datei zu parsen und so eine Punkt-zu-Zeit-Datenbankwiederherstellung durchzuführen.
2. Rückblende der Datenbank basierend auf Binlog-Ereignissen (MariaDB kann mysqlbinlog direkt für Flashbacks verwenden)
3. Githubs Open-Source-Online-Tabellenänderungstool gh-ost ist ebenfalls über binlog implementiert
4. Du kannst auch inkrementell abonnieren und konsumieren, indem du Binlogs parsest
Binlog ist sehr nützlich, aber es ist unvermeidlich, dass Sie im täglichen Betrieb und in der Wartung auf Probleme stoßen werden. Hier sind einige binlogbezogene Fehler.
Eine der häufig gestellten Fragen
Phänomen
mysqlbinlog5.5 parset die MySQL5.7 binlog-Datei erscheint.
ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 31, event_type: 35ERROR: Could not read entry at offset 123: Error in log format or read error.
Ursachenanalyse
MySQL 5.6 und andere höherwertige Versionen von Binlog-Dateien haben neue Binlog-Ereignisse hinzugefügt, wie zum Beispiel GTID-Ereignisse.
MySQLBinlog in MySQL5.5 erkennt solche Binlog-Ereignisse nicht.
Workaround
Verwenden Sie die höhere Version von mysqlbinlog, um das von der niedrigere MySQL-Version erzeugte Binlog aufzulösen
Häufig gestellte Frage zwei
Phänomen
Ein gesunder Mysql-Server zeigt den Slave-Status an
Last_SQL_Error:Relay-Log-Read-Fehler: Konnte den Relay-Log-Ereigniseintrag nicht parsen. Die möglichen Gründe sind: Das Binärprotokoll des Masters ist beschädigt (das kannst du überprüfen, indem du 'mysqlbinlog' auf dem Binärlog ausführst), Das Relay-Log des Slaves ist beschädigt (das kannst du überprüfen, indem du 'mysqlbinlog' auf dem Relay-Log ausführst). ein Netzwerkproblem oder ein Fehler im MySQL-Code des Masters oder Slaves. Wenn Sie das Binärlogbuch des Masters oder das Relais-Logbuch des Slaves überprüfen möchten, Sie können ihre Namen kennen, indem Sie diesem Sklaven die Anzeige "SKLAVENSTATUS ZEIGEN" ausgeben.
Ursachenanalyse
Die Einträge im Relay-Log können aufgrund von Binlog-Fehlern in der Master-Bibliothek, Relay-Log-Fehlern in der Slave-Bibliothek oder Netzwerkproblemen und -fehlern nicht gelesen werden. Sie wird meist durch einen Netzwerkausfall oder übermäßigen Druck auf die Slave-Bibliothek verursacht, was zu einem falschen Relay-Log-Format führt.
Workaround
Nachdem der aktuelle Synchronisationszeitpunkt gefunden und die Master-Slave-Synchronisation zurückgesetzt wurde, wird ein neues Relaislog erstellt und die Master-Slave-Synchronisation wiederhergestellt.
Aus der Ausgabe von "show slave status\G" finden Sie folgende Informationen:
Relay_Master_Log_File: mysql-bin.002540 // Das binlogExec_Master_Log_Pos des Masters, das von der Slave-Bibliothek gelesen wird: 950583017 // Der Positionspunkt, der auf dem Slave ausgeführt wurde Stoppe den Slave und setze die Synchronisation erneut, beginnend mit der Binlog-Datei, die der Slave gelesen hat, und der ausgeführten Position.
Relay_Master_Log_File: mysql-bin.002540 // Das binlogExec_Master_Log_Pos des Masters, das von der Slave-Bibliothek gelesen wird: 950583017 // Der Positionspunkt, der auf dem Slave ausgeführt wurde
Häufig gestellte Frage drei
Phänomen
Wiederherstellen des Fehlers "Show-Slave-Status nach Ausfallzeit"-Fehler:
Last_SQL_Error: Fehler beim Initialisieren der Loglog-Position: I/O-Fehler beim Lesen des Headers aus dem binären Log Last_SQL_Error: Fehler Initialisierung der Loglog-Position des Relais: Binlog hat eine fehlerhafte magische Zahl; Es handelt sich nicht um eine binäre Logdatei, die von dieser MySQL-Version verwendet werden kann
Ursachenanalyse
Ausfallzeiten, wie Stromausfall, verbranntes Mainboard usw., oder illegale Abschaltungen, die zu einer Beschädigung der Relay-bin-Datei führen
Workaround
Gleiche Frage zwei.
relay_log_recovery = 1 kann ebenfalls gesetzt werden.
Wenn der Slave aus der Bibliothek ausfällt, wenn das Relay-Log beschädigt ist und ein Teil des Relay-Logs nicht verarbeitet wird, wird das Relay-Log automatisch aufgegeben und das Log vom Master abgerufen, wodurch die Wiederherstellung des Relay-Logs abgeschlossen ist.
Häufig gestellte Frage vier
Phänomen
Erscheint beim Wechseln des Masters nach einem Neustart vom Bibliotheksrechner, der ausfällt.
Fehler (Code 1201): Konnte die Master-Info-Struktur nicht initialisieren; weitere Fehlermeldungen finden sich im MySQL-Fehlerprotokoll oder
FEHLER 1872 (HY000): Der Sklave konnte die Relay-Log-Info-Struktur aus dem Repository nicht initialisieren
Ursachenanalyse
Ausfallzeiten, wie Stromausfall, Mainboard-Burn usw., oder illegale Abschaltungen, die master.info oder realy-log.info Dateien beschädigen
Workaround
Slave> Slave alle zurücksetzen, Master auf Ersatz ändern
Vorbeugende Maßnahmen
Profileinstellungen
relay_log_info_repository=Tabelle master_info_repository=Tabelle Die Speicher-Engine von MySQL 5.6.5 mysql.slave_master_info und mysql.slave_relay_log_info ist standardmäßig auf MyISAM eingestellt, und du musst sie auf die Speicher-Engine von InnoDB umstellen
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB; ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB; mysql.slave_master_info Tabelle wird nach sync_master_info Ereignissen aktualisiert.
mysql.slave_relay_log_info Tabelle wird mit jeder Transaktion aktualisiert.
Häufig gestellte Frage 5
Phänomen
Der Master-Slave binlog_format ursprünglich eine Anweisung, die nach Änderung der Hauptdatenbank binlog_format auf Row erscheint, zeigt Slave-Status aus der Bibliothek:
Last_Error: Fehler beim ausführenden Zeilenereignis: 'Kann nicht ausgeführt werden: unmöglich in binäres Log zu schreiben, da die Anweisung im Zeilenformat ist und BINLOG_FORMAT = AUSSAGE.'
Ursachenanalyse
Wenn die Hauptdatenbank binlog_format Row ist und die Slave-Bibliothek binlog_format is-Anweisung, erscheint der obige Fehler.
Aber die Hauptbibliothek binlog_format eine Erklärung, und die Sklavenbibliothek binlog_format Reihe;
Oder wenn die Hauptdatenbank binlog_format Zeile ist, wird der Fehler nicht gemeldet, wenn die Datenbank binlog_format gemischt ist.
Wenn dein SQL-Thread tatsächlich konfiguriert ist mit binlog_format=STATEMENT: Sobald es ein ROW-Ereignis erhält, stoppt es. Das Der Grund ist, dass es dieses ROW-Ereignis in STATEMENTformat nicht protokollieren kann (manchmal nennen wir das ROW-Injektion, was entweder eine BINLOG-Anweisung oder ein ROW-Ereignis, das vom SQL-Thread des Slaves ausgeführt wird) Detaillierte Begründung:https://bugs.mysql.com/bug.php?id=69095
Workaround
SKLAVE> STOPP SLAVE; SLAVE> STELLE GLOBAL binlog_format=GEMISCHT; SLAVE> STARTE SLAVE;
Häufig gestellte Frage Nummer 6
Phänomen
Fehler beim Synchronisieren von mysql5.6 mit mysql5.5
Last_IO_Error: Erhielt fatale Fehler 1236 vom Master beim Lesen von Daten aus dem Binärlog: 'Slave kann keine Replikationsereignisse mit der Kontrollsumme verarbeiten, die Master protokollieren soll; Das erste Ereignis 'mysql-bin.000001' bei 4, das letzte Ereignis von 'mysql-bin.000001' bei 120, das letzte Byte von 'MySQL-bin.000001' bei 120.'
Ursachenanalyse
Um das Problem zu lösen, dass die auf dem primären Server laufenden SQL-Anweisungen aufgrund von Software- und Hardware- oder Netzwerkübertragungsfehlern nicht mit den auf dem Server laufenden SQL-Anweisungen übereinstimmen (sogenannte Event-Corrupt), fügt MySQL 5.6 die Funktion Replication Event Checksum hinzu. Wenn ein Ereignis in das Binärlogbuch geschrieben wird, wird auch die Prüfsumme in das Binärprotokoll geschrieben, und nachdem das Ereignis über das Netzwerk an den Sklaven übertragen wurde, wird es am Sklaven verifiziert und in das Relaislogbuch des Sklaven geschrieben. Da bei jedem Schritt Ereignisse und Prüfsummen protokolliert werden, können wir schnell herausfinden, worum es geht.
In mysql5.6.5 und späteren Versionen binlog_checksum ist der Standardwert crc32,
Der Standardwert binlog_checksum vorherigen Version war keiner
Lösung
Sklave> globale Stelle binlog_checksum=none
Häufig gestellte Frage 7
Phänomen
Nachdem die Festplatte voll ist, bereinige manuell die binlog-Datei und die mysql-bin.index-Datei
Die binären Logs sind leer, aber der Master-Status ist normal.
MySQL> zeigt binäre Logs an; Leere Menge (0,00 Sekunden)mysql> Masterstatus anzeigen; +------------------+-----------+--------------+------------------+ | Datei | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+-----------+--------------+------------------+ | mysql-bin.001385 | 987114584 | | | +------------------+-----------+--------------+------------------+
Ursachenanalyse
Nachdem ich die Datei mysql-bin.index überprüft hatte, fand ich die erste leere Zeile.
Im mysql-Quellcode rpl_master.cc:show_binlogs() finden Sie folgenden Code:
/* The file ends with EOF or empty line */ während ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1) Leere Zeilen gelten als das Ende des Dokuments
(Referenz.)https://yq.aliyun.com/articles/213657Artikel)
Vorbeugende Maßnahmen
Lösche binlog nicht manuell, bearbeite die mysql-bin.index-Datei nicht manuell, es sei denn, du weißt, was du tust, sonst legst du vielleicht selbst Minen!
Zusammenfassung
DBAs müssen auf die Verbesserungen des Binlogs in jeder neuen MySQL-Version achten (wie die in Version 5.6 hinzugefügte gtid-Funktion Enhanced Multi-threaded Slaves in Version 5.7) und die Bedeutung jedes Parameters im Detail verstehen, damit sie wissen, was er meint, wenn sie auf Fehler stoßen, und Probleme leicht lösen können.
|