Сломанная репликация master-master и восстановление

Question

[s1dney]

Есть несколько баз с репликацией master<->master, при этом на запись работает только один из мастеров, а второй включается только если первый в дауне.
Периодически репликация ломается и на одном из серверов я получаю такое:
Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
Лог-файл куда-то теряется, причины не понимаю.

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

Answer 1

[s1dney]

Вот тут хорошо написано почему и как: dev.kafol.net/2011/09/mysql-error-1236-client-requested.html
На всякий случай приведу тут цитату:

Causes:
Master server has crashed and the binlog cache has not been flushed to disk. Slave has recieved a new position, did not recieve data, and data gets lost in a crash (however it might have been written to table, but not in binlog).

Solution:
Use this CHANGE MASTER statement on the slave.
CHANGE MASTER TO MASTER_LOG_FILE=[NEXT FILE], MASTER_LOG_POS=4;
SLAVE START;

in my case that would be

CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000034', MASTER_LOG_POS=4;
SLAVE START;

I don't know why the master log position needs to be 4 for the new file.

What happens:
When the master server restarts it logs binary changes to a new binlog file, so that we minimize data loss by skipping to the next file (everything from the previous file was written already).

Prevention:
Add this line to my.cnf:

sync_binlog = 1

With this setting the master server flushes cache in the binlog after every write, so that in case of a crash you can lose one statement at most.