MySQL: не работает Slave после ошибок на Master

Т.е. вы хотите перетащить проблемы на Slave как можно скорее? :)

Не, имелось ввиду, что сделал я "repair table" на Master, на Master всё стало замечательно. Но репликация не возобновилась, т.к. на Slave пишется ошибка. Вот нет ли каких-то способов, не перетаскивая каждый раз базу с Master на Slave, возобновлять репликацию после ошибки на Master?

Так что, ошибку подчиненного сервера не будем показывать?

Если источник остановить НЕаварийно, то потом все нормально запускается?

В порядке телепатической помощи, можете попробовать sync_binlog=1 на сервере-источнике. Но так как может начать работать медленнее, на практике выгоднее исключить причины аварий на источнике, чем бороться с их последствиями.

Есть такая вещь. NDB кластер.

Не для всех подходит.

Покажите ошибку, по дефолту реплика должна сама подыматься, если вы конечно не начинаете писать в слейв при падении.

Телепатически могу предположить посмотреть в сторону опции slave-skip-errors, где можно указывать какие ошибки пропускать

ТС, у меня та же история возникает только база есть в несколько десятков гиг .... и репликация там master-master.... перетаскиваем базу при падении, уже очень сильно оптимизировали сам процесс , например репликация идет по отдельному внутреннему линку между серверами, а так же оба сервера поставили на собственные упсы. что бы падали реже в случаях проблем с генератором или общим питанием. Тут пожалуй Андрейка в правильную сторону говорит... но кому подходит кому нет ... дело такое....

Проблема заключается по сути в том, что на момент остановки SLAVE , останавливается счетчик который меряет сдвиги\изменения, восстановить репликацию можно только с того места откуда она завершилась, а для этого надо четко дать понять SQL где завершена репликация.... соответственно если у вас стал SLAVE , то мастер еще продолжает принимать данные и уже в следующую секунду времени после падения слейва мастер обладает в базе данными которые на слейв не попадают, сдвигается счетчик и репликация без синхронизации базы просто не возможна.

Что касается совета о slave-skip-errors, во первых для данного случая мало вероятно что поможет, хотя еще не совсем ясна ошибка которая у ТС-а на слейве возникает, а в целом путем такой манипуляции мне кажется еще легче будет достигнуть рассинхронизации баз.

Можно ставить 1 мастер и 2 слейва, при этом разводить запросы ввода на мастер а вывода на слейвы, при этом потеря актуальности одного из слейвов не скажется на общей схеме, можно будет спокойно реплицировать без ущерба для проекта.

Что-то не то вы пишете.

Во-первых, у ТС другая менее рисковая конфигурация.

Во-вторых, эти ваши представления о позициях неправильны. В вашем случае, на каждом сервере есть две разных позиции Read_Master_Log_Pos - то, что прочитано и Relay_Log_Pos - что применено. Они независимы и не могут перепутаться.

А вот в сам локальный файл лога при внезапной перезагрузке может не быть дописана вся информация. Именно тут и может возникнуть нестыковка. Для гарантированной фиксации изменений в файл лога служит настройка sync_binlog=1. Как я уже отмечал выше, не все так просто с ней. В документации описаны случаи когда даже она не помогает.

Так а что я не верно сказал, в моем случае Read_Master_Log_Pos ессесно с двух сторон так как мастер-мастер, а у ТС-а всего с одной стороны..... так вот если идет прием данных на мастер, рядом идет прием на слейв (репликация), слейв например упал, мастер продолжает принимать данные и менять этот самый счетчик, соответственно если через 20 минут слейв встал он уже не нейдет позицию откуда принимать данные. Или опять что-то не так? Я как бы не MYSQL гуру, но пользуюсь не первый день репликацией, может что-то и напутал но не со зла :D

Ну почему не найдет ? Загрузится и постепенно догонит. Обычная репликация mysql - асинхронна. Никто никого не ждет.

Пока слейв не догонит, использовать его в хостинговом кластере, или где там он у вас, обычно нельзя.

Или это вы описываете ситуацию когда логи старше 20 минут удаляются ?

Так это еще надо постараться настроить. expire_logs_days вообще в днях исчисляется и дробные значения не принимает.

Видимо я таки применяю на "свою схему", у меня просто не получается стартовать и догонять ввиду master-master, мне же надо с двух сторон зафиксировать значения, в обе стороны передается, а с slave-master выходит, что можно ребутнуть слейв и потом никаких последствий типа? поднялся SQL и начал "догонять мастера"? Тогда теоретически в схеме ТС-а вообще проблем быть не должно.... ну упал мастер .... соответственно остановилась репликация на слейве... мастер встал и все побежало, на слейве то ничего не менялось...

ТС, а что за ошибка у вас вообще, не вижу что бы вы её цитировали.