4.10.7 Часто задаваемые вопросы по репликации | Оглавление | 5 Оптимизация в MySQL |
Если вы следовали инструкциям, но установленный механизм репликации не работает, прежде всего следует искать пользовательские ошибки. Выполните следующие проверки:
SHOW MASTER STATUS
. Если да, значение Position
будет отличным от нуля. Если нет, проверьте, запущен ли головной
сервер с опцией log-bin
и установлен ли server-id
.
SHOW
SLAVE STATUS
. Ответ находится в столбце Slave_running
. Если нет,
проверьте опции подчиненного сервера и просмотрите сообщения в журнале
ошибок.
SHOW PROCESSLIST
, найдите поток, которому
соответствует значение system user
в столбце User
и none
в столбце
Host
, и проверьте столбец State
. Если в нем находится значение
connecting to master
, проверьте привилегии для пользователя репликации
на головном сервере, имя хоста головного сервера, установку DNS,
посмотрите, запущен ли головной сервер в текущее время, доступен ли он
для подчиненного сервера. После этого, если все окажется в порядке,
просмотрите журналы ошибок.
SHOW SLAVE STATUS
и проверьте журналы ошибок. Такое
обычно случается, когда некоторый запрос, успешно выполняющийся на
головном сервере, не выполняется на подчиненном. Если создан
корректный образ головного сервера и данные на подчиненном сервере
обновлялись только через поток подчиненного сервера, этого происходить
не должно. Но если все же такое случилось - значит, имеет место
ошибка; как сообщить о ней, читайте ниже.
SLAVE START
.
SET
SQL_SLAVE_SKIP_COUNTER=1; SLAVE START;
чтобы пропустить запрос, не
использующий функции AUTO_INCREMENT
или LAST_INSERT_ID()
. В противном
случае выполните команды SET SQL_SLAVE_SKIP_COUNTER=2; SLAVE START
.
Причина того, что запросы, использующие функции AUTO_INCREMENT
или
LAST_INSERT_ID()
, обрабатываются по-другому, заключается в том, что
они создают два события в двоичном журнале головного сервера.
grep -i slave /path/to/your-log.err
на
подчиненном сервере. Искать ошибку на головном сервере - не лучшая
идея, поскольку в его журналах находятся лишь системные ошибки общего
характера; если это возможно, он посылает ошибку на подчиненный
сервер, когда что-либо происходит не так, как надо.
Если вы убедились, что пользовательская ошибка здесь ни при чем, однако механизм репликации по-прежнему не работает или работает нестабильно, пришло время начать работу над отчетом об ошибке. Вы должны предоставить нам столько информации, сколько нужно, чтобы отследить ошибку. Пожалуйста, уделите отчету об ошибке нужное количество времени и усилий, чтобы сделать его хорошо. В идеале мы хотели бы иметь контрольный пример в формате, который находится в каталоге `mysql-test/t/rpl*' исходного дерева. Отослав такой контрольный пример, в большинстве случаев можно рассчитывать на получение патча в течение одного-двух дней, хотя, конечно, это время может варьироваться в зависимости от множества факторов.
Еще один хороший способ проинформировать нас об ошибке - написать простую программу с легко конфигурируемыми параметрами соединения для головного и подчиненного серверов, в которой будет продемонстрирована проблема наших систем. Программа может быть написана на Perl или на C, в зависимости от того, какой язык вы знаете лучше.
Подготовив информацию об ошибке одним из двух способов, используйте
утилиту mysqlbug
, чтобы создать отчет об ошибке, и пошлите его по адресу
bugs@lists.mysql.com. Если же вы имеете дело с фантомом - проблемой,
которая имеет место, но вы по какой-либо причине не можете ее
воспроизвести по желанию:
log-slave-updates
и log-bin
-
при этом в журнал будет заноситься информация обо всех обновлениях,
происходящих на подчиненном сервере.
SHOW MASTER STATUS
на головном сервере во время
обнаружения проблемы
SHOW SLAVE STATUS
на головном сервере во время
обнаружения проблемы
mysqlbinlog
. Таким
образом можно находить проблемные запросы, например:
mysqlbinlog -j pos_from_slave_status /path/to/log_from_slave_status | head
Собрав "свидетельства" о проблеме-фантоме, попробуйте сначала организовать их в отдельный контрольный пример. После этого сообщите о проблеме по адресу bugs@lists.mysql.com, описав эту проблему во всех подробностях.
4.10.7 Часто задаваемые вопросы по репликации | Оглавление | 5 Оптимизация в MySQL |