У меня есть репликация master / slave с 5 подчиненными устройствами и 1 мастером. Мастером является mysql 5.1.37, а подчиненными - 5.5.8.
Два дня назад перестал работать один из рабов. В «Показать статус подчиненного» я вижу, что и поток ввода-вывода, и поток SQL работают. Поток ввода-вывода генерирует файлы журнала реле, но поток SQL не применяет изменения ... «Секунды после мастера» показывают «0», хотя я знаю, что он далеко позади (проверка binlog с помощью mysqlbinlog).
Все остальные ведомые устройства работают нормально.
Не знаю, что искать (нет ошибок в файле журнала mysql и нет ошибок в системных журналах ...)
любой совет? См. Ниже вывод состояния ведомого устройства.
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master-db
Master_User: replication
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.020839
Read_Master_Log_Pos: 56173153
Relay_Log_File: research-relay-bin.000002
Relay_Log_Pos: 252
Relay_Master_Log_File: mysql-bin.020828
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: db1,db2,db3,db4
Replicate_Ignore_DB: db5,db6
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: 975734937
Relay_Log_Space: 10714389571
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
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 300
Есть некоторые особенности, на которые следует обратить внимание при репликации MySQL
1) Одновременное использование replicate-do-db и replicate-ignore-db
На странице есть блок-схема, показывающая порядок обработки. Лично я не использую одновременно replicate-do-db и replicate-ignore-db. Я использую то или другое. Если другие ведомые устройства не имеют такой же проблемы, исключите это.
2) Выполнение ЗАГРУЗКИ ДАННЫХ INFILE
То, как с этим справляется репликация MySQL, просто ужасно. Каждый раз, когда ЗАГРУЗКА ДАННЫХ INFILE выполняется на Мастере, весь входной файл помещается в двоичные журналы Мастера. Подчиненное устройство собирает входной файл в своих журналах реле. Подчиненное устройство повторно материализует файл данных в папке / tmp, а затем выполняет ЗАГРУЗИТЬ ДАННЫЕ INFILE на ведомом устройстве. Это не считается задержкой репликации во время этого процесса. Как администратор базы данных MySQL я знаю, что это работает, но это глупо !!!
3) Нарушение связи ведомого потока ввода-вывода
Иногда из-за изменений брандмауэра, сетевой маршрутизации или некоторых других сетевых аномалий поток ввода-вывода ведомого устройства может просто перестать получать записи для заполнения своих журналов ретрансляции. Вы также можете проверить, что поток ввода-вывода ведомого устройства отображается в списке процессов ведущего устройства. Чтобы убедиться, что поток ввода-вывода вашего ведомого устройства жив, просто выполните следующие действия на всех ведомых устройствах:
SHOW SLAVE STATUS\G
Следите за Relay_Log_Space. Он должен расти. Если он перестанет расти, MySQL может просто зависнуть без ошибок по другой безумной причине, которая приводит к предложению №4.
4) Ведомому устройству не хватает места на диске
Я написал сообщение о том, как MySQL зависает при выполнении операции MyISAM. MySQL использует таблицы MyISAM как временные таблицы. Проверьте каталог таблицы tmp по умолчанию (переменная tmpdir в MySQL)
Надеюсь, эти предложения помогут !!!