Die MySQL-Replikation schlägt mit Fehler fehl "Relay-Protokollereigniseintrag konnte nicht analysiert werden."

Question

Ich habe google gründlich nach einer endgültigen Lösung oder einer Reihe von Schritten gesucht, um dieses Problem zu lösen, aber es scheint nicht viele qualitativ hochwertige Ergebnisse zu sein, und ich habe nicht die Frage nach Stack-Überlauf gefunden. Wir versuchen, die MySQL-Replikation mit einem Slave einzurichten. Der Slave scheint zu replizieren, und dann tritt der folgende Fehler auf:

Konnte Relay-Protokollereigniseintrag nicht analysieren. Die möglichen Gründe sind: Das binäre Protokoll des Masters ist beschädigt (Sie können dies überprüfen, indem Sie "mysqlbinlog" im binären Protokoll ausführen), das Relay-Protokoll des Slaves ist beschädigt (Sie können dies überprüfen, indem Sie im Reloc Log "mysqlbinlog" ausführen) Netzwerkproblem oder ein Fehler im MySQL-Code des Masters oder Slaves. Wenn Sie das Binärlog des Masters oder das Relay-Protokoll des Slaves überprüfen möchten, können Sie deren Namen erkennen, indem Sie "SHOW SLAVE STATUS" auf diesem Slave ausgeben.

Um die große Zahl von Menschen zugute kommen, die sich zwangsläufig auf diese Frage aus einer Suche stolpern, wäre es hilfreich, wenn jemand, der einen Überblick über vorgesehen reagiert, was falsch sein könnte gehen und welche Schritte zu ergreifen, um zu beheben Dieses Problem, aber ich werde auch weitere Details im Zusammenhang mit meiner speziellen Situation in der Hoffnung, dass jemand kann mir helfen, es zu lösen.

---

The Dump, die wir in den Slave importiert es wurde geschaffen, um den Einstieg mit dem folgenden Befehl auf dem Master: Position

mysqldump --opt --allow-keywords -q -uroot -ppassword dbname > E:\Backups\dbname.sql 

Das Skript, das diese Sicherung führt auch protokolliert die Master aktuellen Binärlogs . Wir haben dann die folgenden Schritte Replikation auf dem Slave zu starten:

1. STOP SLAVE; 
2. DROP DATABASE dbname; 
3. SOURCE dbname.sql; 
    (... waited a few hours for the 10gb dump to import) 
4. RESET SLAVE; 
5. CHANGE MASTER TO MASTER_HOST='[masterhostname]', MASTER_USER='[slaveusername]', MASTER_PASSWORD='[slaveuserpassword]', MASTER_PORT=[port], MASTER_LOG_FILE='[masterlogfile]', MASTER_LOG_POS=[masterlogposition]; 
6. START SLAVE; 

Nach etwa einem Tag der Replikation funktioniert gut, es scheiterte wieder um 3:43 Uhr. Das erste, was im Fehlerprotokoll von MySQL auftauchte, war der obige Fehler. Dann wieder ein generischer Fehler aufgetreten, nachdem sie mit dem gleichen Datenstand:

Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log '[masterlogfile]' position [masterlogpos] 

Weitere Logging-Informationen, ich hatte eine Batch-Skript einrichten, um „SHOW SLAVE STATUS“ und „SHOW FULL PROCESS“ jede Stunde laufen. Hier sind die Ergebnisse vor und nach dem Scheitern:

--Monitoring: 3:00:00.15 

Slave Status: 
*************************** 1. row *************************** 
      Slave_IO_State: Waiting for master to send event 
       Master_Host: 192.168.xxx.xxx 
       Master_User: slave_user 
       Master_Port: xxxx 
       Connect_Retry: 60 
      Master_Log_File: mysql-bin.000xxx 
     Read_Master_Log_Pos: 316611912 
      Relay_Log_File: dbname-relay-bin.00000x 
       Relay_Log_Pos: 404287513 
     Relay_Master_Log_File: mysql-bin.000xxx 
      Slave_IO_Running: Yes 
      Slave_SQL_Running: Yes 
      Replicate_Do_DB: dbname 
     Replicate_Ignore_DB: 
     Replicate_Do_Table: 
    Replicate_Ignore_Table: 
    Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
       Last_Errno: 0 
       Last_Error: 
       Skip_Counter: 0 
     Exec_Master_Log_Pos: 316611912 
      Relay_Log_Space: 404287513 
      Until_Condition: None 
      Until_Log_File: 
       Until_Log_Pos: 0 
     Master_SSL_Allowed: No 
     Master_SSL_CA_File: 
     Master_SSL_CA_Path: 
      Master_SSL_Cert: 
      Master_SSL_Cipher: 
      Master_SSL_Key: 
     Seconds_Behind_Master: 0 

*************************** 1. row *************************** 
    Id: 98 
    User: system user 
    Host: 
    db: NULL 
Command: Connect 
    Time: 60547 
    State: Waiting for master to send event 
    Info: NULL 
*************************** 2. row *************************** 
    Id: 99 
    User: system user 
    Host: 
    db: NULL 
Command: Connect 
    Time: 5 
    State: Has read all relay log; waiting for the slave I/O thread to update it 
    Info: NULL 
