mysql传统主从模式下，主从中断接续
现象描述
传统模式的mysql主从。
Slave因为大事务延迟巨大。从库重启前的记录位点在binlog：552，pos：471157766
Relaylog：629，pos：496188584
从库重启后binlog倒退到221
Relaylog反而到了1653
故障判断
IO thread 为no，而SQL thread为yes。
通过relog index也确认1633是最新的relaylog。
判断：从库在重启时relay自动应用到了最新，但是在获取主库的binlog位置时失败。
因为是传统模式的m-s主从，需要手工找出接续的位点。
解决办法
分析relaylog 1653发现其是空事务
遂分析relaylog1652最后部分
可以看到end_log_pos是488269909
在主库上488269909的binlog file我们通过大概的分析获得。这里分析得到是binlog000552
| CHANGE MASTER TO MASTER_HOST='master_host_name', -- 主服务器的地址 MASTER_USER='replication_user', -- 用于复制的用户 MASTER_PASSWORD='replication_password', -- 复制用户的密码 MASTER_LOG_FILE='mysql-bin.000552', -- 二进制日志文件名 MASTER_LOG_POS=488269909; -- 二进制日志中的位置 |
重启slave
START SLAVE;
IO thread继续成功，但是有数据不一致问题。从库还是重建了。
试错附录
Error 1236 * log event entry exceed max_allocated_packet
主库master侧的max_allocated_packet太小。估计和解析binlog位置的sql太大有关
Error 1236 * bogus data in log event
在指定master log的pos的时候尝试使用过488269909+1，会导致以下报错
然后再去使用以上的最后位置的488269948就会得到上一张截图的错误。
分析这里是指定接续位点。这里不需要想当然的+1计算。这个pos不是scn这种逻辑值，是直接的物理bytes位置。直接使用最后relaylog中的最后的end_pos：488269948即可