Репликация ведомого останавливается с Last_SQL_Errno: 1032

Я добавил дополнительный ведомый сервер к существующей репликации MySQL. Главный сервер и старый ведомый сервер работают без проблем, но недавно добавленный сервер останавливается с следующей ошибкой:

Last_SQL_Errno: 1032
Last_SQL_Error: Не удалось выполнить событие Update_rows в таблице xxx.email_events; Не удается найти запись в ’email_events’, Код ошибки: 1032; ошибка обработчика HA_ERR_KEY_NOT_FOUND; журнал мастера события mysqld-bin.000410, end_log_pos 368808733

После ремонта он будет работать нормально в течение нескольких часов.

Вопросы

• Можно ли навсегда пропустить Last_SQL_Errno: 1032?
• Есть ли какие-либо проблемы с пропуском этой ошибки?

Вы можете найти код SQL, например, /usr/bin/mysqlbinlog -v --start-position=142743807 --stop-position=147399325 /data/mysql/data/master-bin.000010 > temp.log

Затем сравните различия между базой данных ведомого и мастера в соответствии с temp.log на конкретной позиции.
Затем обновите базу данных ведомого.

Затем пропустите эту строку с помощью mysql -e "stop slave; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; start slave;";

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

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

START SLAVE;

Вы можете установить следующее в my.cnf вашего ведомого:
[mysqld]
slave-skip-errors=1032

Но, как говорится в документации:
Не используйте эту опцию, если вы полностью не понимаете, почему возникают ошибки. Одной из возможных причин этой ошибки может быть “Slave_IO_Running: Yes”, но “Slave_SQL_Running: No”, что означает, что процесс рабского ввода-вывода работает и получает данные от мастера, но не может выполнить их из-за остановившегося процесса Slave_SQL_Running. Для проактивного мониторинга репликации и оповещения об ошибке, отставании или разъединении между мастером и ведомым серверами можно использовать инструмент мониторинга, такой как Monyog.

У меня была такая же проблема, и я выяснил (по консольным журналам “show slave status\G”), что когда я изменял некоторые из моих настроек репликации (в моем случае MASTER_HOST), движок mysql сбрасывал настройку: MASTER_LOG_POS. И после того, как я изменил MASTER_LOG_POS на то, что было в дампе, импортированном на ведомого, все заработало как следует. Возможно, это не ваш случай, но надеюсь, это поможет кому-то.

Вы не можете пропустить ошибку, потому что на сервере реплики запись будет недоступна. Чтобы исправить проблему, выполните следующие шаги:

1. Получите позицию binlog с помощью SHOW SLAVE STATUS\G на сервере реплики, затем получите соответствующий binlog файл с мастера и сохраните его в текстовый файл с помощью следующей команды:

mysqlbinlog –verbose –base64-output=decode-rows
/var/lib/mysql/mysql-bin.000728 > sample.txt

2. Откройте сохраненный текстовый файл с помощью less и найдите позицию binlog. Извлеките весь запрос, выполнив поиск со слэшем (/) за позицией binlog и нажав Enter.

Пример: less sample.txt

3. Проверьте, есть ли в таблице столбец ID. На основе ID извлеките полный запрос INSERT с помощью mysqldump следующим образом:

mysqldump --no-create-info --single-transaction -q bodb managedaccscheme --where "Id=2264;"

Замените Id=2264 на соответствующее условие первичного ключа.

4. Выполните извлеченный запрос INSERT на сервере реплики, следуя этим шагам:

STOP SLAVE; INSERT QUERY; START SLAVE;

Это гарантирует корректную вставку отсутствующей записи на сервере реплики.