django做的网站举例,电子宣传册制作app,济南城之运维网络科技,许昌做网站公司哪家专业问题最近年底#xff0c;大家的数据库经常跑批量大事务#xff0c;会发现复制突然断开#xff0c;报错“心跳与本地信息不兼容”#xff1a;会是什么原因#xff1f;实验我们先来复现一下#xff0c;再进行分析。宽油#xff0c;做一对主从数据库#xff1a;我们先造一…问题最近年底大家的数据库经常跑批量大事务会发现复制突然断开报错“心跳与本地信息不兼容”会是什么原因实验我们先来复现一下再进行分析。宽油做一对主从数据库我们先造一个 500M 的空文件下一步有用再制造一张大表这里用到了之前的造表法不同的是使用了一个 longblob 字段让少数的几行记录就能占用很大的 binlog 空间方便我们后面做实验。这里的 longblob 字段用到了上一步我们做的空文件这样我们获得了一个行数较少但体积很大的表。现在起两个会话一个事务造表 t2一个事务造表 t3并同时提交操作以下举例其中一个事务这样就获得了一个超大的 binlog一共 32G前 16G 是一个事务后 16G 是另一个事务。小贴士一个事务超过 binlog 的限制大小(最大 1G)就会在事务后直接切换到新的 binlog。在同一个 binlog 中我们想让一个超大事务后再记录一个事务所以让两个事务同时提交放在同一个提交组中。查看一下 master 上的 GTID最后两个事务分别是 25 和 26下面登录到 slave上开始表演我们先重置 GTID 和复制状态然后骗 slave 说它已经接到了 1-25 事务要从 26 号事务开始传输也就是从 32G binlog 的中间位置开始传输。然后开始复制的 IO 线程过十几秒就可以看到复制报错查看 Error log和我们想要复现的报错一样。下面我们来看一下原理这个复现中有几个要素从报错得知报错与心跳有关复制线必须配置复制心跳。一个 binlog 中包含两个事务第一个事务超过 4G。(我们在复现中为了方便将第二个事务也做成了大事务这一点不是必须的)。从大事务后的位置开始进行 binlog 复制传输。我们用 tcpdump 抓个包用 wireshark 解开抓包找到有问题的包(这里怎么找我们分析后会有方法)我们来分析一下包结构这里我们将包的内容誊写下来方便大家阅读首先阅读https://dev.mysql.com/doc/internals/en/mysql-packet.html了解 MySQL 的客户端网络包头结构将我们的包对应上去其后的一位 00是 MySQL 的 command type(https://dev.mysql.com/doc/internals/en/command-phase.html)在此没有意义我们将其忽略再继续阅读https://dev.mysql.com/doc/internals/en/event-header-fields.html了解 binlog event 的头结构如下将我们的包对应上去接下来是个字符串明显是一个 binlog 的名字最后四个字节(下图中用黄色标注)是 checksum至此我们完成了一个心跳包的解析并没有看出严重的问题不妨往前再找一个心跳包看看规律我将重点在图中标注就是 next_position 的位置在这个包中为 0xfa000557而其下一个包中为 0x19400583明显后面的 next_position 比前面的 next_position 小这个不符合常理。而 MySQL 的报错 heartbeat is not compatible with local info也是在报这个问题心跳包中的 position 不应比当前的 position 小。那是什么导致了这个问题我们注意到 next_position 的字段长只有 4 字节也就是说该字段最大值为 2 的 31 次方也就是 4G当前 binlog 的位置大于 4G 时该字段就会溢出。也就是说之前我们看到的位置 0x19400583实际丢掉了最高的一位应当是 0x119400583。这也就导致了 binlog event 传输时next_position 突然会变小心跳机制会检查到这个变化产生报错。那我们怎么解决这个问题目前可能的方法有以下两种别用大事务别用大事务别用大事务。数据库系统本来就不是为大事务设计的总会踩到不少坑。停用心跳机制这个问题并不是心跳机制带来的问题每个 binlog event 都会带有这个包头。只是心跳机制让问题暴露了出来。如果关掉提出问题的心跳机制那么复制对于网络故障就会不敏感导致更大的问题。这种方式不推荐使用。复盘因为文章比较长我们对逻辑进行一下复盘我们通过抓包分析知道 binlog 传输的网络包里next_position 只有 4 个字节最大数值为 4G。我们在 master 上做了一个超过 4G 的大事务让 slave 从这个大事务后开始传输。此时 master 会发送一个心跳包。心跳包中的 next_position 是 log event 在 binlog 位置由于这个位置大于 4G会被截断导致 next_position 比实际的小。slave 收到心跳包进行检测时发现 next_position 比实际的小进行报错。以上只是一种容易复现问题的场景。实际使用中master 在一段时间不发送数据包后或者特殊触发条件都会发送心跳包。对于一主多从的环境每条复制链路的心跳是单独发送的也就会导致多个 slave 的表现会有所不同有的 slave 会触发报错有的 slave 由于 master 没发送心跳包而不会触发报错。最后送上几个小贴士1)我们如何快速找到有问题的包报错信息里已经标志了出错的 log position 是 423626115转换成 16 进制为0x19400583找到由此数据的包即可。2)一位一位读包太麻烦了怎么办好办先找到 server_id 的十六进制形式以此为基准往后推定位数就可以。比如我们的 server_id 是 19327很容易找到基准位置。3)报错里有一段乱码是啥最后这四位是 MySQL 程序有缺陷将包中的 checksum 作为文件名输出了对程序逻辑没有影响。0x11 是 17对应 ASCII 码 device control 1 character键盘表达形式是 ctrl Q打印形式就是 ^Q。本文相关的 MySQL 的 bug 列表https://bugs.mysql.com/bug.php?id101948https://bugs.mysql.com/bug.php?id101955关于 MySQL 的技术内容你们还有什么想知道的吗赶紧****留言告诉小编吧
