Я тщательно искал в Google окончательное решение или набор шагов для решения этой проблемы, но, похоже, не так много высококачественных результатов, и я не нашел вопрос о переполнении стека. Мы пытаемся настроить репликацию MySQL с использованием одного подчиненного устройства. Похоже, что ведомое устройство нормально реплицируется, а затем возникает следующая ошибка:
Не удалось проанализировать запись о событии в журнале ретрансляции. Возможные причины: двоичный журнал ведущего поврежден (это можно проверить, запустив 'mysqlbinlog' в двоичном логе), поврежден лог ретрансляции ведомого (вы можете проверить это, запустив 'mysqlbinlog' в журнале ретрансляции), сетевая проблема или ошибка в коде MySQL ведущего или подчиненного устройства. Если вы хотите проверить двоичный журнал ведущего устройства или журнал реле ведомого устройства, вы сможете узнать их имена, выполнив команду 'SHOW SLAVE STATUS' на этом ведомом устройстве.
Чтобы принести пользу большому количеству людей, которые неизбежно наткнутся на этот вопрос при поиске, было бы полезно, если бы кто-то, кто отвечает, предоставил обзор того, что может пойти не так, и какие шаги предпринять для решения этой проблемы, но я буду также предоставьте более подробную информацию ниже, связанную с моей конкретной ситуацией, в надежде, что кто-то может помочь мне решить ее.
Дамп, который мы импортировали в ведомое устройство для его запуска, был создан с помощью следующей команды на ведущем устройстве:
mysqldump --opt --allow-keywords -q -uroot -ppassword dbname > E:\Backups\dbname.sql
Сценарий, который выполняет это резервное копирование, также регистрирует текущую позицию двоичного журнала мастера. Затем мы предприняли следующие шаги, чтобы начать репликацию на подчиненном устройстве:
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;
Примерно через день репликация работала нормально, но в 3:43 снова произошел сбой. Первым, что появилось в журнале ошибок MySQL, была ошибка выше. Затем появилась еще одна общая ошибка с той же отметкой времени:
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]
Для получения дополнительной информации о регистрации я настроил пакетный сценарий для запуска «ПОКАЗАТЬ СОСТОЯНИЕ ВЕДОМОГО» и «ПОКАЗАТЬ ПОЛНЫЙ СПИСОК ПРОЦЕССОВ» каждый час. Вот результаты до и после отказа:
--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
Я попытался следовать инструкциям из ошибки и запустил mysqlbinlog в журнале ретрансляции подчиненного устройства с start_position тысячами операторов до и stop_position тысячами операторов после точки сбоя и перенаправил вывод в текстовый файл. Я не видел никаких ошибок в командной строке или в файле журнала. Вот что говорится в файле журнала о точке отказа:
...
# 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
...
Интересно, что в этот момент он регистрирует недопустимую операцию с плавающей запятой, но я не уверен, как это может привести к сбою репликации в этой позиции. Я запустил mysqlbinlog в двоичном журнале мастера, найденном в SHOW SLAVE STATUS сверху, и не увидел никаких ошибок в командной строке (но не получил возможности открыть файл журнала размером 100 МБ, который был сгенерирован, так как я не хотел засорять рабочий сервер).
Так что прямо сейчас я в недоумении, что еще попробовать. В основном я просто ищу любую информацию о том, что может пойти не так, или какие-либо предложения о том, какие шаги предпринять дальше. Спасибо!
