偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

被面試官問住了,MySQL兩階段提交是什么鬼?

數(shù)據(jù)庫 MySQL
MySQL中既存在redo log,又存在bin log,這是因?yàn)锽in Log是MySQL Server提供的一種歸檔日志,其本身并不具備Crash-Safe能力。而Redo Log本身不具備歸檔能力,他是一種循環(huán)寫的日志。

前言

MySQL通過兩階段提交的機(jī)制,保證了redo log和bin log的邏輯一致性,進(jìn)而保證了數(shù)據(jù)的不丟失以及主從庫的數(shù)據(jù)一致。

而說起兩階段提交,就不得不先介紹一下redo log和bin log。

redo log

redo log即重做日志,是InnoDB引擎特有的一種日志(有的面試官經(jīng)常問到這一點(diǎn))。

redo log主要做什么呢?

以更新數(shù)據(jù)為例,我們知道,MySQL的數(shù)據(jù)是存儲(chǔ)在磁盤上的,如果每一次更新數(shù)據(jù),都去磁盤尋址找到要更新的數(shù)據(jù),進(jìn)行更新操作的話,這個(gè)IO成本是非常高的。

如果是固態(tài)硬盤還好,如果是機(jī)械硬盤,那么MySQL的更新性能根本無法滿足我們的業(yè)務(wù)需要。

所以,MySQL采用了一種叫做WAL的技術(shù),Write-Ahead Logging。

當(dāng)更新數(shù)據(jù)時(shí),將更新操作(即某個(gè)數(shù)據(jù)頁上做了什么修改)先寫到redo log里面,然后更新內(nèi)存,這個(gè)更新操作就算完成了。MySQL會(huì)在服務(wù)器空閑的時(shí)候,把redo log的操作記錄刷新到磁盤里,以保持?jǐn)?shù)據(jù)的一致性。

需要注意的是,redo log雖然也是磁盤上的一個(gè)文件,但是由于操作是順序?qū)?,所以性能是非常高的?/p>

當(dāng)然了,redo log也是有大小上限的,不可能無限制的寫入。

以上圖為例,配置了4個(gè)redo log,write pos就是代表當(dāng)前記錄寫到什么位置了,而check point表示一個(gè)推進(jìn)點(diǎn),它會(huì)不斷的前移,做擦除數(shù)據(jù)的操作,以保證redo log可以不斷的寫入。

當(dāng)然,擦除數(shù)據(jù)之前,會(huì)把redo log的記錄刷新到磁盤。

通過redo log,可以保證即使MySQL發(fā)生異常重啟,數(shù)據(jù)也不會(huì)丟失(因?yàn)閞edo log是物理日志,可以進(jìn)行重放),這個(gè)特性就叫做crash-safe。

bin log

bin log是MySQL Server提供的一種日志,叫做歸檔日志,所有引擎都可以使用bin log。

那bin log和redo log的區(qū)別是什么呢?

1,這兩種日志的提供者不同:bin log是由MySQL Server提供的,redo log是InnoDB引擎特有的。

2,redo log主要記錄的是某個(gè)數(shù)據(jù)頁做了什么修改,bin log記錄的是語句的原始邏輯,比如更新了某一行的某個(gè)字段。

3,redo log是循環(huán)寫的,數(shù)據(jù)會(huì)被覆蓋。bin log是追加寫,一個(gè)文件寫滿,就寫下一個(gè)文件。

兩階段提交

介紹完了redo log和bin log,我們?cè)倏匆幌滤麄儍烧呤侨绾闻浜贤瓿蓛呻A段提交的。

上圖就是一個(gè)更新數(shù)據(jù)的流程,可以看到,在更新一條數(shù)據(jù)之前,MySQL會(huì)先將數(shù)據(jù)加載到內(nèi)存,然后更新內(nèi)存,開始寫redo log。

此時(shí),redo log處于prepare狀態(tài),等到bin log寫完之后,再提交事務(wù),這一條記錄的更新操作就算完成了。

redo log prepare -> 寫bin log -> redo log commit,這個(gè)流程就叫做兩階段提交。

下面我們分析一下,采用兩階段提交的好處。

情景一,redo log處于prepare狀態(tài)時(shí),如果寫bin log失敗了,那么更新失敗,此時(shí)redo log沒有commit,bin log也沒有記錄,兩者的狀態(tài)是一致的,沒有問題。

情景二,redo log處于prepare狀態(tài)時(shí),寫bin log成功,但是宕機(jī)導(dǎo)致commit失敗了。此時(shí)bin log產(chǎn)生了記錄,redo log沒有寫入成功,數(shù)據(jù)暫時(shí)不一致。

但是不用擔(dān)心,當(dāng)MySQL重啟時(shí),會(huì)檢查redo log中處于prepare狀態(tài)的記錄。在redo log中,記錄了一個(gè)叫做XID的字段,這個(gè)字段在bin log中也有記錄,MySQL會(huì)通過這個(gè)XID,如果在bin log中找到了,那么就commit這個(gè)redo log,如果沒有找到,說明bin log其實(shí)沒有寫成功,就放棄提交。

通過這樣的機(jī)制,保證了redo log和bin log的一致性。

總結(jié)

之所以MySQL中既存在redo log,又存在bin log,這是因?yàn)閎in log是MySQL Server提供的一種歸檔日志,其本身并不具備crash-safe能力。而redo log本身不具備歸檔能力,他是一種循環(huán)寫的日志。

MySQL通過將這兩種日志整合起來,并通過兩階段提交的機(jī)制,保證了數(shù)據(jù)的一致性。

責(zé)任編輯:姜華 來源: 今日頭條
相關(guān)推薦

2023-12-05 09:33:08

分布式事務(wù)

2022-03-28 10:44:51

MySQL日志存儲(chǔ)

2024-12-06 07:10:00

2024-05-21 14:12:07

2020-06-22 07:47:46

提交面試官訂單

2020-08-03 07:04:54

測試面試官應(yīng)用程序

2023-11-22 09:30:50

e簽寶面試企業(yè)面經(jīng)

2025-08-04 08:05:28

2023-07-26 09:24:03

分布式事務(wù)分布式系統(tǒng)

2020-05-12 11:05:54

MySQL索引數(shù)據(jù)庫

2025-03-05 00:01:00

ReduxReact

2017-08-30 18:15:54

MySql

2018-10-29 08:44:29

分布式兩階段提交事務(wù)

2023-11-29 07:47:58

DDIA兩階段提交

2019-10-21 09:56:37

MySQLCOUNTInnoDB

2025-06-10 08:02:15

2025-09-23 07:56:31

2021-06-03 08:55:54

分布式事務(wù)ACID

2024-02-20 08:13:35

類加載引用Class

2025-06-19 08:03:03

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)