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

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

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

Проверьте, что никакая пользовательская ошибка не включается. Например, если Вы обновляете ведомое устройство за пределами ведомого потока, данные выходят из синхронии, и у Вас могут быть нарушения уникального ключа на обновлениях. В этом случае ведомый поток останавливается и ожидает Вас, чтобы очистить таблицы вручную, чтобы принести им в синхронию. Это не проблема репликации. Это - проблема внешней репликации порождения интерференции перестать работать.
Выполните ведомое устройство с --log-slave-updates и --log-bin опции. Эти опции заставляют ведомое устройство регистрировать обновления, которые оно получает от ведущего устройства в его собственные двоичные журналы.
Сохраните все доказательство прежде, чем сбросить состояние репликации. Если у нас нет никакой информации или только поверхностной информации, это становится трудным или невозможным для нас разыскать проблему. Доказательства, которые следует собрать:
- Все двоичные файлы журнала от ведущего устройства
- Все двоичные файлы журнала от ведомого устройства
- Вывод SHOW MASTER STATUS от ведущего устройства в то время, когда Вы обнаружили проблему
- Вывод SHOW SLAVE STATUS от ведомого устройства в то время, когда Вы обнаружили проблему
- Журналы ошибок от ведущего устройства и ведомого устройства
Используйте 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, "Как Сообщить об Ошибках или проблемах".