建站
咨詢
售后
建站咨詢
新聞中心
這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案
【MYSQL】?jī)呻A段提交及相關(guān)參數(shù)介紹
由于MySQL的事務(wù)日志包含二進(jìn)制日志和存儲(chǔ)引擎日志，當(dāng)發(fā)生崩潰恢復(fù)時(shí)，MySQL主節(jié)點(diǎn)通過(guò)redo log進(jìn)行恢復(fù)，而在主從復(fù)制的環(huán)境下，slaver節(jié)點(diǎn)是依據(jù)于主節(jié)點(diǎn)的binlog進(jìn)行同步數(shù)據(jù)的；這樣的架構(gòu)于是對(duì)mysql的二進(jìn)制日志和redo log，就有兩個(gè)基本要求：第一，保證binlog里面存在的事務(wù)一定在redo log里面存在，也就是binlog里不會(huì)比redo log多事務(wù)（可以少，因?yàn)閞edo log里面記錄的事務(wù)可能有部分沒(méi)有commit，這些事務(wù)最終可能會(huì)被rollback）。 2、順序一致，這也是很重要的一點(diǎn)，假設(shè)兩者記錄的事務(wù)順序不一致，那么會(huì)出現(xiàn)類似于主庫(kù)事務(wù)執(zhí)行的順序是ta, tb, tc,td，但是binlog里面記錄的是ta,tc, tb, td，binlog復(fù)制到從庫(kù)后導(dǎo)致主從的數(shù)據(jù)不一致。為了達(dá)到上面說(shuō)的兩點(diǎn)，mysql是怎么來(lái)實(shí)現(xiàn)的呢？沒(méi)錯(cuò)，答案是內(nèi)部xa事務(wù)（核心是2pc）
一、二階段事務(wù)提交流程：
(1)先調(diào)用binglog_hton和innobase_hton的prepare方法完成第一階段，binlog_hton的papare方法實(shí)際上什么也沒(méi)做，innodb的prepare將事務(wù)狀態(tài)設(shè)為TRX_PREPARED，并將redo log刷磁盤(pán)
(2)如果事務(wù)涉及的所有存儲(chǔ)引擎的prepare都執(zhí)行成功，則調(diào)用TC_LOG_BINLOG::log_xid將SQL語(yǔ)句寫(xiě)到binlog，此時(shí)，事務(wù)已經(jīng)鐵定要提交了。否則，調(diào)用ha_rollback_trans回滾事務(wù)，而SQL語(yǔ)句實(shí)際上也不會(huì)寫(xiě)到binlog。
(3)最后，調(diào)用引擎的commit完成事務(wù)的提交。實(shí)際上binlog_hton->commit什么也不會(huì)做(因?yàn)?2)已經(jīng)將binlog寫(xiě)入磁盤(pán))，innobase_hton->commit則清除undo信息，刷redo日志，將事務(wù)設(shè)為TRX_NOT_STARTED狀態(tài)
二、事務(wù)恢復(fù)流程：
Innodb在恢復(fù)的時(shí)候，不同狀態(tài)的事務(wù)，會(huì)進(jìn)行不同的處理(見(jiàn)trx_rollback_or_clean_all_without_sess函數(shù))：
<1>對(duì)于TRX_COMMITTED_IN_MEMORY的事務(wù)，清除回滾段，然后將事務(wù)設(shè)為TRX_NOT_STARTED；
<2>對(duì)于TRX_NOT_STARTED的事務(wù)，表示事務(wù)已經(jīng)提交，跳過(guò)；
<3>對(duì)于TRX_PREPARED的事務(wù)，要根據(jù)binlog來(lái)決定事務(wù)的命運(yùn)，暫時(shí)跳過(guò);
<4>對(duì)于TRX_ACTIVE的事務(wù)，回滾。
簡(jiǎn)單來(lái)講，當(dāng)發(fā)生崩潰恢復(fù)時(shí)，數(shù)據(jù)庫(kù)根據(jù)redo log進(jìn)行數(shù)據(jù)恢復(fù)，逐個(gè)查看每條redo的事務(wù)狀態(tài)，如果根據(jù)上圖流程，已進(jìn)行到TRX_NOT_STARTED階段，也就是存儲(chǔ)引擎commit階段，那么說(shuō)明redo log和bin log是一致的，正常根據(jù)redo進(jìn)行恢復(fù)即可；事務(wù)狀態(tài)為TRX_ACTIVE，不用說(shuō)了，都沒(méi)寫(xiě)到binlog中，直接回滾；但如果事務(wù)狀態(tài)為TRX_PREPARED，就要分兩種情況了，要先檢查binlog是否已寫(xiě)入成功？如果沒(méi)寫(xiě)入成功，那么就算是TRX_PREPARED狀態(tài)，也要回滾。如果寫(xiě)入成功了，那么就進(jìn)行最后一步，調(diào)用存儲(chǔ)引擎commit，更改事務(wù)狀態(tài)為TRX_NOT_STARTED，也就是真正提交狀態(tài)，可以用作數(shù)據(jù)恢復(fù)。
從以上分析可以看出，寫(xiě)binlog是一定已經(jīng)提交的數(shù)據(jù)，只要寫(xiě)了binlog，事務(wù)是鐵定要提交成功的。因?yàn)橹鲝膹?fù)制環(huán)境下，寫(xiě)了binlog就可能直接傳輸?shù)綇墓?jié)點(diǎn)應(yīng)用了，所以兩階段提交很好的保持?jǐn)?shù)據(jù)一致性和順序性
三、相關(guān)參數(shù)介紹：
1、innodb_support_xa
用于控制innodb是否支持XA事務(wù)的2PC，默認(rèn)是TRUE。如果關(guān)閉，則innodb在prepare階段就什么也不做；這可能會(huì)導(dǎo)致binlog的順序與innodb提交的順序不一致(比如A事務(wù)比B事務(wù)先寫(xiě)binlog，但是在innodb內(nèi)部卻可能A事務(wù)比B事務(wù)后提交)，這會(huì)導(dǎo)致在恢復(fù)或者slave產(chǎn)生不同的數(shù)據(jù)。
2、sync_binlog
Mysql在提交事務(wù)時(shí)調(diào)用MYSQL_LOG::write完成寫(xiě)binlog，并根據(jù)sync_binlog決定是否進(jìn)行刷盤(pán)。默認(rèn)值是0，即不刷盤(pán)，從而把控制權(quán)讓給OS。如果設(shè)為1，則每次提交事務(wù)，就會(huì)進(jìn)行一次刷盤(pán)；這對(duì)性能有影響(5.6已經(jīng)支持binlog group)，所以很多人將其設(shè)置為100。
3、innodb_flush_log_at_trx_commit
innodb_flush_log_at_trx_commit有0、1、2三個(gè)值分別代表不同的使redo log落地策略。0表示每秒進(jìn)行一次flush，但是每次事務(wù)commit不進(jìn)行任何操作（每秒調(diào)用fsync使數(shù)據(jù)落地到磁盤(pán)，不過(guò)這里需要注意如果底層存儲(chǔ)有cache，比如raid cache，那么這時(shí)也不會(huì)真正落地，但是由于一般raid卡都帶有備用電源，所以一般都認(rèn)為此時(shí)數(shù)據(jù)是安全的）。1代表每次事務(wù)提交都會(huì)進(jìn)行flush，這是最安全的模式。2表示每秒flush，每次事務(wù)提交時(shí)不flush，而是調(diào)用write將redo log buffer里面的redo log刷到os page cache。
那現(xiàn)在來(lái)比較三種策略的優(yōu)劣勢(shì)：1由于每次事務(wù)commit都會(huì)是redo log落地所以是最安全的，但是由于fsync的次數(shù)增多導(dǎo)致性能下降比較厲害。0表示每秒flush，每次事務(wù)提交不進(jìn)行任何操作，所以mysql crash或者os crash時(shí)會(huì)丟失一秒的事務(wù)。2相對(duì)于0來(lái)說(shuō)了多了每次事務(wù)commit時(shí)會(huì)有一次write操作，此時(shí)數(shù)據(jù)雖然沒(méi)有落地到磁盤(pán)但是只要沒(méi)有 os crash，即使mysql crash，那么事務(wù)是不會(huì)丟失的。2相對(duì)于0來(lái)說(shuō)會(huì)稍微安全一點(diǎn)點(diǎn)。
上面3個(gè)參數(shù)不同的值會(huì)帶來(lái)不同的效果。三者都設(shè)置為1(TRUE)，數(shù)據(jù)才能真正安全。sync_binlog非1，可能導(dǎo)致binlog丟失(OS掛掉)，從而與innodb層面的數(shù)據(jù)不一致。innodb_flush_log_at_trx_commit非1，可能會(huì)導(dǎo)致innodb層面的數(shù)據(jù)丟失(OS掛掉)，從而與binlog不一致
文章名稱：【MYSQL】?jī)呻A段提交及相關(guān)參數(shù)介紹
本文鏈接：http://www.ef60e0e.cn/article/gehohh.html
一、二階段事務(wù)提交流程：
(1)先調(diào)用binglog_hton和innobase_hton的prepare方法完成第一階段，binlog_hton的papare方法實(shí)際上什么也沒(méi)做，innodb的prepare將事務(wù)狀態(tài)設(shè)為TRX_PREPARED，并將redo log刷磁盤(pán)
(2)如果事務(wù)涉及的所有存儲(chǔ)引擎的prepare都執(zhí)行成功，則調(diào)用TC_LOG_BINLOG::log_xid將SQL語(yǔ)句寫(xiě)到binlog，此時(shí)，事務(wù)已經(jīng)鐵定要提交了。否則，調(diào)用ha_rollback_trans回滾事務(wù)，而SQL語(yǔ)句實(shí)際上也不會(huì)寫(xiě)到binlog。
(3)最后，調(diào)用引擎的commit完成事務(wù)的提交。實(shí)際上binlog_hton->commit什么也不會(huì)做(因?yàn)?2)已經(jīng)將binlog寫(xiě)入磁盤(pán))，innobase_hton->commit則清除undo信息，刷redo日志，將事務(wù)設(shè)為TRX_NOT_STARTED狀態(tài)
二、事務(wù)恢復(fù)流程：
Innodb在恢復(fù)的時(shí)候，不同狀態(tài)的事務(wù)，會(huì)進(jìn)行不同的處理(見(jiàn)trx_rollback_or_clean_all_without_sess函數(shù))：
<1>對(duì)于TRX_COMMITTED_IN_MEMORY的事務(wù)，清除回滾段，然后將事務(wù)設(shè)為TRX_NOT_STARTED；
<2>對(duì)于TRX_NOT_STARTED的事務(wù)，表示事務(wù)已經(jīng)提交，跳過(guò)；
<3>對(duì)于TRX_PREPARED的事務(wù)，要根據(jù)binlog來(lái)決定事務(wù)的命運(yùn)，暫時(shí)跳過(guò);
<4>對(duì)于TRX_ACTIVE的事務(wù)，回滾。
簡(jiǎn)單來(lái)講，當(dāng)發(fā)生崩潰恢復(fù)時(shí)，數(shù)據(jù)庫(kù)根據(jù)redo log進(jìn)行數(shù)據(jù)恢復(fù)，逐個(gè)查看每條redo的事務(wù)狀態(tài)，如果根據(jù)上圖流程，已進(jìn)行到TRX_NOT_STARTED階段，也就是存儲(chǔ)引擎commit階段，那么說(shuō)明redo log和bin log是一致的，正常根據(jù)redo進(jìn)行恢復(fù)即可；事務(wù)狀態(tài)為TRX_ACTIVE，不用說(shuō)了，都沒(méi)寫(xiě)到binlog中，直接回滾；但如果事務(wù)狀態(tài)為TRX_PREPARED，就要分兩種情況了，要先檢查binlog是否已寫(xiě)入成功？如果沒(méi)寫(xiě)入成功，那么就算是TRX_PREPARED狀態(tài)，也要回滾。如果寫(xiě)入成功了，那么就進(jìn)行最后一步，調(diào)用存儲(chǔ)引擎commit，更改事務(wù)狀態(tài)為TRX_NOT_STARTED，也就是真正提交狀態(tài)，可以用作數(shù)據(jù)恢復(fù)。
從以上分析可以看出，寫(xiě)binlog是一定已經(jīng)提交的數(shù)據(jù)，只要寫(xiě)了binlog，事務(wù)是鐵定要提交成功的。因?yàn)橹鲝膹?fù)制環(huán)境下，寫(xiě)了binlog就可能直接傳輸?shù)綇墓?jié)點(diǎn)應(yīng)用了，所以兩階段提交很好的保持?jǐn)?shù)據(jù)一致性和順序性
三、相關(guān)參數(shù)介紹：
1、innodb_support_xa
用于控制innodb是否支持XA事務(wù)的2PC，默認(rèn)是TRUE。如果關(guān)閉，則innodb在prepare階段就什么也不做；這可能會(huì)導(dǎo)致binlog的順序與innodb提交的順序不一致(比如A事務(wù)比B事務(wù)先寫(xiě)binlog，但是在innodb內(nèi)部卻可能A事務(wù)比B事務(wù)后提交)，這會(huì)導(dǎo)致在恢復(fù)或者slave產(chǎn)生不同的數(shù)據(jù)。
2、sync_binlog
Mysql在提交事務(wù)時(shí)調(diào)用MYSQL_LOG::write完成寫(xiě)binlog，并根據(jù)sync_binlog決定是否進(jìn)行刷盤(pán)。默認(rèn)值是0，即不刷盤(pán)，從而把控制權(quán)讓給OS。如果設(shè)為1，則每次提交事務(wù)，就會(huì)進(jìn)行一次刷盤(pán)；這對(duì)性能有影響(5.6已經(jīng)支持binlog group)，所以很多人將其設(shè)置為100。
3、innodb_flush_log_at_trx_commit
innodb_flush_log_at_trx_commit有0、1、2三個(gè)值分別代表不同的使redo log落地策略。0表示每秒進(jìn)行一次flush，但是每次事務(wù)commit不進(jìn)行任何操作（每秒調(diào)用fsync使數(shù)據(jù)落地到磁盤(pán)，不過(guò)這里需要注意如果底層存儲(chǔ)有cache，比如raid cache，那么這時(shí)也不會(huì)真正落地，但是由于一般raid卡都帶有備用電源，所以一般都認(rèn)為此時(shí)數(shù)據(jù)是安全的）。1代表每次事務(wù)提交都會(huì)進(jìn)行flush，這是最安全的模式。2表示每秒flush，每次事務(wù)提交時(shí)不flush，而是調(diào)用write將redo log buffer里面的redo log刷到os page cache。
那現(xiàn)在來(lái)比較三種策略的優(yōu)劣勢(shì)：1由于每次事務(wù)commit都會(huì)是redo log落地所以是最安全的，但是由于fsync的次數(shù)增多導(dǎo)致性能下降比較厲害。0表示每秒flush，每次事務(wù)提交不進(jìn)行任何操作，所以mysql crash或者os crash時(shí)會(huì)丟失一秒的事務(wù)。2相對(duì)于0來(lái)說(shuō)了多了每次事務(wù)commit時(shí)會(huì)有一次write操作，此時(shí)數(shù)據(jù)雖然沒(méi)有落地到磁盤(pán)但是只要沒(méi)有 os crash，即使mysql crash，那么事務(wù)是不會(huì)丟失的。2相對(duì)于0來(lái)說(shuō)會(huì)稍微安全一點(diǎn)點(diǎn)。
上面3個(gè)參數(shù)不同的值會(huì)帶來(lái)不同的效果。三者都設(shè)置為1(TRUE)，數(shù)據(jù)才能真正安全。sync_binlog非1，可能導(dǎo)致binlog丟失(OS掛掉)，從而與innodb層面的數(shù)據(jù)不一致。innodb_flush_log_at_trx_commit非1，可能會(huì)導(dǎo)致innodb層面的數(shù)據(jù)丟失(OS掛掉)，從而與binlog不一致
文章名稱：【MYSQL】?jī)呻A段提交及相關(guān)參數(shù)介紹
本文鏈接：http://www.ef60e0e.cn/article/gehohh.html
