MySQL 的 binlog 編號(hào)竟然可以這么大！

點(diǎn)擊上方藍(lán)色“程序猿DD”，選擇“設(shè)為星標(biāo)”

回復(fù)“資源”獲取獨(dú)家整理的學(xué)習(xí)資料！

來源 | https://urlify.cn/VVFFNn

每個(gè)binlog文件都有編號(hào)，從最早的3位數(shù)（沒錯(cuò)，很老的版本只有3位數(shù)~），到現(xiàn)在擴(kuò)展到6位數(shù)，從000001開始計(jì)數(shù)。但我打賭，你一定不知道這個(gè)序號(hào)最大可以跑到多少。

MySQL在啟動(dòng)時(shí)會(huì)掃一下binlog文件，找到最大的序號(hào)，然后產(chǎn)生下個(gè)序號(hào)文件。根據(jù)這個(gè)規(guī)則，我們可以自行測(cè)試一下，若當(dāng)前最大的binlog序號(hào)是 999999 時(shí)，下一個(gè)文件序號(hào)是重新從 000001 開始，抑或是 1000000 呢？

# 測(cè)試一，當(dāng)文件序號(hào)達(dá)到999999后，下一個(gè)新文件序號(hào)是多少

把mysqld關(guān)掉，人為造出序號(hào)為999999的binlog，并直接啟動(dòng)mysqld，看看會(huì)怎樣呢？

執(zhí)行 show master status 進(jìn)行確認(rèn)

可以看到，mysqld并沒有掛掉，也沒重新從mysql-bin.000001開始，這個(gè)序號(hào)會(huì)繼續(xù)增加。

現(xiàn)在，我們?cè)偕钔谙逻@個(gè)問題，最大的序號(hào)到底是多少呢？

我們課上教學(xué)使用的版本是mysql 5.7.18，下載相應(yīng)版本的源碼直接看好了，在 sql/binlog.cc 文件中我們找到下面這段代碼：

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

    

     if (max_found == MAX_LOG_UNIQUE_FN_EXT)
    

也就是當(dāng)找到binlog文件最大序號(hào)，達(dá)到起定義的最大值時(shí)，mysqld就會(huì)退出。

我們?cè)倏聪?MAX_LOG_UNIQUE_FN_EXT 宏定義：

    

     #define MAX_LOG_UNIQUE_FN_EXT 0x7FFFFFFF
    

把它轉(zhuǎn)成十進(jìn)制看下：

這個(gè)值等于：pow(2,31) - 1

# 測(cè)試二，測(cè)試binlog序號(hào)達(dá)到最大值后會(huì)怎樣

手動(dòng)創(chuàng)建一個(gè)序號(hào)較大的binlog，比如mysql-bin.2147483640。把所有日志文名都寫入到 mysql-bin.index 中，并確認(rèn) mysql-bin.000001 文件存在（看會(huì)不會(huì)被覆蓋或者其他的）。

touch mysql-bin.2147483640

然后啟動(dòng)mysqld，再執(zhí)行 FLUSH LOGS，看看會(huì)怎樣。

這時(shí)，我們能看到 mysqld 啟動(dòng)，日志里記錄的告警信息：

我們多執(zhí)行幾次 FLUSH LOGS，切換日志，直到序號(hào)達(dá)到最大值，看看會(huì)發(fā)生什么：

第一次切換會(huì)發(fā)出一個(gè) ERROR 級(jí)別錯(cuò)誤日志，第二次再切換，直接導(dǎo)致 mysqld 進(jìn)程退出了?？纯村e(cuò)誤日志：

看這架勢(shì)，是想生成 mysql-bin.(1-999) 這樣的文件而未果。于是我們?cè)龠M(jìn)行下面的測(cè)試。

# 測(cè)試三，測(cè)試binlog序號(hào)能不能循環(huán)重來

還是 touch 一個(gè)較大序號(hào)的binlog，比如mysql-bin.2147483646。把所有日志文名都寫入到 mysql-bin.index 中，并確認(rèn) mysql-bin.000001 文件到 mysql-bin.000999 這些文件都不存在（和測(cè)試二不同，這次是要確保這些文件不存在，看能不能重復(fù)利用）。

然后啟動(dòng)mysqld，再執(zhí)行 FLUSH LOGS，看看會(huì)怎樣。

可以看到，還是會(huì)退出，并沒有進(jìn)行日志的輪轉(zhuǎn)再次重復(fù)利用。

# 最后，關(guān)于binlog的序號(hào)問題，我們結(jié)論如下:

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

當(dāng)序號(hào)接近這個(gè)值，且差距小于 1000 時(shí)（也就是序號(hào)大于 2147482647 時(shí)），就開始向error log中寫入警告。

當(dāng)序號(hào)達(dá)到最大值時(shí)，mysqld 進(jìn)程直接退出。

生成新的binlog時(shí)，會(huì)掃描當(dāng)前已存在的binlog文件，最終取得最大序號(hào)值。因此，如果binlog文件數(shù)目特別多的話，是會(huì)影響MySQL的啟動(dòng)及日志切換效率的。

由此可見有兩個(gè)隱患，當(dāng)binlog文件數(shù)目過大，會(huì)導(dǎo)致binlog切換效率較低。當(dāng)binlog文件最大序號(hào)快達(dá)到最大值時(shí)，離mysqld進(jìn)程掛掉就不遠(yuǎn)了，需要加急處理。

因此，除了要監(jiān)控binlog文件數(shù)目、最大序號(hào)外，還應(yīng)該再error log的內(nèi)容，都予以足夠重視。

往期推薦

fastjson 的作者，在阿里內(nèi)網(wǎng)挨罵了？！

Redisson 是如何實(shí)現(xiàn)分布式鎖的？

詳解：UML類圖符號(hào)、各種關(guān)系說明以及舉例

Spring Cloud 常見面試題及答案

面試：為什么 Java 線程沒有Running狀態(tài)？

星球限時(shí)拼團(tuán)優(yōu)惠進(jìn)行中

我的星球是否適合你？

點(diǎn)擊閱讀原文看看我們都聊過啥？