Praktische Aufzeichnung der MySQL 5.6 Master-Slave-Fehlerberichterstattung

1. Problemsymptome

Version: MySQL 5.6, unter Verwendung der Master-Slave-Replikationsstruktur, die mit der herkömmlichen Binlog-Datei- und POS-Methode konfiguriert wurde.

Nach dem Neustart der Instanz wird der Master-Slave-Replikationsfehler in der obigen Abbildung angezeigt.

2. Fehlerbedeutung

Der Fehler ist in zwei Teile aufgeteilt.

Teil I

• Der Client hat den Master aufgefordert, die Replikation von einer Position > Dateigröße zu starten.
• das erste Ereignis 'mysql-bin.000398' um 163800795, das letzte gelesene Ereignis aus './mysql-binlog.000398' um 4, das letzte gelesene Byte aus './mysql-bin.000398' um 4'

Teil I

Dieser Teil stammt aus der DUMP-Thread-Funktion der Hauptbibliothek

mysql_binlog_send
 ->sender.run()
  ->Binlog_sender::init
    ->Binlog_sender::check_start_file

 wenn ((Datei = open_binlog_file(&cache, m_linfo.log_file_name, &errmsg)) < 0) 
 {
  set_fatal_error(errmsg);
  Rückgabe 1;
 }

 Größe = my_b_filelength(&cache);
 end_io_cache(&cache);
 mysql_file_close(Datei, MYF(MY_WME));

 wenn (m_start_pos > Größe)
 {
  set_fatal_error("Client forderte Master auf, Replikation von " zu starten
          "Position > Dateigröße");
  Rückgabe 1;
 }

Der Schlüssel sind die beiden Werte m_start_pos und size, wobei m_start_pos von der Position kommt, die aus der Bibliothek gelesen werden muss. Und Größe ist die Größe dieser Binärprotokolldatei. Daher ist es leicht zu verstehen, dass es natürlich falsch ist, wenn der vom IO-Thread benötigte POS-Punkt größer als die Größe dieser Binärprotokolldatei ist.

Teil 2

Dieser Teil stammt auch aus dem DUMP-Thread

mysql_binlog_send
 ->sender.run()
   ->Binlog_sender::init
   ->während (!has_error() und !m_thd->killed)
   #Wenn normal, beginnen Sie hier mit der Schleife und dem Lesen von Binlog-Ereignissen. Wenn ein Fehler auftritt, fahren Sie mit der folgenden Logik fort. #Wenn ein Lesefehler auftritt, melden Sie einen Fehler my_snprintf(error_text, sizeof(error_text),
         "%s; das erste Ereignis '%s' um %lld, "
         "das letzte Ereignis wurde um %lld von '%s' gelesen, "
         "das letzte von '%s' gelesene Byte bei %lld.",
         m_errmsg,
         m_start_file, m_start_pos, m_letzte_file, m_letzte_pos,
         log_datei, my_b_tell(&log_cache));

Hier schauen wir uns hauptsächlich m_start_pos und m_last_pos an. Tatsächlich ist m_start_pos die Positionsinformation, die aus der Slave-Bibliothek gelesen werden muss, was mit dem vorherigen Fehlerbericht übereinstimmt, und m_last_pos stammt aus dem Dump-Thread, was die letzte Leseposition ist. Offensichtlich wird es hier nicht einmal gelesen, daher ist die Position die anfängliche Position 4.

3. Mögliche Ursachen

Nach der Analyse denke ich, dass der wahrscheinlichste Grund mit sync_binlog zusammenhängt.

Wenn wir es nicht auf 1 setzen, wird der Betriebssystem-Cache möglicherweise nicht auf die Festplatte geleert. Wenn der Hauptbibliotheksserver abstürzt und direkt neu gestartet wird, kann dieses Problem leicht auftreten.

Nach einer kurzen Google-Suche stellte ich fest, dass die meisten dieser Fehler durch Serverabstürze und dadurch verursacht werden, dass sync_binlog nicht auf 1 gesetzt ist.

Auch dies belegt unsere Aussage.

Abschließend habe ich überprüft, dass die Hauptdatenbank der Problemdatenbank tatsächlich nicht auf Double 1 eingestellt war.

Durch diesen kleinen Fall ist uns die Bedeutung der Einrichtung von Doppel-Einsen noch deutlicher bewusst geworden.

Zusammenfassen

Dies ist das Ende dieses Artikels über die Fehlerberichterstattung von MySQL 5.6 Master-Slave. Weitere relevante Inhalte zur Fehlerberichterstattung von MySQL 5.6 Master-Slave finden Sie in den vorherigen Artikeln von 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!