更新時間:2021-01-22 17:47:12 來源:動力節(jié)點 瀏覽1146次
所謂MySQL事務(wù)持久性就是事務(wù)一旦提交,就是永久性的,不會因為宕機等故障導(dǎo)致數(shù)據(jù)丟失(外力影響不保證,比如磁盤損害)。持久性是保證了MySQL數(shù)據(jù)庫的高可靠性(High Reliability),而不是高可用性(Hign Availability)。
MySQL的innoDB存儲引擎,使用Redo log保證了事務(wù)的持久性。當事務(wù)提交時,必須先將事務(wù)的所有日志寫入日志文件進行持久化,就是我們常說的WAL(write ahead log)機制。這樣才能保證斷電或宕機等情況發(fā)生后,已提交的事務(wù)不會丟失,這個能力稱為 crash-safe。
Redo log包括兩部分,重做日志緩沖(redo log buffer)和重做日志文件(redo log file),前者是易失的緩存,后者是持久化的文件。
舉一個事務(wù)的例子:
步驟1:begin;
步驟2:insert into t1 …r
步驟3:insert into t2 …
步驟4:commit;
這個事務(wù)的寫入過程實際拆解如下:
重點關(guān)注在這個事務(wù)提交前,將redo log的寫入拆成了兩個步驟,prepare 和 commit,這就是"兩階段提交”。那么為什么要采用兩階段提交呢?
實際上,兩階段提交是分布式系統(tǒng)常用的機制。MySQL使用了兩階段提交后,也是為了保證事務(wù)的持久性。Redo log 和bingo 有一個共同的數(shù)據(jù)字段,叫 XID,崩潰恢復(fù)的時候,會按順序掃描 redo log。
假設(shè)在寫入binlog前系統(tǒng)崩潰,那么數(shù)據(jù)庫恢復(fù)后順序掃描 redo log,碰到只有 parepare、而沒有 commit 的 redo log,就拿著 XID 去 binlog 找對應(yīng)的事務(wù),而且binlog也沒寫入,所以事務(wù)就直接回滾了。
假設(shè)在寫入binlog之后,事務(wù)提交前數(shù)據(jù)庫崩潰,那么數(shù)據(jù)庫恢復(fù)后順序掃描 redo log,碰到既有 prepare、又有 commit 的 redo log,就直接提交,保證數(shù)據(jù)不丟失。
這個事務(wù)要往兩個表中插入記錄,插入數(shù)據(jù)的過程中,生成的日志都得先寫入redo log buffer ,等到commit的時候,才真正把日志寫到 redo log 文件。(當然,這里不絕對,因為redo log buffer可能因為其他原因被迫刷新到redo log)。
而為了確保每次日志都能寫入日志文件,在每次將重做日志緩沖寫入重做日志文件后,InnoDB存儲引擎都需要調(diào)用一次fsync操作,確保寫入了磁盤。
對于redo log的持久化,可以如下圖所示。
1)先寫入redo log buffer,在藍色區(qū)域。
2)寫入redo log file,但是還沒有fsync,這時候是處于黃色的位置,處于系統(tǒng)緩存。
3)調(diào)用fsync,真正寫入磁盤。
為了控制 redo log 的寫入策略,InnoDB 提供了 innodb_flush_log_at_trx_commit 參數(shù),它有三種可能取值:
設(shè)置為 0 的時候,表示每次事務(wù)提交時都只是把 redo log 留在 redo log buffer 中 ;
設(shè)置為 1 的時候,表示每次事務(wù)提交時都將 redo log 直接持久化到磁盤;
設(shè)置為 2 的時候,表示每次事務(wù)提交時都只是把 redo log 寫到 page cache。
binlog的寫入和redo log一樣,也是包括bingo cache和bingo file,同樣跟上面的三色層次類似(當然,binlog是server層的,不是存儲引擎層的),包括log buffer、文件系統(tǒng)page cache、hard disk。
寫入page cache 和 fsync到disk 的時機,是由參數(shù) sync_binlog 控制的:
sync_binlog=0 的時候,表示每次提交事務(wù)都只 寫入文件系統(tǒng)的page cache,不 fsync;
sync_binlog=1 的時候,表示每次提交事務(wù)都會執(zhí)行 fsync;
sync_binlog=N(N>1) 的時候,表示每次提交事務(wù)都寫入文件系統(tǒng)的page cache,但累積 N 個事務(wù)后才 fsync。(如果主機發(fā)生異常重啟,會丟失最近 N 個事務(wù)的 binlog 日志)
通常我們說MySQL的“雙 1”配置,指的就是sync_binlog和 innodb_flush_log_at_trx_commit 都設(shè)置成 1。也就是說,一個事務(wù)完整提交前,需要等待兩次刷盤,一次是 redo log(prepare 階段),一次是 binlog。
以上就是MySQL的innoDB存儲引擎,使用Redo log實現(xiàn)了MySQL事務(wù)持久性。除此之外,MySQL事務(wù)的其他特性也有著各自各樣的機制來實現(xiàn),詳情可以觀看本站的MySQL教程,展開拓展性的學(xué)習(xí)。
初級 202925
初級 203221
初級 202629
初級 203743