Привет. 2 сервера MySql 5.7.35 - master и slave. В

конфигах дополнительно прописан expire_logs_days = 7 (как я вычитал в мануале скуля данный параметр определяет сколько времени будет храниться бинлог со всеми изменениями мастера). Ок, сервер с репликой уходит в даун на 10 минут. Стартует, show slave status с ошибкой Could not execute Update_rows event on table XXX. stop slave, reset slave, забираю новый master status с мастера, привязываю реплику, старт и таже самая ошибка. Без использования sql_slave_skip_counter как Вы чините подобное?
Диагностировать ошибку репликации по сообщению почти нереально, но мб есть какой-то совет. Спасибо.

берешь из slave status файл/позицию из релей лога. парсишь файл. находишь на чем падает. дальше смотришь на ошибку и на те данные что лежат в таблице (этой или родительской, если проблема с fk). меняешь данные. стартуешь реплику. будьте внимательны, если у вас транзакция состоит из нескольких запросов. будьте особенно внимательны если у вас master-master, так как все ваши изменения пойдут в бинлог и будут применены на другом сервере. то, что сделали вы мне не совсем понятно. если вы ресетнули слейв и взяли какую-то другую позицию с мастера, то у вас реплика неконсистента, если хотя бы одна транзакция была применена после выполнения change master to/start slave. тут я могу предложить посмотреть логи и убедиться, что ничего не накатилось. если не накатилось, то ищите там же первую позицию на которой все свалилось, делайте change master/start slave и чините как описано ранее. если же что-то накатилось, то у вас есть два пути полный ребилд реплики или опять же change master to/start slave и чинить реплику, а потом уже pt-table-checksum/sync, чтобы убрать несоответствия. если вы не будете ребилдить реплику с нуля, то я бы порекомендовал бы в любом случае проверить консистентность. и если вам важна консистентность данных не применяйте skip_slave_counter. ну и в финале совет читать доки прежде чем что-то запускать/менять.

угу, будет полный ребилд реплики. спс.