导读

每个binlog文件都有编号，从最早的3位数(没错，很老的版本只有3位数~)，到现在扩展到6位数，从000001开始计数。

但我打赌，你一定不知道这个序号最大可以跑到多少。

在我们知数堂的MySQL DBA课上讲到binlog序号是从000001开始，这时有细心的同学问到，是不是这个序号达到999999后，binlog就要重新开始了？

讲真，当时我也是一下子被问住了，只是隐约记得这个值是可以大于999999的。于是，课后我自己细致地探究了一番，遂有本文。

MySQL在启动时会扫一下binlog文件，找到最大的序号，然后产生下个序号文件。根据这个规则，我们可以自行测试一下，若当前最大的binlog序号是 999999 时，下一个文件序号是重新从 000001 开始，抑或是 1000000 呢？

• 测试一，当文件序号达到999999后，下一个新文件序号是多少

把mysqld关掉，人为造出序号为999999的binlog，并直接启动mysqld，看看会怎样呢？

执行 show master status 进行确认

可以看到，mysqld并没有挂掉，也没重新从mysql-bin.000001开始，这个序号会继续增加。

现在，我们再深挖下这个问题，最大的序号到底是多少呢？

我们课上教学使用的版本是mysql 5.7.18，下载相应版本的源码直接看好了，在 sql/binlog.cc 文件中我们找到下面这段代码：

在上面这段代码中，我们看到如下判断：

if (max_found == MAX_LOG_UNIQUE_FN_EXT)

也就是当找到binlog文件最大序号，达到起定义的最大值时，mysqld就会退出。

我们再看下 MAX_LOG_UNIQUE_FN_EXT 宏定义：

#define MAX_LOG_UNIQUE_FN_EXT 0x7FFFFFFF

把它转成十进制看下：

这个值等于：pow(2,31) - 1

• 测试二，测试binlog序号达到最大值后会怎样

手动创建一个序号较大的binlog，比如mysql-bin.2147483640。把所有日志文名都写入到 mysql-bin.index 中，并确认 mysql-bin.000001 文件存在(看会不会被覆盖或者其他的)。

touch mysql-bin.2147483640

然后启动mysqld，再执行 FLUSH LOGS，看看会怎样。

这时，我们能看到 mysqld 启动，日志里记录的告警信息：

我们多执行几次 FLUSH LOGS，切换日志，直到序号达到最大值，看看会发生什么：

第一次切换会发出一个 ERROR 级别错误日志，第二次再切换，直接导致 mysqld 进程退出了。看看错误日志：

看这架势，是想生成 mysql-bin.(1-999) 这样的文件而未果。于是我们再进行下面的测试。

• 测试三，测试binlog序号能不能循环重来

还是 touch 一个较大序号的binlog，比如mysql-bin.2147483646。把所有日志文名都写入到 mysql-bin.index 中，并确认 mysql-bin.000001 文件到 mysql-bin.000999 这些文件都不存在(和测试二不同，这次是要确保这些文件不存在，看能不能重复利用)。

然后启动mysqld，再执行 FLUSH LOGS，看看会怎样。

可以看到，还是会退出，并没有进行日志的轮转再次重复利用。

最后，关于binlog的序号问题，我们结论如下：

1. binlog的最大序号是 pow(2,31)-1 = 2147483647。
2. 当序号接近这个值，且差距小于 1000 时(也就是序号大于 2147482647 时)，就开始向error log中写入警告。
3. 当序号达到最大值时，mysqld 进程直接退出。
4. 生成新的binlog时，会扫描当前已存在的binlog文件，最终取得最大序号值。因此，如果binlog文件数目特别多的话，是会影响MySQL的启动及日志切换效率的。
5. 由此可见有两个隐患，当binlog文件数目过大，会导致binlog切换效率较低。当binlog文件最大序号快达到最大值时，离mysqld进程挂掉就不远了，需要加急处理。
6. 因此，除了要监控binlog文件数目、最大序号外，还应该再error log的内容，都予以足够重视。

最后祝大家的mysqld进程都棒棒哒！

关于「3306π」社区

围绕 MySQL 核心技术，将互联网行业中最重要的数据化解决方案带到传统行业中；囊括其他开源技术Redis、MongoDB、Hbase、Hadoop、ElasticSearch、Storm、Spark等；分享干货知识，即便是赞助商，也要求如此，拒绝放水。