Почему репликация MySQL прерывается на отсутствующей строке, а затем продолжается после "START SLAVE"?
Название немного сбивает с толку, но я не могу придумать лучшего.
То, что у меня есть, это простая ванильная репликация MySQL, иногда с ошибкой ведомого, с этой ошибкой: Error 'Can't find record in 'my_tbl'' on query. Default database: 'my_db'. Query: 'UPDATE my_tbl SET ... WHERE ...' (столбцы опущены для ясности).
Я предполагаю, что эта ошибка означает, что подчиненный поток sql выполнил это обновление и получил 0 rows affected, Это было не то, что ожидалось при сравнении результатов 1 rows affected из релейного журнала, таким образом генерируя ошибку.
При запуске этой же транзакции обновления вручную она работает. То же самое при беге START SLAVE - он просто начинает работать и возвращается к нормальной жизни.
Это не имеет смысла для меня вообще - если все, что нужно, это "попытка", чтобы исправить это, как это могло произойти в первую очередь? Все выполняется сериализованным способом, и больше ничего не записывает на подчиненный сервер MySQL.
Может кто-нибудь дать объяснение?
Некоторые технические особенности - это смешанная настройка репликации с 5.5.7-rc до 5.5.12.
2 ответа
Я обнаружил причину этой проблемы - событие, которое было запущено как на ведущем, так и на ведомом устройствах. Решение простое - alter event event_name disable on slave; Что нужно иметь в виду при создании раба с mysqldump,
Существует ошибка MySQL #60091, связанная с репликацией таблиц InnoDB, которая может соответствовать вашим условиям - посмотрите на нее, проверьте, не затронута ли ваша версия, и обновите ее, чтобы проверить, помогает ли это.
Другим объяснением этого может быть неупорядоченное исполнение - когда UPDATE my_tbl SET ... WHERE ... выполняется, условие WHERE еще не может быть выполнено ни одной строкой, поскольку оно еще не выполнено. Хотя я не могу придумать причину этого - об этом можно было бы спросить в списках рассылки MySQL.