Denne meddelelse i SHOW SLAVE STATUS betyder at den binære log på enten master eller slave er korrupt:
| Last_SQL_Errno: | 1594 |
| Last_SQL_Error: | Relay log read failure: 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. |
Start med at notere dig følgende:
|
1 2 3 4 5 6 |
Master_Log_File: mariadb-bin.000033 Read_Master_Log_Pos: 1047474287 Relay_Log_File: mysqld-relay-bin.000023 Relay_Log_Pos: 10356844 Relay_Master_Log_File: mariadb-bin.000033 Exec_Master_Log_Pos: 1026342167 |
Tjek logfilerne på master og slave
Nu tjekker du slavens aktuelle relay log. Se Relay_Log_File. På Ubuntu ligger den under /var/lib/mysql:
|
1 2 |
# cd /var/lib/mysql # mysqlbinlog mysqld-relay-bin.000023 |
mysqlbinlog oversætter den binære log til tekst, og du vil derfor se en masse fare hen over skærmen. Det kan godt tage tid hvis filen er stor. Når den stopper, kigger du efter en fejlmeddelelse:
|
1 2 3 4 5 6 7 |
ERROR: Error in Log_event::read_log_event(): 'Event invalid', data_len: 0, event_type: 0 ERROR: Could not read entry at offset 10356844: Error in log format or read error. DELIMITER ; # End of log file ROLLBACK /* added by mysqlbinlog */; /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/; |
I dette tilfælde er det slavens binære log der er korrupt. Og det er heldigt, for det kan vi nemt fikse.
Tjek også masterens binære log, som i mit tilfælde ligger under /var/log/mysql:
|
1 2 |
# cd /var/log/mysql # mysqlbinlog mariadb-bin.000033 |
Slavens log er korrupt
Hvis det er slavens log der indeholder fejl, gør du følgende på slaven:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
MariaDB> STOP SLAVE; MariaDB> RESET SLAVE ALL; MariaDB> CHANGE MASTER TO MASTER_HOST='10.0.0.86', MASTER_USER='slaveUser', MASTER_PASSWORD='slavePass' MASTER_PORT=3306, MASTER_LOG_FILE='mariadb-bin.000033', MASTER_LOG_POS=1026342167, MASTER_CONNECT_RETRY=10, MASTER_USE_GTID=slave_pos; MariaDB> START SLAVE; MariaDB> SHOW SLAVE STATUS\G; |
!!! BEMÆRK !!!
• RESET SLAVE ALL nulstiller bl.a. alle MASTER oplysningerne, så dem skal du have parat. Hvis du ikke har adgangskoden til din master bruger, kan du lige starte med at ændre den med ALTER USER bruger@'host' IDENTIFIED BY 'kode' både på master og slave… og husk FLUSH PRIVILEGES.
• Værdien MASTER_LOG_POS skal du tage fra Exec_Master_Log_Pos, og MASTER_LOG_FILE er Relay_Master_Log_File, som du noterede dig tidligere.
Æren for ovenstående løsning, går til dette svar : https://dba.stackexchange.com/a/75200/127493
Masterens log er korrupt
Hvis masterens log er korrupt, kan slaven ikke læse den. Drejer det sig om et enkelt statement i loggen, kan du fikse det ved at få slaven til at skippe den. Men du bør først overveje hvilke konsekvenser det manglende data kan have for de efterfølgende statements slaven modtager.
Du kan se i indlægget MariaDB replikering: Når replikeringen fejler hvordan du skipper et statement eller starter slaven forfra ved at indlæse et fuldt dump fra masteren.