點(diǎn)擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”

后臺(tái)回復(fù)"書"，獲取

來源：22j.co/bYaE

每個(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)程退出了。看看錯(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)容，都予以足夠重視。

想知道更多？掃描下面的二維碼關(guān)注我

后臺(tái)回復(fù)"書"，獲取近百本電子書入口

【精彩推薦】

• 超清晰的DNS入門指南

• 深入理解Java Stream流水線

• 干掉Swagger,試試這個(gè)

• 干掉GuavaCache：Caffeine才是本地緩存的王

• 如何用ELK搭建TB級(jí)的日志系統(tǒng)

• 深度好文：Linux系統(tǒng)內(nèi)存知識(shí)

• 日志系統(tǒng)新貴Loki，確實(shí)比笨重的ELK輕

• 日志采集系統(tǒng)都用到哪些技術(shù)？

• 面試官：為什么HashMap的加載因子是0.75？

• 原創(chuàng)|OpenAPI標(biāo)準(zhǔn)規(guī)范
  

點(diǎn)個(gè)贊+在看，少個(gè) bug?????

總結(jié)

以上是生活随笔為你收集整理的今天才知道，MySQL 的 binlog 编号可以这么大！的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。