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

成都創(chuàng)新互聯(lián)主要從事網(wǎng)頁設計、PC網(wǎng)站建設（電腦版網(wǎng)站建設）、wap網(wǎng)站建設（手機版網(wǎng)站建設）、響應式網(wǎng)站建設、程序開發(fā)、網(wǎng)站優(yōu)化、微網(wǎng)站、小程序定制開發(fā)等，憑借多年來在互聯(lián)網(wǎng)的打拼，我們在互聯(lián)網(wǎng)網(wǎng)站建設行業(yè)積累了豐富的成都網(wǎng)站設計、成都網(wǎng)站制作、網(wǎng)站設計、網(wǎng)絡營銷經(jīng)驗，集策劃、開發(fā)、設計、營銷、管理等多方位專業(yè)化運作于一體。

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

到此，關于“怎么理解MarriDB/MySQL的binlog group commit技術”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
分享題目：怎么理解MarriDB/MySQL的binloggroupcommit技術
分享路徑：http://weahome.cn/article/ggcsoh.html