从MySQL源码看日志命令失效的原因有哪些
这篇文章主要为大家展示了“从MySQL源码看日志命令失效的原因有哪些”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“从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源码看日志命令失效的原因有哪些”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注创新互联行业资讯频道!
文章标题:从MySQL源码看日志命令失效的原因有哪些
网址分享:http://scyanting.com/article/ghdeds.html