Доброго времени суток, господа и дамы.

Есть два MySQL сервера, с мастера на слэйв настроена репликация.

Настройки на мастере, касающиеся репликации:


(если выставить более 5 дней - есть вероятность забить весь диск)

Слэйв в очередной раз остановил репликацию из-за ошибки - это нечасто, но происходит. Обычно я замечаю, что репликация остановилась, устраняю проблему (как правило, достаточно бывает просто пропустить строку в логе, которая вызывала проблему - во всех моих случаях это не приводило к рассинхронизации) и запускаю репликацию с момента остановки:


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

Слэйв продолжает вычитывать бинарные логи с мастера и складывает их в свои логи.

Вопрос: существует ли возможность пропустить проблемную строку и продолжить репликацию с тех бинарных логов, которые слэйв вычитал с мастера и сохранил у себя?

Базы на мастере достаточно объемные, полный бэкап (чтобы потом с него восстановить базы на слэйве) займет несколько часов - такой длительный простой крайне нежелателен.

Заранее спасибо за ответы.

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

Остановилась только часть репликации (запись в базу). Бинарные логи с момента остановки записи продолжали вычитываться (и продолжают сейчас) и сохраняться на слэйве. Т.е. по большому счёту те бинарные логи, которые уже удалены с мастера, на слэйве присутствуют...

Alex_Ustinovbelikoviv...
В этот раз остановка произошла более 5 дней назад
...
Т.е. по большому счёту те бинарные логи, которые уже удалены с мастера, на слэйве присутствуют...ПРОПУСК более в пять дней...слайв был заморожен и не получал ничего, у вас дырка будет по любому
Наверное, я не очень точно выразился.
Вот статус слэйва:


Т.е. вычитывание бинарных логов с мастера продолжается - значение Read_Master_Log_Pos увеличивается, значение Master_Log_File - текущий файл на мастере. И, очевидно, значение Slave_IO_Running как раз подтверждает, что вычитывание логов продолжается.

А вот Slave_SQL_Running как раз говорит, что прекратилась _обработка_ вычитанных логов.

Вот как бы так "извернуться", чтобы пропустить строку, которая слэйву "не понравилась", и продолжить обработку ранее вычитанных логов? Все файлы, начиная с указанного в Relay_Log_File, на слэйве присутствуют.

Alex_Ustinovкакой давности у вас файл relay
Relay_Log_File: mysqld-relay-bin.003675
он по идее и должен содержать что последнее забрано с binloga
Нет, судя по дате - в нем последнее, что реплицировано в базу.
А самый свежий - mysqld-relay-bin.003843 (с текущим временем), и все файлы между 3675 и 3843 также присутствуют.

javajdbc...belikoviv -- вы как партизан на допросе -- надо
10 раз спрашивать какая ошибка была...
в статусе есть и номер ошибки и текст ошибки и даже квери...

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

А вопрос был другой - можно ли использовать "SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;", если на мастере более старые бинарные логи уже удалились.

Другими словами - если я сделаю STOP и START - репликация начнётся из тех файлов, которые уже вычитаны с мастера на слэйв, или слэйв попытается по новой начать вычитывать логи с мастера.

javajdbcесли ошибка одноразовая то попробуйте:
>> STOP SLAVE;
>> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
>> START SLAVE;

Вероятнее всего - не одноразовая, пропустить придётся и эту запись, и, возможно, ещё несколько штук, относящихся к той же строке в таблице. Но в данной конкретной ситуации это не критично.

javajdbcтакой вариант легче чем настройка сервера.

Учтите что репликацию будет уже НЕ идентичной источнику.
Да, я это прекрасно понимаю.
Повторюсь, в данной конкретной ситуации это не критично.

Alex_Ustinov,

1. Спасибо, сейчас буду пробовать.
2. Не, для этого моего опыта достаточно. Иначе я бы сразу привёл информацию об ошибке.
3. Да, я этим пользовался. Но я (ошибочно) считал, что после STOP/START слэйв начинает по новой вычитывать все бинлоги с мастера.
4. Нет, пропускать ошибки автоматом я не хочу. Тот же код ошибки может возникнуть на другой таблице в другой базе - там, где пропуск одной строки репликации может быть критичным.

Всем спасибо за ответы - всё получилось.
Остановил репликацию, пропустил одну строку, запустил репликацию.
Процесс продолжился из ранее вычитанных с мастера локальных бинлогов.

P.S. Очень странно видеть в статусе в Relay_Master_Log_File имена уже несуществующих на мастере файлов. Именно этот момент и сбивал меня с толку (т.е. я считал, что бинлоги с мастера _перечитываются_ после рестарта репликации) в предыдущие разы, когдя я таким же образом пропускал проблемные строчки.