怎么理解MarriDB/MySQL的binlog group commit技術(shù)

這篇文章主要介紹“怎么理解MarriDB/MySQL的binlog group commit技術(shù)”，在日常操作中，相信很多人在怎么理解MarriDB/MySQL的binlog group commit技術(shù)問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么理解MarriDB/MySQL的binlog group commit技術(shù)”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

我們知道，操作系統(tǒng)使用頁面緩存機(jī)制來填補(bǔ)內(nèi)存訪問速度和磁盤訪問速度之間的差距。通常情況下，對磁盤文件的寫都會先寫入到頁面緩存中，
然后由操作系統(tǒng)來決定何時(shí)將修改過的臟頁刷新到磁盤上。如果想確保修改已經(jīng)持久寫到了磁盤，必須調(diào)用fsync或fdatasync。在關(guān)系數(shù)據(jù)庫中，
為了滿足ACID中的持久化屬性，也就是說事務(wù)提交并成功返回給客戶端之后，必須保證該事務(wù)的所有修改不能丟。無論是在數(shù)據(jù)庫程序崩潰的情況下，
還是在數(shù)據(jù)庫所在的服務(wù)器發(fā)生宕機(jī)或斷電的情況下，都必須保證數(shù)據(jù)不能丟，這就要求數(shù)據(jù)庫在事務(wù)提交過程中調(diào)用fsync或fdatasync將數(shù)據(jù)持久化
到磁盤。fsync是一個(gè)昂貴的系統(tǒng)調(diào)用，對于普通的磁盤，每秒只能完成幾百次的fsync操作，很明顯，fsync將會限制每秒提交的事務(wù)數(shù)，成為關(guān)系
數(shù)據(jù)庫的瓶頸。
對于MarriDB/MySQL來說，這種情況變得更加糟糕。在開啟binlog的情況下，為了保證主庫和從庫之間數(shù)據(jù)的一致性，MarriDB/MySQL使用了事務(wù)的
兩階段提交協(xié)議。在這種情況下，為了滿足數(shù)據(jù)的持久化需求，一個(gè)事務(wù)的提交最多會導(dǎo)致3次fsync操作。
為了提高M(jìn)arriDB/MySQL在開啟binlog的情況下單位時(shí)間內(nèi)的事務(wù)提交數(shù)，就必須減少每個(gè)事務(wù)提交過程中導(dǎo)致的fsync的調(diào)用次數(shù)。MarriDB從5.3版本開始，
引入了binlog group commit技術(shù)來解決這個(gè)問題。MySQL從5.6版本開始也加入了binlog group commit技術(shù)。
binlog group commit的基本思想是多個(gè)并發(fā)提交的事務(wù)之間共用一次fsync操作來實(shí)現(xiàn)事務(wù)對binlog修改的持久化。

到此，關(guān)于“怎么理解MarriDB/MySQL的binlog group commit技術(shù)”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！