MySQL組提交group?commit實(shí)例分析

今天小編給大家分享一下MySQL組提交group commit實(shí)例分析的相關(guān)知識(shí)點(diǎn)，內(nèi)容詳細(xì)，邏輯清晰，相信大部分人都還太了解這方面的知識(shí)，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來(lái)了解一下吧。

引 言

前提：

• 以下討論的前提 是設(shè)置MySQL的crash safe相關(guān)參數(shù)為雙1：

sync_binlog=1

innodb_flush_log_at_trx_commit=1

背景說(shuō)明：

• WAL機(jī)制 (Write Ahead Log)定義: WAL指的是對(duì)數(shù)據(jù)文件進(jìn)行修改前，必須將修改先記錄日志。MySQL為了保證ACID中的一致性和持久性，使用了WAL。

• Redo log的作用: Redo log就是一種WAL的應(yīng)用。當(dāng)數(shù)據(jù)庫(kù)忽然掉電，再重新啟動(dòng)時(shí)，MySQL可以通過(guò)Redo log還原數(shù)據(jù)。也就是說(shuō)，每次事務(wù)提交時(shí)，不用同步刷新磁盤(pán)數(shù)據(jù)文件，只需要同步刷新Redo log就足夠了。相比寫(xiě)數(shù)據(jù)文件時(shí)的隨機(jī)IO，寫(xiě)Redo log時(shí)的順序IO能夠提高事務(wù)提交速度。

• 組提交的作用:

• 在沒(méi)有開(kāi)啟binlog時(shí)

Redo log的刷盤(pán)操作將會(huì)是最終影響MySQL TPS的瓶頸所在。為了緩解這一問(wèn)題，MySQL使用了組提交，將多個(gè)刷盤(pán)操作合并成一個(gè)，如果說(shuō)10個(gè)事務(wù)依次排隊(duì)刷盤(pán)的時(shí)間成本是10，那么將這10個(gè)事務(wù)一次性一起刷盤(pán)的時(shí)間成本則近似于1。

• 當(dāng)開(kāi)啟binlog時(shí)

為了保證Redo log和binlog的數(shù)據(jù)一致性，MySQL使用了二階段提交，由binlog作為事務(wù)的協(xié)調(diào)者。而 引入二階段提交 使得binlog又成為了性能瓶頸，先前的Redo log 組提交 也成了擺設(shè)。為了再次緩解這一問(wèn)題，MySQL增加了binlog的組提交，目的同樣是將binlog的多個(gè)刷盤(pán)操作合并成一個(gè)，結(jié)合Redo log本身已經(jīng)實(shí)現(xiàn)的 組提交，分為三個(gè)階段(Flush 階段、Sync 階段、Commit 階段)完成binlog 組提交，最大化每次刷盤(pán)的收益，弱化磁盤(pán)瓶頸，提高性能。

圖解：

下圖我們假借“渡口運(yùn)輸”的例子來(lái)看看binlog 組提交三個(gè)階段的流程：

在MySQL中每個(gè)階段都有一個(gè)隊(duì)列，每個(gè)隊(duì)列都有一把鎖保護(hù)，第一個(gè)進(jìn)入隊(duì)列的事務(wù)會(huì)成為leader，leader領(lǐng)導(dǎo)所在隊(duì)列的所有事務(wù)，全權(quán)負(fù)責(zé)整隊(duì)的操作，完成后通知隊(duì)內(nèi)其他事務(wù)操作結(jié)束。

Flush 階段 (圖中第一個(gè)渡口)

• 首先獲取隊(duì)列中的事務(wù)組

• 將Redo log中prepare階段的數(shù)據(jù)刷盤(pán)(圖中Flush Redo log)

• 將binlog數(shù)據(jù)寫(xiě)入文件，當(dāng)然此時(shí)只是寫(xiě)入文件系統(tǒng)的緩沖，并不能保證數(shù)據(jù)庫(kù)崩潰時(shí)binlog不丟失 (圖中Write binlog)

• Flush階段隊(duì)列的作用是提供了Redo log的組提交

• 如果在這一步完成后數(shù)據(jù)庫(kù)崩潰，由于協(xié)調(diào)者binlog中不保證有該組事務(wù)的記錄，所以MySQL可能會(huì)在重啟后回滾該組事務(wù)

Sync 階段 (圖中第二個(gè)渡口)

• 這里為了增加一組事務(wù)中的事務(wù)數(shù)量，提高刷盤(pán)收益，MySQL使用兩個(gè)參數(shù)控制獲取隊(duì)列事務(wù)組的時(shí)機(jī)：

binlog_group_commit_sync_delay=N：在等待N μs后，開(kāi)始事務(wù)刷盤(pán)(圖中Sync binlog)

binlog_group_commit_sync_no_delay_count=N：如果隊(duì)列中的事務(wù)數(shù)達(dá)到N個(gè)，就忽視binlog_group_commit_sync_delay的設(shè)置，直接開(kāi)始刷盤(pán)(圖中Sync binlog)

• Sync階段隊(duì)列的作用是支持binlog的組提交

• 如果在這一步完成后數(shù)據(jù)庫(kù)崩潰，由于協(xié)調(diào)者binlog中已經(jīng)有了事務(wù)記錄，MySQL會(huì)在重啟后通過(guò)Flush 階段中Redo log刷盤(pán)的數(shù)據(jù)繼續(xù)進(jìn)行事務(wù)的提交

Commit 階段 (圖中第三個(gè)渡口)

• 首先獲取隊(duì)列中的事務(wù)組

• 依次將Redo log中已經(jīng)prepare的事務(wù)在引擎層提交(圖中InnoDB Commit)

• Commit階段不用刷盤(pán)，如上所述，F(xiàn)lush階段中的Redo log刷盤(pán)已經(jīng)足夠保證數(shù)據(jù)庫(kù)崩潰時(shí)的數(shù)據(jù)安全了

• Commit階段隊(duì)列的作用是承接Sync階段的事務(wù)，完成最后的引擎提交，使得Sync可以盡早的處理下一組事務(wù)，最大化組提交的效率

以上就是“MySQL組提交group commit實(shí)例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會(huì)為大家更新不同的知識(shí)，如果還想學(xué)習(xí)更多的知識(shí)，請(qǐng)關(guān)注億速云行業(yè)資訊頻道。