Восстановление репликации
Репликация в MySQL - очень удобная возможность, а с появлением GTID эксплуатация стала еще проще. Репликация позволяет держать горячую резервную копию и снижать нагрузку на основной сервер, направляя выборки на реплику. И все работает отлично, пока однажды не случается проблема...
Определение проблемы
Если при воспроизведении бинарных журналов на реплике возникает какая-либо проблема, то репликация останавливается. При этом в журнале вы увидите подобное:
2021-01-01T18:56:50.487205Z 11964570 [Warning] Slave: Can't find record in 'mytable' Error_code: 1032,
2021-01-01T18:56:50.487173Z 11964570 [ERROR] Slave SQL for channel 'master': Could not execute Delete_rows event on table mydb.mytable; Can't find record in 'mytable', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.002599, end_log_pos 866963173, Error_code: 1032
2021-01-01T18:56:50.487213Z 11964570 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.002599' position 866962354
Произойти подобная ситуация может например при изменении данных на реплике напрямую.
Восстановление
Самый простой способ восстановления работоспособности реплики - полное восстановление из резервной копии. Но это не всегда целесообразно по многим причинам - например, значительный объем данных и время, необходимое для восстановления.
Другой способ - откорректировать данные на реплике, чтобы появилась возможность воспроизвести действия из бинарного журнала без ошибок.
Для определения инструкций, которые не могут быть выполнены, на основном сервере смотрим события в журнале:
Значение параметра --start-position берем из сообщений в журнале реплики, а значение --stop-position определяем опытным путем.
После изучения событий и корректировки данных на реплике, запускаем репликацию:
Ссылки
Last updated
Was this helpful?