今天看数据库内核月报，发现一个蛮有意思的问题，就是show binary logs的时候没有任何结果，这个问题的原因很简单，但是分析问题的过程相比是艰辛的，需要在各种潜在的可能中找到那个肯定的结果。当然这个问题带给我的最大福利不是解决了这个问题，而是通过这个问题我们可以换一个思路来分析，比如说通过源码的方式来了解更多的细节。
我在自己的电脑上下载了MySQL近几个版本的源码，平时很少看，但是环境基本配置好了，就等待一些实用快捷的案例了。
首先复现下问题，我所测试的版本是5.6，使用show binary logs查看binlog的信息时，得到的结果如下：
mysql> show binary logs;
Empty set (0.00 sec)
而实际上这个环境是存在binlog的，毫无疑问，binlog是打开的。
我们可以在系统层面看到这些binlog
可以通过binlog.index文件看到，确实是存在这些binlog的。
因为我知道了问题的答案，所以就顺着里面的疑点来看，上面的index文件看起来比较奇怪，怎么第1行是空着的。
所以顺着这个思路，可以看看是否是由于这个问题导致。
阿里的同学在文章 http://mysql.taobao.org/monthly/2017/09/03/
给出了参考的文件，是rpl_master.cc，简单翻译就是属于replication部分，master端的。我们在master端使用的命令show master status,或者是reset master，里面的实现细节都在这个文件里面，所以我们举一反三，还有一个文件是rpl_slave,使用的reset_slave, start slave,stop slave,show slave status等等，都是在这个文件里面的。
我们查看文件rpl_master.cc文件看看里面的实现部分。如果使用eclipse的方式查看基本就能通过几个维度来看到一些明细的信息，左边的是代码的层级结构，中间的是指定的函数，比如show binary logs的实现，右边的是一些概览，比如变量，方法等。
当然rpl_master和rpl_slave的代码量相差巨大，rpl_slave加入了GTID的部分，可以看到大量的注释。
而rpl_master中，我们可以很快看到下面的逻辑。如果是空行或者是EOF结尾都会被视为文件的末尾，上面1行是调用了index文件得到一个列表的信息。
所以这个问题的明白了原委，修复起来也就很简单了。直接删掉那个空行，然后再次刷新日志即可。
先删掉空格，然后刷新日志，如下所示。
所以按照这个思路，我们可以在rpl_slave中找到自己自己想得到的内容，比如Seconds_Behind_Master的含义，代码中自有黄金屋。注释中甚至给出了伪代码，把计算的流程说得很详细。
里面的代码解释还是很详细的，感觉和读文档的感觉差不多。
当然里面也说得很明确，Seconds_Behind_Master不能全信，有时候也是不准的。
读了一会代码，发现request_dump的实现里还有些不完善的地方。代码里看起来也是很无奈，只能以后修复了。
有了这些信息，不断跟着内核月报学学，发现分析问题也会别有一番风味。
