共計 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 行業資訊頻道！