點(diǎn)擊上方“服務(wù)端思維”，選擇“設(shè)為星標(biāo)”
回復(fù)”669“獲取獨(dú)家整理的精選資料集
回復(fù)”加群“加入全國(guó)服務(wù)端高端社群「后端圈」
出品?| http://cp1m5.cn/zu70W日志是MySQL數(shù)據(jù)庫(kù)的重要組成部分，記錄著數(shù)據(jù)庫(kù)運(yùn)行期間各種狀態(tài)信息。MySQL日志主要包括錯(cuò)誤日志、查詢(xún)?nèi)罩尽⒙樵?xún)?nèi)罩尽⑹聞?wù)日志、二進(jìn)制日志幾大類(lèi)。作為開(kāi)發(fā)，我們重點(diǎn)需要關(guān)注的是二進(jìn)制日志（binlog）和事務(wù)日志（包括redo log和undo log），本文接下來(lái)會(huì)詳細(xì)介紹這三種日志。
binlog用于記錄數(shù)據(jù)庫(kù)執(zhí)行的寫(xiě)入性操作（不包括查詢(xún)）信息，以二進(jìn)制的形式保存在磁盤(pán)中。binlog是MySQL的邏輯日志，并且由Server層進(jìn)行記錄，使用任何存儲(chǔ)引擎的MySQL數(shù)據(jù)庫(kù)都會(huì)記錄binlog日志。binlog是通過(guò)追加的方式進(jìn)行寫(xiě)入的，可以通過(guò)max_binlog_size參數(shù)設(shè)置每個(gè)binlog文件的大小，當(dāng)文件大小達(dá)到給定值之后，會(huì)生成新的文件來(lái)保存日志。在實(shí)際應(yīng)用中，binlog的主要使用場(chǎng)景有兩個(gè)，分別是主從復(fù)制和數(shù)據(jù)恢復(fù)。對(duì)于InnoDB存儲(chǔ)引擎而言，只有在事務(wù)提交時(shí)才會(huì)記錄biglog，此時(shí)記錄還在內(nèi)存中，那么biglog是什么時(shí)候刷到磁盤(pán)中的呢？MySQL通過(guò)sync_binlog參數(shù)控制biglog的刷盤(pán)時(shí)機(jī)，取值范圍是0-N：0：不去強(qiáng)制要求，由系統(tǒng)自行判斷何時(shí)寫(xiě)入磁盤(pán)；
1：每次commit的時(shí)候都要將binlog寫(xiě)入磁盤(pán)；
N：每N個(gè)事務(wù)，才會(huì)將binlog寫(xiě)入磁盤(pán)。
從上面可以看出，sync_binlog最安全的是設(shè)置是1，這也是MySQL 5.7.7之后版本的默認(rèn)值。但是設(shè)置一個(gè)大一些的值可以提升數(shù)據(jù)庫(kù)性能，因此實(shí)際情況下也可以將值適當(dāng)調(diào)大，犧牲一定的一致性來(lái)獲取更好的性能。binlog日志有三種格式，分別為STATMENT、ROW和MIXED。在MySQL 5.7.7之前，默認(rèn)的格式是STATEMENT，MySQL 5.7.7之后，默認(rèn)值是ROW。日志格式通過(guò)binlog-format指定。STATMENT：基于SQL語(yǔ)句的復(fù)制（statement-based replication, SBR），每一條會(huì)修改數(shù)據(jù)的SQL語(yǔ)句會(huì)記錄到binlog中。優(yōu)點(diǎn)：不需要記錄每一行的變化，減少了binlog日志量，節(jié)約了IO，從而提高了性能；缺點(diǎn)：在某些情況下會(huì)導(dǎo)致主從數(shù)據(jù)不一致，比如執(zhí)行sysdate()、slepp()等。
ROW：基于行的復(fù)制（row-based replication，RBR），不記錄每條SQL語(yǔ)句的上下文信息，僅需記錄哪條數(shù)據(jù)被修改了。優(yōu)點(diǎn)：不會(huì)出現(xiàn)某些特定情況下的存儲(chǔ)過(guò)程、或function、或trigger的調(diào)用和觸發(fā)無(wú)法被正確復(fù)制的問(wèn)題；缺點(diǎn)：會(huì)產(chǎn)生大量的日志，尤其是alter table的時(shí)候會(huì)讓日志暴漲。
MIXED：基于STATMENT和ROW兩種模式的混合復(fù)制（mixed-based replication，MBR），一般的復(fù)制使用STATEMENT模式保存binlog，對(duì)于STATEMENT模式無(wú)法復(fù)制的操作使用ROW模式保存binlog。
我們都知道，事務(wù)的四大特性里面有一個(gè)是持久性，具體來(lái)說(shuō)就是只要事務(wù)提交成功，那么對(duì)數(shù)據(jù)庫(kù)做的修改就被永久保存下來(lái)了，不可能因?yàn)槿魏卧蛟倩氐皆瓉?lái)的狀態(tài)。那么MySQL是如何保證持久性的呢？最簡(jiǎn)單的做法是在每次事務(wù)提交的時(shí)候，將該事務(wù)涉及修改的數(shù)據(jù)頁(yè)全部刷新到磁盤(pán)中。但是這么做會(huì)有嚴(yán)重的性能問(wèn)題，主要體現(xiàn)在兩個(gè)方面：因?yàn)镮nnoDB是以頁(yè)為單位進(jìn)行磁盤(pán)交互的，而一個(gè)事務(wù)很可能只修改一個(gè)數(shù)據(jù)頁(yè)里面的幾個(gè)字節(jié)，這個(gè)時(shí)候?qū)⑼暾臄?shù)據(jù)頁(yè)刷到磁盤(pán)的話(huà)，太浪費(fèi)資源了！
一個(gè)事務(wù)可能涉及修改多個(gè)數(shù)據(jù)頁(yè)，并且這些數(shù)據(jù)頁(yè)在物理上并不連續(xù)，使用隨機(jī)IO寫(xiě)入性能太差！
因此MySQL設(shè)計(jì)了redo log，具體來(lái)說(shuō)就是只記錄事務(wù)對(duì)數(shù)據(jù)頁(yè)做了哪些修改，這樣就能完美地解決性能問(wèn)題了（相對(duì)而言文件更小并且是順序IO）。redo log包括兩部分：一個(gè)是內(nèi)存中的日志緩沖（redo log buffer），另一個(gè)是磁盤(pán)上的日志文件（redo log file）。MySQL每執(zhí)行一條DML語(yǔ)句，先將記錄寫(xiě)入redo log buffer，后續(xù)某個(gè)時(shí)間點(diǎn)再一次性將多個(gè)操作記錄寫(xiě)到redo log file。這種先寫(xiě)日志，再寫(xiě)磁盤(pán)的技術(shù)就是MySQL里經(jīng)常說(shuō)到的WAL（Write-Ahead Logging）技術(shù)。在計(jì)算機(jī)操作系統(tǒng)中，用戶(hù)空間（user space）下的緩沖區(qū)數(shù)據(jù)一般情況下是無(wú)法直接寫(xiě)入磁盤(pán)的，中間必須經(jīng)過(guò)操作系統(tǒng)內(nèi)核空間（kernel space）緩沖區(qū)（OS Buffer）。因此，redo log buffer寫(xiě)入redo log file實(shí)際上是先寫(xiě)入OS Buffer，然后再通過(guò)系統(tǒng)調(diào)用fsync()將其刷到redo log file中，過(guò)程如下：MySQL支持三種將redo log buffer寫(xiě)入redo log file的時(shí)機(jī)，可以通過(guò)innodb_flush_log_at_trx_commit參數(shù)配置，各參數(shù)值含義如下：參數(shù)值
| 含義
|
| 0（延遲寫(xiě)） | 事務(wù)提交時(shí)不會(huì)將redo log buffer中日志寫(xiě)入到os buffer，而是每秒寫(xiě)入os buffer并調(diào)用fsync()寫(xiě)入到redo log file中。也就是說(shuō)設(shè)置為0時(shí)是(大約)每秒刷新寫(xiě)入到磁盤(pán)中的，當(dāng)系統(tǒng)崩潰，會(huì)丟失1秒鐘的數(shù)據(jù)。 |
| 1（實(shí)時(shí)寫(xiě)，實(shí)時(shí)刷） | 事務(wù)每次提交都會(huì)將redo log buffer中的日志寫(xiě)入os buffer并調(diào)用fsync()刷到redo log file中。這種方式即使系統(tǒng)崩潰也不會(huì)丟失任何數(shù)據(jù)，但是因?yàn)槊看翁峤欢紝?xiě)入磁盤(pán)，IO的性能較差。 |
| 2（實(shí)時(shí)寫(xiě)，延遲刷） | 每次提交都僅寫(xiě)入到os buffer，然后是每秒調(diào)用fsync()將os buffer中的日志寫(xiě)入到redo log file。 |
前面說(shuō)過(guò)，redo log實(shí)際上記錄數(shù)據(jù)頁(yè)的變更，而這種變更記錄是沒(méi)必要全部保存，因此redo log實(shí)現(xiàn)上采用了大小固定，循環(huán)寫(xiě)入的方式，當(dāng)寫(xiě)到結(jié)尾時(shí)，會(huì)回到開(kāi)頭循環(huán)寫(xiě)日志。如下圖：同時(shí)我們很容易得知，在InnoDB中，既有redo log需要刷盤(pán)，還有數(shù)據(jù)頁(yè)也需要刷盤(pán)，redo log存在的意義主要就是降低對(duì)數(shù)據(jù)頁(yè)刷盤(pán)的要求。在上圖中，write pos表示redo log當(dāng)前記錄的LSN（邏輯序列號(hào)）位置，check point表示數(shù)據(jù)頁(yè)更改記錄刷盤(pán)后對(duì)應(yīng)redo log所處的LSN（邏輯序列號(hào)）位置。write pos到check point之間的部分是redo log空著的部分，用于記錄新的記錄；check point到write pos之間是redo log待落盤(pán)的數(shù)據(jù)頁(yè)更改記錄。當(dāng)write pos追上check point時(shí)，會(huì)先推動(dòng)check point向前移動(dòng)，空出位置再記錄新的日志。啟動(dòng)InnoDB的時(shí)候，不管上次是正常關(guān)閉還是異常關(guān)閉，總是會(huì)進(jìn)行恢復(fù)操作。因?yàn)閞edo log記錄的是數(shù)據(jù)頁(yè)的物理變化，因此恢復(fù)的時(shí)候速度比邏輯日志（如binlog）要快很多。重啟InnoDB時(shí)，首先會(huì)檢查磁盤(pán)中數(shù)據(jù)頁(yè)的LSN，如果數(shù)據(jù)頁(yè)的LSN小于日志中的LSN，則會(huì)從checkpoint開(kāi)始恢復(fù)。還有一種情況，在宕機(jī)前正處于checkpoint的刷盤(pán)過(guò)程，且數(shù)據(jù)頁(yè)的刷盤(pán)進(jìn)度超過(guò)了日志頁(yè)的刷盤(pán)進(jìn)度，此時(shí)會(huì)出現(xiàn)數(shù)據(jù)頁(yè)中記錄的LSN大于日志中的LSN，這時(shí)超出日志進(jìn)度的部分將不會(huì)重做，因?yàn)檫@本身就表示已經(jīng)做過(guò)的事情，無(wú)需再重做。
| redo log | binlog |
| 文件大小 | redo log的大小是固定的。 | binlog可通過(guò)配置參數(shù)max_binlog_size設(shè)置每個(gè)binlog文件的大小。 |
| 實(shí)現(xiàn)方式 | redo log是InnoDB引擎層實(shí)現(xiàn)的，并不是所有引擎都有。 | binlog是Server層實(shí)現(xiàn)的，所有引擎都可以使用 binlog日志。 |
| 記錄方式 | redo log 采用循環(huán)寫(xiě)的方式記錄，當(dāng)寫(xiě)到結(jié)尾時(shí)，會(huì)回到開(kāi)頭循環(huán)寫(xiě)日志。 | binlog 通過(guò)追加的方式記錄，當(dāng)文件大小大于給定值后，后續(xù)的日志會(huì)記錄到新的文件上。 |
| 適用場(chǎng)景 | redo log適用于崩潰恢復(fù)（crash-safe）。 | binlog適用于主從復(fù)制和數(shù)據(jù)恢復(fù)。 |
由binlog和redo log的區(qū)別可知：binlog日志只用于歸檔，只依靠binlog是沒(méi)有crash-safe能力的。但只有redo log也不行，因?yàn)閞edo log是InnoDB特有的，且日志上的記錄落盤(pán)后會(huì)被覆蓋掉。因此需要binlog和redo log二者同時(shí)記錄，才能保證當(dāng)數(shù)據(jù)庫(kù)發(fā)生宕機(jī)重啟時(shí)，數(shù)據(jù)不會(huì)丟失。
數(shù)據(jù)庫(kù)事務(wù)四大特性中有一個(gè)是原子性，具體來(lái)說(shuō)就是原子性是指對(duì)數(shù)據(jù)庫(kù)的一系列操作，要么全部成功，要么全部失敗，不可能出現(xiàn)部分成功的情況。實(shí)際上，原子性底層就是通過(guò)undo log實(shí)現(xiàn)的。undo log主要記錄了數(shù)據(jù)的邏輯變化，比如一條INSERT語(yǔ)句，對(duì)應(yīng)一條DELETE的undo log，對(duì)于每個(gè)UPDATE語(yǔ)句，對(duì)應(yīng)一條相反的UPDATE的undo log，這樣在發(fā)生錯(cuò)誤時(shí)，就能回滾到事務(wù)之前的數(shù)據(jù)狀態(tài)。同時(shí)，undo log也是MVCC（多版本并發(fā)控制）實(shí)現(xiàn)的關(guān)鍵，這部分內(nèi)容在https://juejin.cn/post/6855129007336521741中有介紹，不再贅述。
關(guān)注我，回復(fù) 「加群」 加入各種主題討論群。
對(duì)「服務(wù)端思維」有期待，請(qǐng)?jiān)谖哪c(diǎn)個(gè)在看
喜歡這篇文章，歡迎轉(zhuǎn)發(fā)、分享朋友圈
