Ошибка репликации MySQL (1062) - PullRequest
3 голосов
/ 12 января 2011

Я новичок в MySQL, и после долгого поиска я могу настроить репликацию master-slave на основе ROW.Я думал, что это будет безопасно, и мне не пришлось бы перепроверять это снова и снова.

Но сегодня, когда я сделал SHOW SLAVE STATUS; на подчиненном устройстве, я обнаружил, что следующее

не может быть выполненоСобытие Write_rows для таблицы mydatabasename.atable;Дублирующая запись «174465» для ключа «ПЕРВИЧНЫЙ», код ошибки: 1062;ошибка обработчика HA_ERR_FOUND_DUPP_KEY;основной журнал события mysql-bin.000004, end_log_pos 60121977

Может кто-нибудь сказать мне, как это может произойти, когда мастер не имеет такой ошибки и схема на обоих серверах одинакова, тогда как это может произойти.И как это исправить, чтобы это снова заработало, и как это предотвратить в будущем.

Пожалуйста, дайте мне знать, что еще неожиданно следует ожидать, кроме этого.

Ответы [ 2 ]

6 голосов
/ 17 января 2011

Это никогда не произойдет с мастером, почему?

Ряд SQL реплицируется с мастера,
, если запись уже существует в мастере, mysql отклоняется на мастере

но на ведомом, если происходит сбой и позиция репликации не переходит к следующему SQL (он просто остановился)

Причина?

Запрос вставки этогозапись записывается непосредственно в ведомое устройство без использования репликации от ведущего устройства

Как исправить?

Пропустить ошибку на ведомом устройстве, как

SET GLOBAL sql_slave_skip_counter = N;

подробности - http://dev.mysql.com/doc/refman/5.0/en/set-global-sql-slave-skip-counter.html

Или удалите дублирующую запись на ведомом устройстве, возобновите ведомое снова (пусть репликация сделает вставку)

В худшем сценарии вам потребовалось бы повторно выполнить настройку сновадля обеспечения целостности данных на ведомом устройстве.

Как предотвратить?

Проверьте уровень приложения, убедитесь, что нет записи непосредственно в ведомое устройство
Это включает в себя, как вы подключаетесь к mysqlв командной строке

Split MySQL пользователь, который может сделать записьe и read,
Итак, ваше приложение должно использовать пользователя read (master и slave), когда не требуется запись.
Использовать пользователя write (только master) для действий, требующих записи в базу данных.

2 голосов
/ 15 января 2014

счетчик пропусков не всегда является жизнеспособным решением, вы пропускаете записи, но это может повлиять на дальнейшие записи.

Ниже приводятся подробные сведения о том, почему счетчик пропусков sql slave плох.

http://www.mysqlperformanceblog.com/2013/07/23/another-reason-why-sql_slave_skip_counter-is-bad-in-mysql/

...