資訊專欄INFORMATION COLUMN
對于支持事務的關(guān)系型數(shù)據(jù)庫來說，事務的完成需要執(zhí)行commit命令，用于保存該事務操作的相關(guān)日志、標記該事務已完成，確保數(shù)據(jù)的一致性。通常情況下，commit命令執(zhí)行很快，但也會存在commit是性能瓶頸，影響整體數(shù)據(jù)庫性能的情況發(fā)生。
慢日志分析
| |
對慢日志分析可見，commit操作平均耗時近1分鐘是非正常現(xiàn)象。
MySQL commit機制
mysql數(shù)據(jù)庫為了保證binlog、redolog中事務的一致性，事務采用了兩階段提交（2pc）機制：
prepare階段
innodb write/sync事務redo、undolog，binlog不做任何操作。
commit階段
mysql層write/syncbinlog，innodb寫 commit 至redolog。
從這個機制可以看出，commit操作包括binlog的落地動作。這就延長了commit動作的時間，也成了一個性能瓶頸，為了優(yōu)化這一性能問題，mysql5.6推出了組提交機制。
binlog組提交的基本思想是，引入隊列機制保證innodb commit順序與binlog落盤順序一致，并將事務分組，組內(nèi)的binlog刷盤動作交給一個事務進行，實現(xiàn)組提交目的。
binlog提交將提交分為了3個階段，F(xiàn)LUSH階段，SYNC階段和COMMIT階段?；玖鞒倘缦拢?/span>
FLUSH 階段
持有Lock_log mutex [leader持有，follower等待]
獲取隊列中的一組binlog(隊列中的所有事務)
將binlog buffer到I/O cache
通知dump線程dump binlog
SYNC階段
釋放Lock_log mutex，持有Lock_sync mutex[leader持有，follower等待]
將一組binlog 落盤(sync動作，最耗時，假設sync_binlog為1)
COMMIT階段
釋放Lock_sync mutex，持有Lock_commit mutex[leader持有，follower等待]
遍歷隊列中的事務，逐一進行innodb commit
釋放Lock_commit mutex
喚醒隊列中等待的線程
組提交就是每次sync一組binlog，從而提升效率，而一組binlog的數(shù)量則由以下兩個參數(shù)決定：
binlog_group_commit_sync_delay=N：在等待N μs后，開始事務刷盤
binlog_group_commit_sync_no_delay_count=N：如果隊列中的事務數(shù)達到N個，就忽視binlog_group_commit_sync_delay的設置
| 參數(shù)名 | 參數(shù)值 |
| sync_binlog | 1 |
| binlog_group_commit_sync_delay | 1 |
| binlog_group_commit_sync_no_delay_count | 1000 |
以上參數(shù)為故障發(fā)生時數(shù)據(jù)庫的參數(shù)設置，可以看binlog_group_commit_sync_delay設置為1微妙，即1微妙內(nèi)sync一組binlog，這對于高并發(fā)的dml操作而言對IO壓力相對比較大；sync_binlog參數(shù)在組提交機制下其意義也發(fā)生了變化，官方文檔如下：
| |
當sync_binlog設置為0或1時，binlog_group_commit_sync_delay時間后sync一組binlog；當sync_binlog設置N(N>1)時binlog_group_commit_sync_delay時間后syncN組binlog。
所以整體上看，故障發(fā)生時有大量的dml操作，且因為數(shù)據(jù)庫的參數(shù)設置1微妙sync一組binlog，對IO造成了很大壓力，再加上同時有大量的select查詢，此刻IO已經(jīng)達到極限，最終造成commit提交阻塞，事務不能及時釋放資源，其它dml操作因不能及時獲取事務鎖、io等資源而延長執(zhí)行時間。
由于數(shù)據(jù)庫設置為1微妙sync一組binlog，在大并發(fā)dml操作時對IO造成很大壓力，造成commit阻塞和其它dml操作執(zhí)行延長。由于binlog的sync操作代價相對較高，因此可以增加每組binlog的數(shù)量、每次syncbinlog組的數(shù)量，減輕對IO的壓力。
設置sync_binlog為1，則commit操作需要等待binlog_group_commit_sync_delay時間才能完成，阻塞了commit操作，設置太大的值（如：1000），則一次syncbinlog量比較大，很容易造成IO波動，如果存大大事務，則IO波動會更大。
binlog_group_commit_sync_delay設置太小，則每組中binlog數(shù)量較小，起不到組提交帶來的性能優(yōu)化，設置太大則阻塞了commit操作很長時間且binlog事務太大。
binlog_group_commit_sync_delay最好設置為10的倍數(shù)，不然會引起如下bug：
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/130192.html
摘要：隔離級別個等級的事務隔離級別，在相同的數(shù)據(jù)環(huán)境下，使用相同的輸入，執(zhí)行相同的工作，根據(jù)不同的隔離級別，可以導致不同的結(jié)果。不同事務隔離級別能夠解決的數(shù)據(jù)并發(fā)問題的能力是不同的。 Java知識點總結(jié)（JDBC-事務） @(Java知識點總結(jié))[Java, JDBC] 事務 事務基本概念 一組要么同時執(zhí)行成功，要么同時執(zhí)行失敗的 SQL 語句。是數(shù)據(jù)庫操作的一個執(zhí)行單元！ 事務開始于：...
摘要：一致性一個事務中，事務前后數(shù)據(jù)的完整性必須保持一致。持久性持久性是指一個事務一旦被提交，它對數(shù)據(jù)庫中數(shù)據(jù)的改變就是永久性的，接下來即使數(shù)據(jù)庫發(fā)生故障也不應該對其有任何影響。 一、事務概述1．什么是事務一件事情有n個組成單元 要不這n個組成單元同時成功 要不n個單元就同時失敗就是將n個組成單元放到一個事務中2．mysql的事務默認的事務：一條sql語句就是一個事務 默認就開啟事務并提交事...
摘要：今天對象在學習時發(fā)現(xiàn)對象的方法并不能清理一級緩存同一下相同查詢條件返回的結(jié)果還是舊值。測試代碼如下上網(wǎng)搜索網(wǎng)上搜索找到了相同問題并沒有人解答。例如查看官方文檔實例有一個本地緩存在執(zhí)行和時被清理。要明確地關(guān)閉它獲取打算做更多的工作你可以調(diào)用。 今天對象在學習 Mybatis 時發(fā)現(xiàn) org.apache.ibatis.session.SqlSession 對象的 clearCache()...
閱讀 1356·2023-01-11 13:20
閱讀 1707·2023-01-11 13:20
閱讀 1215·2023-01-11 13:20
閱讀 1906·2023-01-11 13:20
閱讀 4165·2023-01-11 13:20
閱讀 2757·2023-01-11 13:20
閱讀 1402·2023-01-11 13:20
閱讀 3671·2023-01-11 13:20