*************************** 3. row *************************** 
    Id: 119 
    User: root 
    Host: localhost:xxxx 
    db: NULL 
Command: Query 
    Time: 0 
    State: NULL 
    Info: SHOW FULL PROCESSLIST 

--Monitoring: 4:00:02.71 

Slave Status: 
*************************** 1. row *************************** 
      Slave_IO_State: Waiting for master to send event 
       Master_Host: 192.168.xxx.xxx 
       Master_User: slave_user 
       Master_Port: xxxx 
       Connect_Retry: 60 
      Master_Log_File: mysql-bin.000xxx 
     Read_Master_Log_Pos: 324365637 
      Relay_Log_File: dbname-relay-bin.00000x 
       Relay_Log_Pos: 410327741 
     Relay_Master_Log_File: mysql-bin.000xxx 
      Slave_IO_Running: Yes 
      Slave_SQL_Running: No 
      Replicate_Do_DB: dbname 
     Replicate_Ignore_DB: 
     Replicate_Do_Table: 
    Replicate_Ignore_Table: 
    Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
       Last_Errno: 0 
       Last_Error: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. 
       Skip_Counter: 0 
     Exec_Master_Log_Pos: 322652140 
      Relay_Log_Space: 412041238 
      Until_Condition: None 
      Until_Log_File: 
       Until_Log_Pos: 0 
     Master_SSL_Allowed: No 
     Master_SSL_CA_File: 
     Master_SSL_CA_Path: 
      Master_SSL_Cert: 
      Master_SSL_Cipher: 
      Master_SSL_Key: 
     Seconds_Behind_Master: NULL 

*************************** 1. row *************************** 
    Id: 98 
    User: system user 
    Host: 
    db: NULL 
Command: Connect 
    Time: 64149 
    State: Waiting for master to send event 
    Info: NULL 
*************************** 2. row *************************** 
    Id: 122 
    User: root 
    Host: localhost:3029 
    db: NULL 
Command: Query 
    Time: 0 
    State: NULL 
    Info: SHOW FULL PROCESSLIST 

ich nach den Anweisungen von dem Fehler versucht und lief mysqlbinlog auf dem Relay-Log des Slaves mit start_position Tausenden von Aussagen vor und stop_position Tausenden von Aussagen nach dem Punkt der Fehler und leitete die Ausgabe in eine Textdatei um. Ich habe keine Fehler in der Befehlszeile oder in der Protokolldatei angezeigt. Dies ist, was die Protokolldatei um den Punkt des Scheiterns sagte:

... 
# at 410327570 
#120816 3:43:26 server id 1 log_pos 322651969 Intvar 
SET INSERT_ID=3842697; 
# at 410327598 
#120816 3:43:26 server id 1 log_pos 322651997 Query thread_id=762340 exec_time=0 error_code=0 
SET TIMESTAMP=1345113806 
insert into LOGTABLENAME (UpdateDate, Description) values (now(), "Invalid floating point operation"); 
# at 410327741 
#120816 3:44:26 server id 1 log_pos 322754486 Intvar 
SET INSERT_ID=3842701; 
# at 410327769 
#120816 3:43:26 server id 1 log_pos 322754514 Query thread_id=762340 exec_time=0 error_code=0 
SET TIMESTAMP=1345113866; 
insert into LOGTABLENAME (UpdateDate, Description) values (now(), "Invalid floating point operation"); 
# at 410327912 
... 

Interessant, dass es an diesem Punkt eine ungültige Gleitkommaoperation ist die Anmeldung, aber ich bin nicht sicher, wie dass die Replikation in dieser Position zu brechen verursachen könnte. Ich habe mysqlbinlog auf dem Binärlog des Masters in SHOW SLAVE STATUS von oben ausgeführt und keine Fehler in der Befehlszeile angezeigt (aber ich hatte keine Chance, die 100 MB Log-Datei zu öffnen, die generiert wurde, weil ich nicht mogeln wollte den Produktionsserver herunterfahren).

So im Moment bin ich ratlos für was sonst noch zu versuchen. Ich bin im Grunde nur auf der Suche nach Einsichten, was schief gehen könnte oder irgendwelche Vorschläge für die nächsten Schritte. Vielen Dank!

Answer 1

Ich bin nicht sicher, was die Ursache sein kann.Aber aus dieser Situation zu erholen, würden Sie wollen, dass MySQL anzuweisen, lösche alle Relais-bin-Protokolle über die folgende Nummer

• Relay_Master_Log_File: mysql-bin.000xxx
• Exec_Master_Log_Pos: 322652140

indem Sie folgendermaßen vorgehen:

STOP SLAVE; CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.000xxx', MASTER_LOG_POS = 322652140; START SLAVE;

HINWEIS: Leser, die da draußen sind, sollten nicht von Relay_Master_Log_File verwirrt werden, es ist NICHT dasselbe wie Read_Master_Log_Pos. Und verwechseln Sie Exec_Master_Log_Pos nicht mit Read_Master_Log_Pos. Der Read_ * ist eine Read-Ahead-Strategie, mit der MySQL die Replikations-Bin-Logs vor der eigentlichen Implementierung der lokal ausgeführten Replikation vom Master herunterlädt.