MySQL Replication 遇到 error 1236 就有点麻烦了~ 通常都是 binlog 出问题造成的~ (Master 或 Slave 的 binlog 坏掉都有可能造成此错误)

通常遇到这个状况, 都是 Slave 的 binlog 坏掉, 就 Slave DB 的资料重倒来解决, 但是此次遇到是 Master 的 binlog 坏掉, 就有点苦了~

错误讯息如下:

MySQL Replication 遇到 Got fatal error 1236 from master 修复

错误讯息如下: (已经把不必要得删除)

?: Debian / Ubuntu Linux 预设 MySQL data path: /var/lib/mysql, 所以下述 binlog 可於此路径寻找.

Slave binlog 坏掉的解法

1.一般常见是 Slave binlog 坏掉, 所以都会先去 Slave 找 mysql-bin.003583 档案.
2.再把 mysql-bin.003583 的资料用 mysqlbinlog dump 出来, 指到下一个 position 即可.
3.Slave: ls /var/lib/mysql/mysql-bin.003583 # not found.
4.Slave 不存在档案, 才发现到坏的是 Master.
Master binlog 坏掉的解法

■最苦的状况是 Master 的 binlog 坏掉了, 所以所有 Slave 都死光光. XD
此时可以考虑几种作法:

1.全部 Slave 重倒 (最保险, no data lost)
2.先让 Replication 可以启动, 再来 重倒 / sync 一定需要同步的资料即可. (Cache ... 那种就可以不用理他)
下面是?裼玫诙?肿鞣?

1.mysql> STOP SLAVE;
2.mysql> CHANGE MASTER TO master_log_file = 'mysql-bin.003584', master_log_pos = 0; # 先指到下一个 binlog 档, pos 指 0 或 4, 都是一样意思.
3.mysql> START SLAVE;
4.mysql> SHOW SLAVE STATUS G # 於此应该就恢复了.
5.然后在对重要的 Table 用 pt-table-sync 来补一补即可. (apt-get install percona-toolkit)

--转自