您好,登錄后才能下訂單哦!
這篇文章主要介紹“怎么理解MarriDB/MySQL的binlog group commit技術”,在日常操作中,相信很多人在怎么理解MarriDB/MySQL的binlog group commit技術問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”怎么理解MarriDB/MySQL的binlog group commit技術”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
我們知道,操作系統使用頁面緩存機制來填補內存訪問速度和磁盤訪問速度之間的差距。通常情況下,對磁盤文件的寫都會先寫入到頁面緩存中,
然后由操作系統來決定何時將修改過的臟頁刷新到磁盤上。如果想確保修改已經持久寫到了磁盤,必須調用fsync或fdatasync。在關系數據庫中,
為了滿足ACID中的持久化屬性,也就是說事務提交并成功返回給客戶端之后,必須保證該事務的所有修改不能丟。無論是在數據庫程序崩潰的情況下,
還是在數據庫所在的服務器發生宕機或斷電的情況下,都必須保證數據不能丟,這就要求數據庫在事務提交過程中調用fsync或fdatasync將數據持久化
到磁盤。fsync是一個昂貴的系統調用,對于普通的磁盤,每秒只能完成幾百次的fsync操作,很明顯,fsync將會限制每秒提交的事務數,成為關系
數據庫的瓶頸。
對于MarriDB/MySQL來說,這種情況變得更加糟糕。在開啟binlog的情況下,為了保證主庫和從庫之間數據的一致性,MarriDB/MySQL使用了事務的
兩階段提交協議。在這種情況下,為了滿足數據的持久化需求,一個事務的提交最多會導致3次fsync操作。
為了提高MarriDB/MySQL在開啟binlog的情況下單位時間內的事務提交數,就必須減少每個事務提交過程中導致的fsync的調用次數。MarriDB從5.3版本開始,
引入了binlog group commit技術來解決這個問題。MySQL從5.6版本開始也加入了binlog group commit技術。
binlog group commit的基本思想是多個并發提交的事務之間共用一次fsync操作來實現事務對binlog修改的持久化。
到此,關于“怎么理解MarriDB/MySQL的binlog group commit技術”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。