Spec-Zone .ru
спецификации, руководства, описания, API

16.4.5. Как Сообщить об Ошибках Репликации или проблемах

Когда Вы решили, что нет никакой пользовательской ошибки, включенной, и репликация все еще, или не работает вообще или является нестабильной, пора отправить нам отчет об ошибках. Мы должны получить такую большую информацию насколько возможно от Вас, чтобы быть в состоянии разыскать ошибку. Пожалуйста, проведите некоторое время и усилие в подготовке хорошего отчета об ошибках.

Если у Вас есть повторимый прецедент, который демонстрирует ошибку, пожалуйста, введите ее в нашу базу данных ошибок, используя инструкции, данные в Разделе 1.7, "Как Сообщить об Ошибках или проблемах". Если у Вас есть "фантомная" проблема (тот, который невозможно копировать по желанию), используйте следующую процедуру:

  1. Проверьте, что никакая пользовательская ошибка не включается. Например, если Вы обновляете ведомое устройство за пределами ведомого потока, данные выходят из синхронии, и у Вас могут быть нарушения уникального ключа на обновлениях. В этом случае ведомый поток останавливается и ожидает Вас, чтобы очистить таблицы вручную, чтобы принести им в синхронию. Это не проблема репликации. Это - проблема внешней репликации порождения интерференции перестать работать.

  2. Выполните ведомое устройство с --log-slave-updates и --log-bin опции. Эти опции заставляют ведомое устройство регистрировать обновления, которые оно получает от ведущего устройства в его собственные двоичные журналы.

  3. Сохраните все доказательство прежде, чем сбросить состояние репликации. Если у нас нет никакой информации или только поверхностной информации, это становится трудным или невозможным для нас разыскать проблему. Доказательства, которые следует собрать:

    • Все двоичные файлы журнала от ведущего устройства

    • Все двоичные файлы журнала от ведомого устройства

    • Вывод SHOW MASTER STATUS от ведущего устройства в то время, когда Вы обнаружили проблему

    • Вывод SHOW SLAVE STATUS от ведомого устройства в то время, когда Вы обнаружили проблему

    • Журналы ошибок от ведущего устройства и ведомого устройства

  4. Используйте mysqlbinlog, чтобы исследовать двоичные журналы. Следующее должно быть полезным, чтобы найти проблемный оператор. log_file и log_pos Master_Log_File и Read_Master_Log_Pos значения от SHOW SLAVE STATUS.

    shell> mysqlbinlog --start-position=log_pos log_file
                        | head

После того, как Вы собрали доказательства для проблемы, попытайтесь изолировать это как отдельный прецедент сначала. Затем введите проблему с такой большой информацией насколько возможно в нашу базу данных ошибок, используя инструкции в Разделе 1.7, "Как Сообщить об Ошибках или проблемах".