У нас есть клиент репликации mysql, работающий на нашем сервере резервного копирования. После сбоя питания на прошлой неделе он перестал воспроизводиться. До этого он работал без перебоев в течение нескольких месяцев.
Я попытался перезапустить и ведущий, и ведомый, но это не помогло. Я могу получить доступ к главному серверу с подчиненного, поэтому проблема не в сети.
Могу ли я еще что-нибудь сделать, чтобы попытаться диагностировать проблему?
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: master
Master_User: username
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000060
Read_Master_Log_Pos: 46277494
Relay_Log_File: mysqld-relay-bin.000348
Relay_Log_Pos: 98
Relay_Master_Log_File: mysql-bin.000060
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB:
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: 46277494
Relay_Log_Space: 98
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 in set (0.00 sec)
ERROR:
No query specified
mysql> show master status\G;
*************************** 1. row ***************************
File: mysql-bin.000069
Position: 851796
Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)
ERROR:
No query specified
Обновление: ошибки попадали в daemon.log, а не в mysql.err, что объясняет, почему я не мог их найти. Проблема, похоже, в том, что мастер говорит, что журнал недоступен, что не имеет особого смысла, потому что этот журнал (и предыдущий) все еще доступны на мастере.
090710 9:17:35 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000060' at position 46277494, relay log './mysqld-relay-bin.000350' position: 98
090710 9:17:35 [Note] Slave I/O thread: connected to master 'username@master:3306', replication started in log 'mysql-bin.000060' at position 46277494
090710 9:17:35 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
090710 9:17:35 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
090710 9:17:35 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000060', position 46277494
Добро пожаловать в чудесный мир репликации MySQL. Я сам не сталкивался с вашей конкретной проблемой, но я столкнулся с множеством других странных проблем, и ближайшее решение - просто выполнить повторную синхронизацию с мастером, как если бы это новый ведомый, и покончить с этим.
Вам следует изучить журнал ошибок ведомого устройства - обычно он довольно четко описывает, в чем проблема.
У вас должны быть журналы ошибок mysql, привязанные к вашей системе мониторинга, иначе ваши ведомые устройства потенциально бесполезны.
Более того, у вас должен быть монитор, который проверяет статус ведомого.
И для того, чтобы вообще можно было использовать, вы также захотите время от времени проверять синхронизацию ведомых устройств, возможно, используя что-то вроде mk-table-counterum; в идеале также привязать результаты этого к вашей системе мониторинга.
Многие люди устанавливают skip-slave-start, чтобы убедиться, что все в порядке, если подчиненное устройство прекращает репликацию перед его запуском. Попробуйте запустить 'start slave' и посмотрите, не изменится ли что-нибудь или что-то будет зарегистрировано. Кроме того, странно, что процесс SlaveSQL запущен, а SlaveIO - нет. Возможно, локальные журналы реле на ведомом устройстве были повреждены, хотя это должен сообщаться в журналах. Вы можете попробовать отключить Mysql, а затем удалить журналы реле.
Как уже упоминал womble, забудьте об устранении ошибок репликации. В этом подходе меня больше всего беспокоит то, что вам, возможно, удастся снова перезапустить репликацию и вы думаете, что все в порядке, но что, если некоторые части вашей базы данных все еще не синхронизированы?
Лучше всего уничтожить подчиненную базу данных и перезапустить репликацию из моментального снимка главной. Это не должно быть настолько разрушительным, как вы думаете:
http://www.neotitans.com/resources/mysql/quick-replication-error-recovery-via-snapshots.html
В приведенном выше отчете я обнаружил проблему, этот файл должен быть установлен на (Slave_IO_Running): да, но в отчете выше он показывает Slave_IO_Running: Нет.
Это вызывает проблему. Если эта переменная имеет значение «Нет», значит, поток ввода-вывода был остановлен. так что репликации больше нет. Вам нужно будет проверить Last_SQL_Errno и Last_SQL_Err для получения дополнительной информации о причине. Номер ошибки 0 и сообщение о пустой строке означают «нет ошибки». Last_SQL_Error появляется в журнале ошибок ведомого устройства.
Чтобы решить эту проблему, остановите ведомый
Затем установите:
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
Это говорит ведомому устройству пропустить один запрос (который является недопустимым, что привело к остановке репликации). Если вы хотите пропустить два запроса, используйте SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2; вместо этого и так далее.
Затем перезапустите ведомое устройство и проверьте журналы, надеясь, что это решит проблему ...