《MySQL binlog后面的編號最大是多大？MYSQL教程》要點：
本文介紹了MySQL binlog后面的編號最大是多大？MYSQL教程，希望對您有用。如果有疑問，可以聯系我們。

每個binlog文件都有編號,從最早的3位數(沒錯,很老的版本只有3位數~),到現在擴展到6位數,從000001開始計數.

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

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 文件存在(看會不會被覆蓋或者其他的).
touch mysql-bin.2147483640

然后啟動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的序號問題,我們結論如下：
binlog的最大序號是 pow(2,31)-1 = 2147483647.
當序號接近這個值,且差距小于 1000 時(也就是序號大于 2147482647 時),就開始向error log中寫入警告.
當序號達到最大值時,mysqld 進程直接退出.
生成新的binlog時,會掃描當前已存在的binlog文件,最終取得最大序號值.因此,如果binlog文件數目特別多的話,是會影響MySQL的啟動及日志切換效率的.
由此可見有兩個隱患,當binlog文件數目過大,會導致binlog切換效率較低.當binlog文件最大序號快達到最大值時,離mysqld進程掛掉就不遠了,需要加急處理.
因此,除了要監控binlog文件數目、最大序號外,還應該再error log的內容,都予以足夠重視.

最后祝大家的mysqld進程都棒棒噠!

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/5574.html