共计 1501 个字符，预计需要花费 4 分钟才能阅读完成。
这篇文章主要为大家展示了“从 MySQL 源码看日志命令失效的原因有哪些”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让丸趣 TV 小编带领大家一起研究并学习一下“从 MySQL 源码看日志命令失效的原因有哪些”这篇文章吧。
今天看数据库内核月报，发现一个蛮有意思的问题，就是 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 的实现里还有些不完善的地方。代码里看起来也是很无奈，只能以后修复了。
以上是“从 MySQL 源码看日志命令失效的原因有哪些”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！
