MYSQL中binlog優(yōu)化的一些思考匯總

問(wèn)題

問(wèn)題1：如何解決事務(wù)提交時(shí)flush redo log帶來(lái)的性能損失

WAL是實(shí)現(xiàn)事務(wù)持久性(D)的一個(gè)常用技術(shù)，基本原理是將事務(wù)的修改記錄redo log。redo log順序追加寫(xiě)入。事務(wù)提交時(shí)，只需要保證事務(wù)的redo log落盤(pán)即可，通過(guò)redo log的順序?qū)懘骓?yè)面的隨機(jī)寫(xiě)提升數(shù)據(jù)庫(kù)系統(tǒng)的性能。但是，該方案必須要求每個(gè)事務(wù)提交時(shí)都將其生成的redo log進(jìn)行一次刷盤(pán)，效率不高。

問(wèn)題2：binlog和引擎層事務(wù)提交的順序問(wèn)題

對(duì)于單個(gè)事務(wù)而言，日志寫(xiě)入順序是先redo log再binlog，只要維持該順序即可維持正確性。但對(duì)于一個(gè)高并發(fā)的數(shù)據(jù)庫(kù)系統(tǒng)而言，每時(shí)每刻可能都會(huì)存在眾多并發(fā)執(zhí)行的事務(wù)。我們還需要通過(guò)一定的手段來(lái)維護(hù)Server層binlog和引擎層事務(wù)提交的順序一致性。

維護(hù)這種順序一致性其實(shí)是為了保證備份工具Xtrabackup的正確性。

當(dāng) binlog 作為協(xié)調(diào)者，如果其中記錄的事務(wù)順序和存儲(chǔ)引擎層記錄的順序不一樣的話，備份工具（Innodb Hot Backup）拿到備份集的位點(diǎn)可能會(huì)存在空洞。因?yàn)閭浞莨ぞ邥?huì)拷貝 redo 日志，在 redo 的頭部會(huì)記錄最后一個(gè)提交的事務(wù)對(duì)應(yīng)的 binlog 位點(diǎn)，備份集建立之后就會(huì)根據(jù)這個(gè)位點(diǎn)繼續(xù)從主庫(kù) dump binlog。

假如有三個(gè)事務(wù) T1，T2，T3 已經(jīng) fsync 到 binlog 文件中，三個(gè)事務(wù)的在文件中的位點(diǎn)分別是 100，200，300，但是在引擎層的只有 T1 和 T3 完成了 commit 并記錄到 redo 中，最后一個(gè) commit 的事務(wù) T3 位點(diǎn)是 300。此時(shí)通過(guò)備份工具拿到的數(shù)據(jù)就是這樣的狀態(tài)，備份集啟動(dòng)的時(shí)候會(huì)走崩潰恢復(fù)的流程，prepare 事務(wù)被回滾（備份集不會(huì)備份 binlog 文件，對(duì)應(yīng)上個(gè)小節(jié) xid 集合為空），自位點(diǎn) 300 繼續(xù)從主庫(kù)同步binlog并apply，導(dǎo)致 T2 在備庫(kù)就丟失了。

因此，我們必須設(shè)計(jì)一種機(jī)制來(lái)保證Server層的binlog寫(xiě)入順序和存儲(chǔ)引擎層的事務(wù)提交順序保持一致。

問(wèn)題3：同時(shí)寫(xiě)redo和binlog帶來(lái)的性能下降

問(wèn)題1中提到每次的事務(wù)提交會(huì)帶來(lái)性能問(wèn)題，而這個(gè)問(wèn)題在引入binlog后會(huì)變得更加嚴(yán)重。每個(gè)事務(wù)提交都會(huì)增加一次文件IO，且需要刷盤(pán)。如果系統(tǒng)并發(fā)比較高，那么這些IO將會(huì)成為拖慢整體性能的瓶頸。

解決方案

問(wèn)題1：Redo log組提交技術(shù)

redo組提交技術(shù)思想很簡(jiǎn)單：通過(guò)將多個(gè)事務(wù)redo log的刷盤(pán)動(dòng)作合并，減少刷盤(pán)次數(shù)。Innodb的日志系統(tǒng)里面，每條redo log都有一個(gè)LSN(Log Sequence Number)。事務(wù)將日志拷貝到redo log buffer時(shí)，都會(huì)獲取當(dāng)前最大的LSN，且LSN單調(diào)遞增，因此可以保證不同事務(wù)的LSN不會(huì)重復(fù)。那么假設(shè)三個(gè)事務(wù)Trx1、Trx2、Trx3的日志的最大LSN分別為L(zhǎng)SN1、LSN2、LSN3（LSN1 LSN2 LSN3)，它們同時(shí)進(jìn)行提交，那么如果trx3率先執(zhí)行提交，它會(huì)要求刷盤(pán)至LSN3處，這樣就順便將Trx1、Trx2的redo log也刷了，Trx1和Trx2會(huì)判斷自己的LSN小于當(dāng)前已落盤(pán)的最大LSN，就無(wú)需再次刷盤(pán)。

問(wèn)題2：內(nèi)部XA事務(wù)

開(kāi)啟binlog情況下，引入內(nèi)部XA事務(wù)來(lái)協(xié)調(diào)上層和存儲(chǔ)引擎層，具體來(lái)說(shuō)，在事務(wù)提交時(shí)引入兩個(gè)階段：

prepare：將redo log刷盤(pán)操作以確保data頁(yè)和undo頁(yè)的更新已經(jīng)刷新到磁盤(pán)，設(shè)置事務(wù)狀態(tài)為PREPARE狀態(tài)；

