MySQL：主从HASH SCAN算法可能导致从库数据错误

发布时间：2025-11-04 23:36:54 来源：技术快报 作者：IT科技

本文主要以hash scan全表为基础进行分析，库数而不涉及到hash scan索引，据错实际上都会遇到这个问题。库数本文主要描述的据错是update event，delete event也是库数一样的，测试包含8022，据错8026，库数8028均包含这个问题。据错

约定：bi为update row event的库数before image

一、问题描述

这里简单看一下报错的据错我们直接用metalink 上的文章来看，实际上作为做oracle的库数老人，还是据错比较查metalink的，在metalink上也有一些MySQL相关的库数文章，但是据错很少，如下：

错误就是库数那个错误，解决办法也比较简单就是加上主键重做，这个问题我个人已经遇到N次了，每次都这么处理的，隐约的b2b供应网觉得hash scan 有BUG。

在8.0中 hash scan 使用一个std::unordered_multimap的hash容器，记录其key - value值，每个key - value 代表修改的一行值，因为multimap容器允许重复的key - value，因此可以存在相同的行记录，这和5.7的实现不同，5.7是自己写的，而8.0 用的容器。其中：

当然这里是简化了，实际value还包含一个std::unordered_multimap的迭代器和删除器，其中迭代器的作用是高防服务器通过相同的key 调用，std::next 来查找下一个相同key的记录。 

当一个event扫描结束后会将所有这个event的记录存储到这个hash容器中，函数Hash_slave_rows::put。而查找阶段会全表扫描本表，每次获取一行数据，然后在hash容器中进行查找，并进行处理，如下：

这样做的目的很明确就是将全表扫描的次数减少，每个event才做一次，这样自然提高了性能。

这个BUG是同事查询到后给我的，BUG如下：https://bugs.mysql.com/bug.php?id=101828

在这个BUG中，出现了2行记录crc32一致的情况，如下2个字符串的crc32也是一致的：

但是在整个hash scan 逻辑中，实际上比对crc32相同过后还是做了实际值的比较，也就是不完全依赖crc32值。这个BUG的流程如下：

第一阶段，数据准备阶段：

这两行数据的crc32值一样。

第二阶段，数据错误阶段 主库执行：

显然这条语句更改是第二行数据，但是到了从库由于BUG存在更改的是第一条数据，这个时候数据已经错误了。这个时候主库数据如下：

从库数据如下：

第三阶段，报错阶段：

这里主库修改是第二行记录，也就是：

但是到了从库，因为a=1和b=7572456450708129686的hash crc32值和表中任何一个记录都不匹配 ，这报错。

来看一下为什么出现问题。 在例子中如果我们修改了1行数据，并且这行数据在表中有2数据存在相同的crc32值，主库修改的是2行数据，那么可能存在下面的问题：

从库首先在循环1中获取第1行数据，然后在hash结构中查找，找到相同的crc32值，进入循环2拷贝record后进入循环3首先对比record0到record1的值也就是event中的数据，也就是第2行数据和第1行数据对比，显然实际的值肯定不同，这获取event相同crc32的下一条记录，显然不存在因为就更改了1条数据，返回为NULL，循环3结束，继续，因为entry为NULL，恢复record0的操作和更改数据的操作都不会做。

然后循环2循环条件再次通过扫描到的行数据查找hash结构的entry依旧是第1行数据的entry，进行下一次循环，这个时候因为record0没有恢复，还是event对应的bi数据，因此拷贝后record1也就是event对应的bi数据，接着进入循环3，这个时候进行比较，实际上比较都是event中的数据，因此比较一定成功，进入修改流程。 这个时候实际上就是把表中的第一行数据给修改了。也就是这个时候数据已经不对了，再次进行修改在错误数据上进行修改自然就可能查不到数据的情况。这实际就是一个crc32碰撞后逻辑错误导致的问题。

相关文章