бинлога и имя файла.
2. Переливаю базу, делаю START SLAVE.
3. Он падает с ошибкой инсерта строки в таблице.
4. До этого я думал, что дамп не консистентный, но это не так. Остановил специально "трафик в таблицу", проверил, всё льётся норм.
5. Лезу в таблицу, проверяю наличие id = 34928485 по сообщению слейва (duplicate entry). Он есть и в мастере, и в слейве
6. Захожу в performance_schema.replication_applier_status_by_worker, смотрю по нужному каналу статус.
7. Обращаю внимание на APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP
8. И там значится timestamp 10-дневной давности. Чему соответствует created_at в нужной мне таблице.
Вывод: слейв где-то хранит у себя последнюю позицию как 10-дневной давности? Где он это хранит, и как сбросить такое? RESET SLAVE FOR CHANNEL, RESET MASTER не помогают. Он всё равно хочет применить те транзакции 10-дневной давности.
10 дней назад перешёл с auto_position 1 на 0?
Вот не помню, переходил ли. То есть он где-то оставил эту позицию, и хранит её у себя? Я читал где-то и как-то удалял полностью инфу о канале репликации, найти не могу пока.
Обсуждают сегодня