commit：1). 寫(xiě)binlog并刷盤(pán)，2).調(diào)用引擎層事務(wù)提交接口。將事務(wù)狀態(tài)設(shè)置為COMMIT。

如此兩階段提交主要是要保證數(shù)據(jù)庫(kù)崩潰時(shí)的正確性。因?yàn)橐坏゜inlog落盤(pán)了，它就可能被下游節(jié)點(diǎn)消費(fèi)。這種事務(wù)必須在重啟后被commit而非rollback。而對(duì)于binlog未落盤(pán)的事務(wù)，崩潰恢復(fù)時(shí)直接回滾。

具體來(lái)說(shuō)，故障恢復(fù)時(shí)，掃描最后一個(gè)binlog文件(在flush階段，如果binlog大小超過(guò)閥值，進(jìn)行rotate binlog文件，會(huì)保證該文件記錄的最后一個(gè)事務(wù)一定被提交)，提取其中的xid。重做檢查點(diǎn)以后的redo日志，讀取事務(wù)的undo段信息，搜集處于prepare階段的事務(wù)列表，將事務(wù)的xid與binlog中記錄的xid對(duì)比，若存在，則提交，否則就回滾。

MySQL5.6以前，為了保證數(shù)據(jù)庫(kù)binlog的寫(xiě)入順序和InnoDB層的事務(wù)提交順序一致，MySQL數(shù)據(jù)庫(kù)內(nèi)部使用了prepare_commit_mutex鎖。

具體來(lái)說(shuō)，在兩階段提交引擎層 prepare 的時(shí)候加鎖，在引擎層 commit 之后釋放鎖：

innobase_xa_prepare()
write() and fsync() binary log
innobase_commit()

這樣確實(shí)可以保證 binlog 和 innodb 的事務(wù)順序一致，但是這把鎖會(huì)導(dǎo)致所有的事務(wù)串行化執(zhí)行，且每次提交都會(huì)至少調(diào)用多次fsync，效率很低。這也是接下來(lái)需要探討并解決的一個(gè)問(wèn)題。

問(wèn)題4

參考redo log優(yōu)化技術(shù)，引入組提交技術(shù)來(lái)優(yōu)化binlog的寫(xiě)入性能。

考慮未優(yōu)化時(shí)事務(wù)提交流程：

prepare：該階段刷存儲(chǔ)引擎層(innodb)的redo log并將事務(wù)狀態(tài)設(shè)置為PREPARED(更新undo page上事務(wù)狀態(tài))，該階段不涉及binlog
commit：寫(xiě)binlog日志并刷盤(pán)，同時(shí)引擎層釋放鎖，釋放回滾段、設(shè)置事務(wù)狀態(tài)為COMMITTED等
所謂的組提交技術(shù)其本質(zhì)上是將耗時(shí)的commit步驟進(jìn)行更細(xì)粒度的拆分，具體來(lái)說(shuō)：

將步驟2的commit 分為三個(gè)階段：

Flush：寫(xiě)binlog，但不sync
Sync： 調(diào)用 fsync 操作將文件落盤(pán)
Commit ：調(diào)用存儲(chǔ)引擎接口提交事務(wù)

這里的fsync是耗時(shí)操作，因此我們希望能攢足夠多的寫(xiě)入后才進(jìn)行一次fsync調(diào)用，在這里使用batch技術(shù)。其原理是：上述步驟中的每個(gè)階段都有一個(gè)對(duì)應(yīng)的任務(wù)鏈表，每個(gè)進(jìn)入該階段的線程會(huì)將自己的任務(wù)加入至該鏈表中，鏈表加鎖以保證正確性。第一個(gè)加入該鏈表的線程會(huì)成為L(zhǎng)eader，后續(xù)的線程成為Follower。鏈表中的所有任務(wù)組成一個(gè)Batch，由Leader負(fù)責(zé)執(zhí)行，而Follower則等待其任務(wù)完成即可。

一旦某階段的鏈表任務(wù)執(zhí)行完成，這些任務(wù)會(huì)進(jìn)入下一個(gè)階段，同樣加入該階段的任務(wù)鏈表，重復(fù)上述執(zhí)行流。

如此設(shè)計(jì)有以下幾點(diǎn)好處：

1. 使用Leader執(zhí)行而非每個(gè)線程各自執(zhí)行可有效減少write/fsync等調(diào)用次數(shù)，提高效率
2. 可保證事務(wù)寫(xiě)binlog和引擎層提交的順序一致
3. 多事務(wù)可并發(fā)執(zhí)行，而不再需要被prepare_commit_mutex鎖強(qiáng)制串行化
   

除此之外，MYSQL還對(duì)prepare階段刷redo log進(jìn)行了進(jìn)一步優(yōu)化。原來(lái)的設(shè)計(jì)是多事務(wù)可并發(fā)地刷redo log，同樣效率不夠高?？梢詫repare階段的redo log刷盤(pán)放在commit階段的Flush階段執(zhí)行。但有個(gè)小問(wèn)題需要說(shuō)明的是：優(yōu)化前每個(gè)線程各自負(fù)責(zé)自己的redo log的落盤(pán)，且知道需要flush的redo log的lsn，如果改為在Flush階段由其Leader線程統(tǒng)一落盤(pán)，此時(shí)它不了解每個(gè)線程的redo log的lsn，因此它簡(jiǎn)單粗暴地flush至log_sys的最大lsn，這就保證了要提交事務(wù)的redo log一定可以被落盤(pán)。

總結(jié)

到此這篇關(guān)于MYSQL中binlog優(yōu)化思考的文章就介紹到這了,更多相關(guān)MYSQL binlog優(yōu)化思考內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！