導讀

每個binlog檔案都有編號，從最早的3位數（沒錯，很老的版本只有3位數~），到現在擴充套件到6位數，從000001開始計數。

但我打賭，你一定不知道這個序號最大可以跑到多少。

在我們知數堂的MySQL DBA課上講到binlog序號是從000001開始，這時有細心的同學問到，是不是這個序號達到999999後，binlog就要重新開始了？

講真，當時我也是一下子被問住了，只是隱約記得這個值是可以大於999999的。於是，課後我自己細緻地探究了一番，遂有本文。

MySQL在啟動時會掃一下binlog檔案，找到最大的序號，然後產生下個序號檔案。根據這個規則，我們可以自行測試一下，若當前最大的binlog序號是 999999 時，下一個檔案序號是重新從 000001 開始，抑或是 1000000 呢？

• 測試一，當檔案序號達到999999後，下一個新檔案序號是多少

把mysqld關掉，人為造出序號為999999的binlog，並直接啟動mysqld，看看會怎樣呢？

執行 show master status 進行確認

可以看到，mysqld並沒有掛掉，也沒重新從mysql-bin.000001開始，這個序號會繼續增加。

現在，我們再深挖下這個問題，最大的序號到底是多少呢？

我們課上教學使用的版本是mysql 5.7.18，下載相應版本的原始碼直接看好了，在 sql/binlog.cc 檔案中我們找到下面這段程式碼：

在上面這段程式碼中，我們看到如下判斷：

if (max_found == MAX_LOG_UNIQUE_FN_EXT)

也就是當找到binlog檔案最大序號，達到起定義的最大值時，mysqld就會退出。 我們再看下 MAX_LOG_UNIQUE_FN_EXT 巨集定義：

#define MAX_LOG_UNIQUE_FN_EXT 0x7FFFFFFF

把它轉成十進位制看下：


這個值等於：pow(2,31) - 1

• 測試二，測試binlog序號達到最大值後會怎樣

手動建立一個序號較大的binlog，比如mysql-bin.2147483640。把所有日誌文名都寫入到mysql-bin.index 中，並確認 mysql-bin.000001 檔案存在（看會不會被覆蓋或者其他的）。

然後啟動mysqld，再執行 FLUSH LOGS，看看會怎樣。

這時，我們能看到 mysqld 啟動，日誌裡記錄的告警資訊：

 

我們多執行幾次 FLUSH LOGS，切換日誌，直到序號達到最大值，看看會發生什麼：
第一次切換會發出一個 ERROR 級別錯誤日誌，第二次再切換，直接導致 mysqld 程序退出了。看看錯誤日誌：

看這架勢，是想生成 mysql-bin.(1-999) 這樣的檔案而未果。於是我們再進行下面的測試。

• 測試三，測試binlog序號能不能迴圈重來

還是 touch 一個較大序號的binlog，比如mysql-bin.2147483646。把所有日誌文名都寫入到mysql-bin.index 中，並確認 mysql-bin.000001 檔案到 mysql-bin.000999 這些檔案都不存在（和測試二不同，這次是要確保這些檔案不存在，看能不能重複利用）。

然後啟動mysqld，再執行 FLUSH LOGS，看看會怎樣。
可以看到，還是會退出，並沒有進行日誌的輪轉再次重複利用。

最後，關於binlog的序號問題，我們結論如下：

1.binlog的最大序號是pow(2,31)-1=2147483647。

2.當序號接近這個值，且差距小於1000時（也就是序號大於2147482647時），就開始向

errorlog中寫入警告。

3.當序號達到最大值時，mysqld程序直接退出。

4.生成新的binlog時，會掃描當前已存在的binlog檔案，最終取得最大序號值。因此，如果

binlog檔案數目特別多的話，是會影響MySQL的啟動及日誌切換效率的。

5.由此可見有兩個隱患，當binlog檔案數目過大，會導致binlog切換效率較低。當binlog文

件最大序號快達到最大值時，離mysqld程序掛掉就不遠了，需要加急處理。

6.因此，除了要監控binlog檔案數目、最大序號外，還應該再errorlog的內容，都予以足夠

重視。

文章來自微信公眾號：老葉茶館