Replikacja MySQL kończy się niepowodzeniem z błędem "Nie można przeanalizować wpisu zdarzenia dziennika przekazywania."

Question

Szukałem w Google dokładnego rozwiązania lub zestawu kroków, aby rozwiązać ten problem, ale nie wydaje się, że jest wiele wyników wysokiej jakości i nie znalazłem pytania na przepełnieniu stosu. Próbujemy skonfigurować replikację MySQL za pomocą jednego urządzenia podrzędnego. Wydaje się, że urządzenie podrzędne replikuje się prawidłowo, a następnie pojawia się następujący błąd:

Nie można przeanalizować zdarzenia zdarzenia dziennika przekazywania. Możliwe powody są następujące: logi binarne mastera są uszkodzone (możesz to sprawdzić, uruchamiając "mysqlbinlog" w logu binarnym), log przekaźnika slave jest uszkodzony (możesz to sprawdzić, uruchamiając "mysqlbinlog" w logu przekaźnika), a problem sieciowy lub błąd w kodzie MySQL master lub slave. Jeśli chcesz sprawdzić log binarny master lub log przekaźnika slave, będziesz mógł poznać ich nazwy, wydając "SHOW SLAVE STATUS" na tym slave.

W celu skorzystania z dużej liczby ludzi, którzy będą nieuchronnie natknąć się na to pytanie z wyszukiwarki, byłoby pomocne, jeśli ktoś odpowie warunkiem przegląd tego, co może być nie tak i jakie kroki podjąć, aby rozwiązać ten problem, ale podam też więcej szczegółów poniżej związanych z moją konkretną sytuacją w nadziei, że ktoś może mi pomóc rozwiązać ten problem.

---

wysypisko że importowane do niewolnika, aby dostać się zaczęło został stworzony za pomocą następującego polecenia w Master:

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

Skrypt, który wykonuje to kopia zapasowa rejestruje również aktualny binarny pozycji dziennika magisterskiej . Następnie podjęła następujące kroki, aby uruchomić replikację na 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; 

Po około dnia replikacji działa dobrze, to znowu nie na 3:43 rano. Pierwszą rzeczą, która pojawiła się w dzienniku błędów MySQL, był powyższy błąd. Potem pojawiła się kolejny błąd po rodzajowe z tym samym znacznikiem czasu:

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] 

Aby uzyskać więcej informacji logowania, miałem utworzyć skrypt wsadowy do uruchomienia „show SLAVE STATUS” oraz „Pokaż pełny processlist” co godzinę. Oto wyniki przed i po awarii:

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

Próbowałem postępując zgodnie z instrukcjami z błędem i pobiegł mysqlbinlog w dzienniku przekaźnika niewolnika z start_position tysięcy sprawozdania wcześniej i stop_position tysięcy sprawozdania po punkcie niepowodzenie i przekierowane wyjście do pliku tekstowego. Nie widziałem żadnych błędów korupcji w wierszu poleceń lub w pliku dziennika. To, co plik dziennika powiedział wokół punktu awarii:

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

Ciekawe, że to zalogowaniu się nieprawidłowej operacji zmiennoprzecinkowej w tym punkcie, ale nie jestem pewien, w jaki sposób, który mógłby spowodować replikacji złamać w tej pozycji. Uruchomiłem mysqlbinlog na binarnym logu nadrzędnego znalezionym w SHOW SLAVE STATUS powyżej i nie widziałem żadnych błędów w wierszu poleceń (ale nie otrzymałem szansy na otwarcie pliku dziennika 100mb, który został wygenerowany, ponieważ nie chciałem torfować w dół do serwera produkcyjnego).

Tak więc teraz nie mam pojęcia, co jeszcze spróbować. Po prostu szukam wglądu w to, co może się nie udać, lub sugestie, jakie kroki należy podjąć. Dzięki!

Answer 1

Nie jestem pewien, jaka może być podstawowa przyczyna.Ale żeby wyjść z tej sytuacji, którą chcesz polecić MySQL, aby usunąć wszystkie przekaźnik-bin-logów poza następnym punkcie

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

wykonując następujące czynności:

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

UWAGA: Dla czytelników, nie dajcie się pomylić z Relay_Master_Log_File, to NIE jest to samo, co Read_Master_Log_Pos. I nie mylić Exec_Master_Log_Pos z Read_Master_Log_Pos. Read_ * to strategia odczytu z wyprzedzeniem, którą MySQL pobiera, aby pobrać dzienniki bin replikacji z mastera przed rzeczywistą implementacją replikacji wykonywanej lokalnie.