Last_IO_Error: Got fatal error 1236 from master when reading data from binary log

很久不关注MHA,最近看到已经升级到 MHA 0.58,开始支持MySQL的GTID。

GTID对于MySQL复制而言,已经是一场革命。复制变得更加简单,创建复制从库时无需指定主库的file和position,新引入的 master_auto_position=1 即可自动比对主从库之间的binlog差异,自动进行同步,无疑大大节省了DBA操作成本。

GTID的引入,对于DBA而言增加了学习成本。不过,这是值得的。多测试、多踩几个坑,对后续基于GTID的复制管理会更有把握。

 

在测试基于GTID的复制failover时,遇到了 “Last_IO_Error: Got fatal error 1236 from master when reading data from binary log”问题。在网上搜寻到了解决办法,但是无法再次复现该问题,很苦恼无法深入研究报错原因。

问题描述

 

解决办法

主库查看Executed_Gtid_Set值,并记录下来

从库根据主库的 Executed_Gtid_Set,设置从库的gtid_purged

关于gtid_purged

在MySQL官方文档中,有一段描述了设置 gtid_purged的场景。

使用gtid_purged排除事务。如果采用快照方式创建备库,那么当主库产生的binlog传递到从库并应用时,就会报错。通常,采用插入空事务来解决该问题。

这里使用的方式是,记录主库的gtid_executed值,然后在从库将该值写入gtid_purged

 

参考:

https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-failover.html    #Excluding transactions with gtid_purged

https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-failover.html    #Injecting empty transactions

https://aliang.org/MySQL/Last_IO_Error.html

23 total views, 1 views today

发表评论

电子邮件地址不会被公开。 必填项已用*标注