MySQL自增主键遇到主从切换，数据泄露警告你怕不怕？

普通熊猫 2021-09-27 09:55:14

一、感谢GitHub兄弟趟坑

2012年9月，GitHub官网发生用户私有数据泄露事故。

事故的原因是MySQL集群的数据库主节点写压力过大，导致心跳检查失败，这时某个未完全同步的从节点被自动提升为主节点。

在当时的数据设计中，开发人员使用了auto_increment自增计数器作为表的自增主键。新的主节点的计数器落后于原主节点（主从复制使用了异步方式，两者并非完全同步），它重新使用了某些已经被原主节点分配出去的主键。

然而，不幸的是，这些主键恰好已经被外部的redis系统引用了，结果出现了MySQL与Redis之间的数据不一致，最终某些私有数据被错误地泄露给了其它用户。

二、对自增主键的朴素期待

啥是自增主键？以下是MySQL的一个例子：

create table ‘test’ (‘id’  int(16) NOT NULL AUTO_INCREMENT,‘name’  char(10) DEFAULT NULL, PRIMARY KEY(‘id’)) ENGINE = InnoDB;

自增主键给开发人员提供了很大的便利。由于MySQL存储引擎的特性，主键唯一且自增是普遍的设计要求。如果数据库没有内置这个特性，应用开发人员就必须自己设计一套主键生成逻辑，而数据库原生提供的自增主键免去了这些工作量，这是非常好的事情。

而且，自增主键似乎还能满足开发人员更多的期待，比如：

唯一性：必要特性，否则就没法做主键了。

单调递增：后插入记录的自增主键值一定比先插入记录的值要大。

连续递增：自增主键每次加1 。

大家之所以有这些期待，是因为这些特征非常符合原子计数器的人设（对比java中的AtomicInteger，golang听atomic包），同时原子计数器非常高效，因此看起来也非常适合完成这个任务。然而，现实总想着时不时的给我们上一课：

首先是单调递增：从auto_increment计数器取到值，到写入到redo日志，这个过程中间没有原子性保证，并且是多线程操作。因此，即使取的过程中是单调递增的，落盘之后也不见得是。

其次是连续递增：自增主键每次加1本来也没啥，但是数据库事务是有可能失败的，你不能指望一个事务回滚的时候还把自增主键也回滚吧？

因此，这样盘算下来，只有唯一性是可以保证的，其它两点都只是一厢情愿的幻觉。

既然是幻觉，也就没什么好坚持的了。

三、如何避免主从切换时丢失数据？

在刚刚GitHub的事故分析中，之所以主从切换时会丢失数据，是因为集群把一个未能与主节点完全同步的从节点选举出来作为新的主节点。这真是一件遗憾的事情。为了避免同样的问题，我们需要至少有一个时刻与主节点保持数据同步的从节点，为了达到这个目标，通常会将集群配置成半同步复制模式：集群的所有从节点中，有一个从节点是同步复制模式，其它的从节点是异步复制模式。

不应该将所有的从节点都配置成同步复制模式，否则MySQL每次写数据必须等待所有从节点确认后才能返回，这会极大影响整个集群的响应时间。同时，如果其中某个从节点crash掉了，还会导致整个集群不可用。

相比之下，Kafka的ISR机制要可靠的多：如果从节点迅速确认返回了，应该保持同步；如果从节点超时未返回，就将它踢出ISR变成异步。

这样就能保证万无一失了嘛？等等，有坑：MySQL的REPLACE操作会导致主从节点的AUTO_INCREMENT值不一致，这个bug直到MySQL 8.0才修复。以我司到目前还在广泛使用MySQL 5.6现状来看，万一主从切换了，这是分分钟又掉入到GitHub坑里的节奏。要避免这个，就得禁止使用replace语句。

等等，这可不是唯一的坑：一些复杂的SQL语句，会在insert自带select，如果配置了binlog_format=statement，同样的SQL语句在主节点与从节点上选择的索引可能是不一样的，这可能会导致主从数据插入的顺序不一样。要避免这个，就得配置binlog_format=row。

你不能指望所有的业务研发和运维都配合你，对吧？

四、分布式id生成算法是一个更好选择吗？

市面上有很多分布式id生成算法，比如twitter的snowflake算法，变种的sonyflake算法等。它们通过将int64进行分段拆分，把时间戳和机器id揉和进一个int64中，从而做到集群中的不同机器在相互无感知的前提下生成（大概率）全局唯一的id。

以snowflake算法为例：