MySQL auto_increment 重启后值丢失

阅读更多

相关链接：

• 《MySQL自增变量auto_increment踩坑，重启后值丢失》
• 《Be Careful With MySQL's auto_increment. How We Ended Up Losing Data》
• 《AUTO_INCREMENT Handling in InnoDB》

 

背景描述

与相关链接《Be Careful...》中的案例很类似，某个业务系统中也有两张表，暂且称其为 pending_task 和 task_archive。它们的存储引擎都为 InnoDB；MySQL 版本为 5.7。
 

• 业务系统会先在 pending_task 表中创建一个新的 task 记录；
• 此表使用自增主键，作为 task 的唯一标识 —— task_id；
• task 结束后 pending_task 表中的相应记录会被删除；
• task_archive 表用于记录 task 的最终存档信息，主键就是 task_id。

先不讨论这种设计是否恰当。

该系统平时一切正常，但是一旦 MySQL 被重启，就很可能在向 task_archive 插入数据时引发重复主键的问题。

ERROR 1062 (23000): Duplicate entry 'xxx' for key 'PRIMARY'

 

很容易就想到是 pending_task 表中的新生成的 task_id 与以前的记录重复了。
一般人都是去复盘系统维护过程是否有不当操作，导致自增字段出错，很少会去怀疑 MySQL。
但事实就是 MySQL 处理自增字段的逻辑导致了重复ID。
（后来看了 MySQL 官方的说明措辞，居然隐约把这个“逻辑”当作了“特性”，而不是Bug...）

 

问题原因

在 MySQL 5.7 及 以前的版本中，InnoDB 表中的 auto-increment计数器 会把值存放在内存中，不会写入磁盘。一旦 MySQL 服务重启，这个值就丢了，InnoDB 引擎会根据表中现有的数据重新计算该计数器的值：

SELECT MAX(ai_col) FROM table_name FOR UPDATE;

因为上述业务系统会把 pending_task 中已结束task的记录删除，所以MySQL服务重启后，自增字段计数器重新计算，并得到了一个小于被删除 task_id 的值。如：当 pending_task 表中没有记录时，计算得到的结果为 0。
 

这种“特性”是不是很违背普通人的直觉？！

 

MySQL 8.0 auto-increment 计数器逻辑有变！

在 MySQL 8.0 中，这个计数器的逻辑变了：每当计数器的值有变，InnoDB 会将其写入 redo log，保存到引擎专用的系统表中。
 

MySQL 正常关闭后重启：从系统表中获取计数器的值。
 

MySQL 故障后重启：从系统表中获取计数器的值；从最后一个检查点开始扫描 redo log 中记录的计数器值；取这两者的最大值作为新值。
但是这个处理逻辑不能保证最后拿到的值是正确的：如果在计数器 redo log 落盘前服务崩溃，那么就可能拿到一个之前被使用过的值。
 

另，MySQL 8.0 开始，只有在 拷贝表空间 且 未指定.cfg元文件 时，才会使用以下语句确定计数器的值：

SELECT MAX(ai_col) FROM table_name FOR UPDATE;

 

解决方案

方案1：定制 MySQL

修改 MySQL 源码，自定义 auto-increment计数器 的运行逻辑。
 

显然这种方案成本很大，设计研发及后续的兼容性保障都是大手笔。
一般只有配备专职数据库研发团队的组织才会考虑。
当然也不排除某些不自量力、不负责、自私的决策人故意入坑。

 

方案2：升级到 MySQL 8.0

这个方案的影响得根据实际项目情况进行评估。
如果改动牵扯的范围比较广，回归测试不够彻底，很可能埋下一些大坑。
如果牵扯范围很小，具体影响边界很清晰，那也不失为一个好方案。
 

当然，你还是得评估极端情况 “计数器 redo log 落盘前 MySQL 崩溃” 对业务的影响，并设计相应的处理方案。

 

方案3：使用 MyISAM

MyISAM 中的 auto-increment计数器 数值是落盘的（.MYI文件头部），所以不存在重启后丢失的问题。
 

是否应该使用 MyISAM 又牵扯到它与 InnoDB 的优缺点比较：《MyISAM vs InnoDB》。
很多人因为 MyISAM 不支持行锁、不支持事务 而坚决使用 InnoDB。

 

方案4：弃用自增字段，选用其它唯一标识生成方案

既然 MySQL 的自增字段不靠谱，那我们就选一个靠谱的方案来生成记录的唯一标识。
 

UUID、Snowflake（分布式ID）是比较常见的方案。相应的性能、成本也都需要根据实际情况评估。
（理论上，UUID是有可能重复的。在实际合适的应用场景中，其重复几率低到可以忽略。）
注意：MySQL 中的 UUID() 方法是 version 1 —— 基于时间和节点ID（Mac地址或一个随机数）

 

方案5：保留自增字段值最大的记录

根据 MySQL 5.7 中的 auto-increment计数器逻辑，只要我们保留 自增字段值 最大的记录，MySQL 重启后重新计算得到的计数值就不会“回退”。
 

当然，此方案需要更改业务逻辑，甚至影响到相关干系人对系统设计的认知。
如，对于前述的业务系统，如果某个 task 已结束，但因其 task_id 是 pending_task 中最大的，而一直驻留在此表中，直到有新的 task 产生。这种行为在语义上和 “pending” 不符。
但是在实际项目中，这种偏 hack 的方案很可能是短时间内成本最低的。这个“短时间”甚至会长到超出所有人的预期，甚至让这种方案成为“标准”方案（中性语气，不是反讽，没有任何贬义）。
 

前述业务系统最后采用了该方案。