Skip to content


Ошибка mysql: Got fatal error 1236 from master

После аварийного рестарта mysql-сервера, исполняющего роль master-а, на slave-е вылезла вот такая проблемка:

[ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from position > file size', Error_code: 1236

Ну и процесс репликации, естественно, остановился.

Как можно догадаться из сообщения об ошибке, slave захотел выполнить команды из такого места бинлога, которого на мастере не оказалось после рестарта последнего (наверное, потому, что часть бинлога не успела записаться на диск мастера за мгновение до того, как он был перезагружен по питанию).

Смотрим позицию, до которой дошел slave:

  1. [slave]$ echo "show slave status \G" | mysql | grep -E "[[:space:]]Master_Log_File|Read_Master_Log_Pos"
  2.   Master_Log_File: s10-bin.000253
  3.   Exec_Master_Log_Pos: 783374391

Смотрим последнюю позицию, которая реально присутствует в этом бинлоге мастера:

  1. [master]$ mysqlbinlog s10-bin.000253 | tail -n 9
  2. /*!*/;
  3. # at 783367615
  4. #150704 18:12:45 server id 62 end_log_pos 783367646 CRC32 0x2be04f67 Xid = 22088173
  5. COMMIT/*!*/;
  6. DELIMITER ;
  7. # End of log file
  8. ROLLBACK /* added by mysqlbinlog */;
  9. /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
  10. /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

И видим, что последняя позиция - 783367646. В то время как slave пытается исполнить позицию 783374391, которая, очевидно, дальше, чем 783367646. Вывод – надо "отмотать" slave немного назад:

  1. [slave] mysql> stop slave;
  2. [slave] mysql> change master to master_log_pos=783367646;
  3. [slave] mysql> start slave;

В логе видим:

  1. [Note] 'CHANGE MASTER TO executed'. Previous state master_host='10.10.10.10', master_port= 3306, master_log_file='s10-bin.000253', master_log_pos=783374391, master_bind=''. New state master_host='10.10.10.10', master_port= 3306, master_log_file='s10-bin.000253', master_log_pos=783367646, master_bind=''.
  2. [Note] Slave I/O thread: connected to master 'repl@10.10.10.10:3306',replication started in log 's10-bin.000253' at position 783367646

Ну и далее show slave status нам говорит, что slave начал догонять master.

Happy end.

Правильные ролеты в Днепропетровске здесь .

Размещено в категории Howto. Теги: , .

Комментариев: 6

Чтобы быть всегда в курсе здесь происходящего, Вы можете подписаться на RSS feed для комментариев на эту заметку.

  1. buggy said

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

  2. Admin said

    buggy, в данном случае не будет она записана повторно. Потому что на мастере кусок бинлога n потерялся с конца. После ребута мастер начинает новый бинлог n+1. Слейв в старом бинлоге выполнит тольку одну позицию 783367646 и перескочит на следующий бинлог, данных из которого он еще не выполнял.

    То есть слейв выполнит только одну 783367646, а не разницу между 783367646 и 783374391.

  3. buggy said

    Admin, спасибо. Если лог действительно был поврежден и записи потерялись, тогда да.

  4. Кстати, если тип репликации row-based (по умолчанию mixed), то чтобы увидеть SQL-операторы, нужно для mysqlbinlog добавить опции --base64-output=DECODE-ROWS --verbose

  5. Заметил прикольную фичу - если на слейве поменять тип репликации (например, добавив в my.cnf binlog_format = row), то мастер автоматически подстраивается, меняя у себя тоже на тот же тип.

  6. Василий said

    Петровский, да реально так и есть.

Some HTML is OK

(required)

(required, but never shared)

, или ответить через trackback.

Страница 1 из 11