&nbs凌源ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)公司的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！p;   由于Mysql的事務(wù)日志包含二進制日志和存儲引擎日志，當發(fā)生崩潰恢復(fù)時，MySQL主節(jié)點通過redo log進行恢復(fù)，而在主從復(fù)制的環(huán)境下，slaver節(jié)點是依據(jù)于主節(jié)點的binlog進行同步數(shù)據(jù)的；這樣的架構(gòu)于是對mysql的二進制日志和redo log，就有兩個基本要求：第一，保證binlog里面存在的事務(wù)一定在redo log里面存在，也就是binlog里不會比redo log多事務(wù)（可以少，因為redo log里面記錄的事務(wù)可能有部分沒有commit，這些事務(wù)最終可能會被rollback）。  2、順序一致，這也是很重要的一點，假設(shè)兩者記錄的事務(wù)順序不一致，那么會出現(xiàn)類似于主庫事務(wù)執(zhí)行的順序是ta, tb, tc,td，但是binlog里面記錄的是ta,tc, tb, td，binlog復(fù)制到從庫后導(dǎo)致主從的數(shù)據(jù)不一致。為了達到上面說的兩點，mysql是怎么來實現(xiàn)的呢？沒錯，答案是內(nèi)部xa事務(wù)（核心是2pc）
一、二階段事務(wù)提交流程：
   
    (1)先調(diào)用binglog_hton和innobase_hton的prepare方法完成第一階段，binlog_hton的papare方法實際上什么也沒做，innodb的prepare將事務(wù)狀態(tài)設(shè)為TRX_PREPARED，并將redo log刷磁盤
    (2)如果事務(wù)涉及的所有存儲引擎的prepare都執(zhí)行成功，則調(diào)用TC_LOG_BINLOG::log_xid將SQL語句寫到binlog，此時，事務(wù)已經(jīng)鐵定要提交了。否則，調(diào)用ha_rollback_trans回滾事務(wù)，而SQL語句實際上也不會寫到binlog。
    (3)最后，調(diào)用引擎的commit完成事務(wù)的提交。實際上binlog_hton->commit什么也不會做(因為(2)已經(jīng)將binlog寫入磁盤)，innobase_hton->commit則清除undo信息，刷redo日志，將事務(wù)設(shè)為TRX_NOT_STARTED狀態(tài)
二、事務(wù)恢復(fù)流程：

    Innodb在恢復(fù)的時候，不同狀態(tài)的事務(wù)，會進行不同的處理(見trx_rollback_or_clean_all_without_sess函數(shù))：
<1>對于TRX_COMMITTED_IN_MEMORY的事務(wù)，清除回滾段，然后將事務(wù)設(shè)為TRX_NOT_STARTED；
<2>對于TRX_NOT_STARTED的事務(wù)，表示事務(wù)已經(jīng)提交，跳過；
<3>對于TRX_PREPARED的事務(wù)，要根據(jù)binlog來決定事務(wù)的命運，暫時跳過;
<4>對于TRX_ACTIVE的事務(wù)，回滾。
    簡單來講，當發(fā)生崩潰恢復(fù)時，數(shù)據(jù)庫根據(jù)redo log進行數(shù)據(jù)恢復(fù)，逐個查看每條redo的事務(wù)狀態(tài)，如果根據(jù)上圖流程，已進行到TRX_NOT_STARTED階段，也就是存儲引擎commit階段，那么說明redo log和bin log是一致的，正常根據(jù)redo進行恢復(fù)即可；事務(wù)狀態(tài)為TRX_ACTIVE，不用說了，都沒寫到binlog中，直接回滾；但如果事務(wù)狀態(tài)為TRX_PREPARED，就要分兩種情況了，要先檢查binlog是否已寫入成功？如果沒寫入成功，那么就算是TRX_PREPARED狀態(tài)，也要回滾。如果寫入成功了，那么就進行最后一步，調(diào)用存儲引擎commit，更改事務(wù)狀態(tài)為TRX_NOT_STARTED，也就是真正提交狀態(tài)，可以用作數(shù)據(jù)恢復(fù)。
    從以上分析可以看出，寫binlog是一定已經(jīng)提交的數(shù)據(jù)，只要寫了binlog，事務(wù)是鐵定要提交成功的。因為主從復(fù)制環(huán)境下，寫了binlog就可能直接傳輸?shù)綇墓?jié)點應(yīng)用了，所以兩階段提交很好的保持數(shù)據(jù)一致性和順序性
三、相關(guān)參數(shù)介紹：

1、innodb_support_xa
用于控制innodb是否支持XA事務(wù)的2PC，默認是TRUE。如果關(guān)閉，則innodb在prepare階段就什么也不做；這可能會導(dǎo)致binlog的順序與innodb提交的順序不一致(比如A事務(wù)比B事務(wù)先寫binlog，但是在innodb內(nèi)部卻可能A事務(wù)比B事務(wù)后提交)，這會導(dǎo)致在恢復(fù)或者slave產(chǎn)生不同的數(shù)據(jù)。
2、sync_binlog
Mysql在提交事務(wù)時調(diào)用MYSQL_LOG::write完成寫binlog，并根據(jù)sync_binlog決定是否進行刷盤。默認值是0，即不刷盤，從而把控制權(quán)讓給OS。如果設(shè)為1，則每次提交事務(wù)，就會進行一次刷盤；這對性能有影響(5.6已經(jīng)支持binlog group)，所以很多人將其設(shè)置為100。
3、innodb_flush_log_at_trx_commit
   innodb_flush_log_at_trx_commit有0、1、2三個值分別代表不同的使redo log落地策略。0表示每秒進行一次flush，但是每次事務(wù)commit不進行任何操作（每秒調(diào)用fsync使數(shù)據(jù)落地到磁盤，不過這里需要注意如果底層存儲有cache，比如raid cache，那么這時也不會真正落地，但是由于一般raid卡都帶有備用電源，所以一般都認為此時數(shù)據(jù)是安全的）。1代表每次事務(wù)提交都會進行flush，這是最安全的模式。2表示每秒flush，每次事務(wù)提交時不flush，而是調(diào)用write將redo log buffer里面的redo log刷到os page cache。
   那現(xiàn)在來比較三種策略的優(yōu)劣勢：1由于每次事務(wù)commit都會是redo log落地所以是最安全的，但是由于fsync的次數(shù)增多導(dǎo)致性能下降比較厲害。0表示每秒flush，每次事務(wù)提交不進行任何操作，所以mysql crash或者os crash時會丟失一秒的事務(wù)。2相對于0來說了多了每次事務(wù)commit時會有一次write操作，此時數(shù)據(jù)雖然沒有落地到磁盤但是只要沒有 os crash，即使mysql crash，那么事務(wù)是不會丟失的。2相對于0來說會稍微安全一點點。
       上面3個參數(shù)不同的值會帶來不同的效果。三者都設(shè)置為1(TRUE)，數(shù)據(jù)才能真正安全。sync_binlog非1，可能導(dǎo)致binlog丟失(OS掛掉)，從而與innodb層面的數(shù)據(jù)不一致。innodb_flush_log_at_trx_commit非1，可能會導(dǎo)致innodb層面的數(shù)據(jù)丟失(OS掛掉)，從而與binlog不一致

文章標題：【MYSQL】兩階段提交及相關(guān)參數(shù)介紹-創(chuàng)新互聯(lián)
當前地址：http://aaarwkj.com/article36/cchisg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、軟件開發(fā)、網(wǎng)站建設(shè)、App設(shè)計、定制開發(fā)、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)