從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源碼看日志命令失效的原因有哪些”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！