Я искал google полностью для окончательного решения или набора шагов для решения этой проблемы, но, похоже, не так много качественных результатов, и я не нашел вопроса о переполнении стека. Мы пытаемся настроить репликацию MySQL с использованием одного подчиненного. Ведомое устройство, как представляется, реплицируется в порядке, и возникает следующая ошибка:
Невозможно разобрать запись события журнала протокола. Возможные причины: главный двоичный журнал поврежден (вы можете проверить это, запустив mysqlbinlog в двоичном журнале), журнал ведомых реле поврежден (вы можете проверить это, запустив mysqlbinlog в журнале реле), сетевой проблемы или ошибки в главном или подчиненном коде MySQL. Если вы хотите проверить журнал основных двоичных журналов или ведомых реле, вы сможете узнать их имена, выпустив "SHOW SLAVE STATUS" на этом подчиненном устройстве.
Чтобы извлечь выгоду из большого числа людей, которые неизбежно наткнутся на этот вопрос из поиска, было бы полезно, если бы кто-то, кто отвечает, предоставил обзор того, что может быть неправильным, и какие шаги необходимо предпринять для решения этой проблемы, но я также расскажу подробнее о моей конкретной ситуации в надежде, что кто-то сможет мне помочь в ее решении.
Дамп, который мы импортировали в подчиненный, чтобы запустить его, был создан с использованием следующей команды мастера:
mysqldump --opt --allow-keywords -q -uroot -ppassword dbname > E:\Backups\dbname.sql
script, который выполняет эту резервную копию, также регистрирует основную текущую позицию двоичного журнала. Затем мы предприняли следующие шаги для начала репликации на подчиненном устройстве:
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]
Для получения дополнительной информации о регистрации я создал пакет script для запуска "SHOW SLAVE STATUS" и "SHOW FULL PROCESSLIST" каждый час. Вот результаты до и после сбоя:
--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 binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master or slave MySQL code. If you want to check the master binary log or slave 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 за тысячами инструкций и остановил тысячу операторов после точки отказа и перенаправил вывод в текстовый файл. Я не видел ошибок коррупции в командной строке или в файле журнала. Это то, что файл журнала сказал в месте сбоя:
...
# 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 сверху, и не видел никаких ошибок в командной строке (но не получил возможности открыть файл журнала 100mb, который был сгенерирован, так как я не хотел болото вниз по производственному серверу).
Так что сейчас я не понимаю, что еще попробовать. Я просто ищу информацию о том, что может быть неправильным, или какие-либо предложения о том, какие шаги следует предпринять дальше. Спасибо!
