保险查询平台seo的优点和缺点

现象描述

传统模式的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即可