從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行是空著的。

所以順著這個思路，可以看看是否是由於這個問題導致。

阿里的同學在文章

給出了參考的檔案，是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的實現裡還有些不完善的地方。程式碼裡看起來也是很無奈，只能以後修復了。

有了這些資訊，不斷跟著核心月報學學，發現分析問題也會別有一番風味。