La replica di MySQL fallisce con l'errore "Impossibile analizzare la voce di evento del log di inoltro".

Question

Ho cercato a fondo google per una soluzione definitiva o una serie di passaggi per risolvere questo problema, ma non sembrano esserci molti risultati di alta qualità e non ho trovato la domanda sullo stack overflow. Stiamo cercando di impostare la replica MySQL usando uno slave. Lo slave sembra replicare correttamente e quindi si verifica il seguente errore:

Impossibile analizzare la voce di evento del registro di inoltro. Le possibili ragioni sono: il log binario del master è corrotto (è possibile verificarlo eseguendo 'mysqlbinlog' nel log binario), il log di relay dello slave è corrotto (è possibile controllare questo eseguendo 'mysqlbinlog' nel log di relay), un problema di rete, o un bug nel codice MySQL del master o dello slave. Se si desidera controllare il log binario del master o il log relay dello slave, sarà possibile conoscere il loro nome emettendo 'SHOW SLAVE STATUS' su questo slave.

Al fine di beneficiare del gran numero di persone che saranno inevitabilmente inciampare su questa domanda da una ricerca, sarebbe utile se qualcuno che risponde fornito una panoramica di quello che potrebbe essere andato storto e quali misure prendere per risolvere questo problema, ma fornirò anche ulteriori dettagli di seguito relativi alla mia particolare situazione nella speranza che qualcuno possa aiutarmi a risolverlo.

---

La discarica che abbiamo importato nel schiavo di farla partire è stata creata usando il seguente comando sul master:

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

Lo script che esegue questo backup registra anche la posizione log binario corrente del master . Abbiamo poi preso le seguenti operazioni per avviare la replica sullo slave:

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; 

Dopo circa un giorno di replica lavorando bene, non è riuscito di nuovo a 3:43. La prima cosa che è apparso nel log degli errori di MySQL era l'errore sopra. Poi un altro errore generico apparso dopo con la stessa data e ora:

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] 

Per ulteriori informazioni di registrazione, avevo creato uno script batch per eseguire "SHOW SLAVE STATUS" e "Visualizza tutti i PROCESSLIST" ogni ora. Ecco i risultati prima e dopo il fallimento:

--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 

Ho provato seguendo le istruzioni da l'errore e corse mysqlbinlog sul relay log dello schiavo con uno start_position migliaia di dichiarazioni prima, e stop_position migliaia di dichiarazioni dopo il punto di errore e reindirizzato l'output in un file di testo. Non ho visto alcun errore di corruzione nella riga di comando o nel file di registro. Questo è ciò che ha detto il file di registro attorno al punto di guasto:

... 
# 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 
... 

Interessante il fatto che è la registrazione di un'operazione a virgola mobile non valido in quel punto, ma non sono sicuro di come questo potrebbe causare la replica di rottura in quella posizione. Ho eseguito mysqlbinlog sul log binario del master trovato in SHOW SLAVE STATUS da sopra e non ho visto alcun errore sulla riga di comando (ma non ho avuto la possibilità di aprire il file di log da 100mb che è stato generato poiché non volevo tormentare giù il server di produzione).

Quindi adesso sono a corto di cos'altro provare. Fondamentalmente sto solo cercando informazioni su cosa potrebbe andare storto o suggerimenti su quali passi fare in seguito. Grazie!

Answer 1

Non sono sicuro di quale sia la causa principale.Ma per recuperare da questa situazione, che ci si vuole istruire MySQL per cancellare tutti i relè-bin-logs al di là del punto seguente

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

effettuando le seguenti operazioni:

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

NOTA: Per i lettori là fuori, non essere confuso da Relay_Master_Log_File, NON è lo stesso di Read_Master_Log_Pos. E non confondere Exec_Master_Log_Pos con Read_Master_Log_Pos. Read_ * è una strategia read-ahead che MySQL esegue per scaricare i log del cestino di replica dal master prima dell'implementazione effettiva della replica eseguita localmente.