Mysql篇-三大日志

概述

• undo log（回滾日志）：是 Innodb 存儲(chǔ)引擎層生成的日志，實(shí)現(xiàn)了事務(wù)中的 原子性 ，主要用于事務(wù)回滾和 MVCC。
• redo log（重做日志）：是 Innodb 存儲(chǔ)引擎層生成的日志，實(shí)現(xiàn)了事務(wù)中的 持久性 ，主要用于掉電等故障恢復(fù)；
• binlog （歸檔日志）：是 Server 層生成的日志，主要用于數(shù)據(jù)備份和主從復(fù)制；

回滾日志（undo log）

作用

• 保存了事務(wù)發(fā)生之前的數(shù)據(jù)的一個(gè)版本，可以用于回滾，保障原子性
• 實(shí)現(xiàn)多版本并發(fā)控制下的讀（MVCC）的關(guān)鍵因素之一，也即非鎖定讀，MVCC通過(guò)Read View + undolog的版本鏈實(shí)現(xiàn)，可以具體看 MVCC的快照讀

內(nèi)容

邏輯格式的日志，在執(zhí)行 undo 的時(shí)候，僅僅是將數(shù)據(jù)從邏輯上恢復(fù)至事務(wù)之前的狀態(tài)，而不是從物理頁(yè)面上操作實(shí)現(xiàn)的，這一點(diǎn)是不同于redo log 的。

每當(dāng) InnoDB 引擎對(duì)一條記錄進(jìn)行操作（修改、刪除、新增）時(shí)，要把回滾時(shí)需要的信息都記錄到 undo log 里，比如：

• 在 插入insert 一條記錄時(shí)，要把這條記錄的主鍵值記下來(lái)，這樣之后回滾時(shí)只需要把這個(gè)主鍵值對(duì)應(yīng)的 記錄刪掉delete 就好了；
• 在 刪除delete 一條記錄時(shí)，要把這條記錄中的內(nèi)容都記下來(lái)，這樣之后回滾時(shí)再把由這些內(nèi)容組成的 記錄插入insert 到表中就好了；
• 在 更新 一條記錄時(shí)，要把被更新的列的舊值記下來(lái)，這樣之后回滾時(shí)再把這些列 更新為舊值 就好了。

什么時(shí)候產(chǎn)生

事務(wù)開(kāi)始之前 ，MySQL 會(huì)先記錄更新前的數(shù)據(jù)到 undo log 日志文件里面，當(dāng)事務(wù)回滾時(shí)，可以利用 undo log 來(lái)進(jìn)行回滾。同時(shí)undo 也會(huì)產(chǎn)生 redo 來(lái)保證undo log的可靠性。

什么時(shí)候刷盤(pán)

undo log 和數(shù)據(jù)頁(yè)的刷盤(pán)策略是一樣的，都需要通過(guò) redo log 保證持久化。產(chǎn)生undo日志的時(shí)候，同樣會(huì)伴隨類似于保護(hù)事務(wù)持久化機(jī)制的redolog的產(chǎn)生。

buffer pool 中有 undo 頁(yè)，對(duì) undo 頁(yè)的修改也都會(huì)記錄到 redo log。redo log 會(huì)每秒刷盤(pán)，提交事務(wù)時(shí)也會(huì)刷盤(pán)，數(shù)據(jù)頁(yè)和 undo 頁(yè)都是靠這個(gè)機(jī)制保證持久化的，具體看下面內(nèi)容。

重做日志（redo log）

作用

• 確保事務(wù)的持久性。
  • 為了防止斷電導(dǎo)致數(shù)據(jù)丟失的問(wèn)題，當(dāng)有一條記錄需要更新的時(shí)候，InnoDB 引擎就會(huì)先更新內(nèi)存（同時(shí)標(biāo)記為臟頁(yè)），然后將本次對(duì)這個(gè)頁(yè)的修改以 redo log 的形式記錄下來(lái)，這個(gè)時(shí)候更新就算完成了。也就是說(shuō)， redo log 是為了防止 Buffer Pool 中的臟頁(yè)丟失而設(shè)計(jì)的。
  • 在重啟mysql服務(wù)的時(shí)候，根據(jù)redo log進(jìn)行重做，從而達(dá)到事務(wù)的持久性這一特性。
• 將寫(xiě)操作從「隨機(jī)寫(xiě)」變成了「順序?qū)憽梗�提�?MySQL 寫(xiě)入磁盤(pán)的性能。

內(nèi)容

物理格式的日志，記錄的是物理數(shù)據(jù)頁(yè)面的修改的信息，其 redo log 是順序?qū)懭雛edo log file 的物理文件中去的。同時(shí)，在內(nèi)存修改 Undo log 后，也需要記錄undo log對(duì)應(yīng)的 redo log。

redo log 和 undo log 區(qū)別:

• redo log 記錄了此次事務(wù) 完成后 的數(shù)據(jù)狀態(tài)，記錄的是更新之后的值；
• undo log 記錄了此次事務(wù) 開(kāi)始前 的數(shù)據(jù)狀態(tài)，記錄的是更新之前的值；

什么時(shí)候產(chǎn)生

事務(wù)開(kāi)始之后就產(chǎn)生redo log，redo log的落盤(pán)并不是隨著事務(wù)的提交才寫(xiě)入的，而是在事務(wù)的執(zhí)行過(guò)程中，便開(kāi)始寫(xiě)入redo log文件中。

事務(wù)提交之前發(fā)生了崩潰，重啟后會(huì)通過(guò) undo log 回滾事務(wù)，事務(wù)提交之后發(fā)生了崩潰，重啟后會(huì)通過(guò) redo log 恢復(fù)事務(wù)，如下圖：

redo log 要寫(xiě)到磁盤(pán)，數(shù)據(jù)也要寫(xiě)磁盤(pán)，為什么要多此一舉？

寫(xiě)入 redo log 的方式使用了追加操作， 所以磁盤(pán)操作是順序?qū)�，而�?xiě)入數(shù)據(jù)需要先找到寫(xiě)入位置，然后才寫(xiě)到磁盤(pán)，所以磁盤(pán)操作是隨機(jī)寫(xiě)。磁盤(pán)的「順序?qū)?」比「隨機(jī)寫(xiě)」 高效的多，因此 redo log 寫(xiě)入磁盤(pán)的開(kāi)銷更小。

什么時(shí)候刷盤(pán)

實(shí)際上， 執(zhí)行一個(gè)事務(wù)的過(guò)程中，產(chǎn)生的 redo log 也不是直接寫(xiě)入磁盤(pán)的，因?yàn)檫@樣會(huì)產(chǎn)生大量的 I/O 操作，而且磁盤(pán)的運(yùn)行速度遠(yuǎn)慢于內(nèi)存。

redo log有一個(gè)緩存區(qū) Innodb_log_buffer，Innodb_log_buffer 的默認(rèn)大小為 16M，每當(dāng)產(chǎn)生一條 redo log 時(shí)，會(huì)先寫(xiě)入到 redo log buffer，后續(xù)再持久化到磁盤(pán)。

然后會(huì)通過(guò)以下三種方式將innodb log buffer的日志刷新到磁盤(pán):

• MySQL 正常關(guān)閉時(shí)；
• 當(dāng) redo log buffer 中記錄的寫(xiě)入量大于 redo log buffer 內(nèi)存空間的一半時(shí)，會(huì)觸發(fā)落盤(pán)；
• InnoDB 的后臺(tái)線程每隔 1 秒，將 redo log buffer 持久化到磁盤(pán)。
• 每次事務(wù)提交時(shí)都將緩存在 redo log buffer 里的 redo log 直接持久化到磁盤(pán)。

因此redo log buffer的寫(xiě)盤(pán)，并不一定是隨著事務(wù)的提交才寫(xiě)入redo log文件的，而是隨著事務(wù)的開(kāi)始，逐步開(kāi)始的。

即使某個(gè)事務(wù)還沒(méi)有提交，Innodb存儲(chǔ)引擎仍然每秒會(huì)將redo log buffer刷新到redo log文件。

這一點(diǎn)是必須要知道的，因?yàn)檫@可以很好地解釋再大的事務(wù)的提交（commit）的時(shí)間也是很短暫的。

redolog的文件

兩個(gè) redo 日志的文件名叫 ：ib_logfile0 和 ib_logfile1。

redo log文件組是以循環(huán)寫(xiě)的方式工作的， InnoDB 存儲(chǔ)引擎會(huì)先寫(xiě) ib_logfile0 文件，當(dāng) ib_logfile0 文件被寫(xiě)滿的時(shí)候，會(huì)切換至 ib_logfile1 文件，當(dāng) ib_logfile1 文件也被寫(xiě)滿時(shí)，會(huì)切換回 ib_logfile0 文件；相當(dāng)于一個(gè)環(huán)形。

• write pos 和 checkpoint 的移動(dòng)都是順時(shí)針?lè)较颍?
• write pos ～ checkpoint 之間的部分（圖中的紅色部分），用來(lái)記錄新的更新操作；
• check point ～ write pos 之間的部分（圖中藍(lán)色部分）：待落盤(pán)的臟數(shù)據(jù)頁(yè)記錄；

因此，如果 write pos 追上了 checkpoint，就意味著 redo log 文件滿了，這時(shí) MySQL 不能再執(zhí)行新的更新操作，也就是說(shuō) MySQL 會(huì)被阻塞

二進(jìn)制日志（binlog）

作用

• 用于復(fù)制，在主從復(fù)制中，從庫(kù)利用主庫(kù)上的binlog進(jìn)行重放，實(shí)現(xiàn)主從同步。
• 用于數(shù)據(jù)庫(kù)的基于時(shí)間點(diǎn)的還原，即備份恢復(fù)

內(nèi)容

binlog 有 3 種格式類型，分別是 STATEMENT（默認(rèn)格式）、ROW、 MIXED，區(qū)別如下：

• STATEMENT：每一條修改數(shù)據(jù)的 SQL 都會(huì)被記錄到 binlog 中（相當(dāng)于記錄了邏輯操作，所以針對(duì)這種格式， binlog 可以稱為邏輯日志），主從復(fù)制中 slave 端再根據(jù) SQL 語(yǔ)句重現(xiàn)。但 STATEMENT 有動(dòng)態(tài)函數(shù)的問(wèn)題，比如你用了 uuid 或者 now 這些函數(shù)，你在主庫(kù)上執(zhí)行的結(jié)果并不是你在從庫(kù)執(zhí)行的結(jié)果，這種隨時(shí)在變的函數(shù)會(huì)導(dǎo)致復(fù)制的數(shù)據(jù)不一致；
• ROW：記錄行數(shù)據(jù)最終被修改成什么樣了（這種格式的日志，就不能稱為邏輯日志了），不會(huì)出現(xiàn) STATEMENT 下動(dòng)態(tài)函數(shù)的問(wèn)題。但 ROW 的缺點(diǎn)是每行數(shù)據(jù)的變化結(jié)果都會(huì)被記錄，比如執(zhí)行批量 update 語(yǔ)句，更新多少行數(shù)據(jù)就會(huì)產(chǎn)生多少條記錄，使 binlog 文件過(guò)大，而在 STATEMENT 格式下只會(huì)記錄一個(gè) update 語(yǔ)句而已；
• MIXED：包含了 STATEMENT 和 ROW 模式，它會(huì)根據(jù)不同的情況自動(dòng)使用 ROW 模式和 STATEMENT 模式；

注意：不同的日志類型在主從復(fù)制下除了有動(dòng)態(tài)函數(shù)的問(wèn)題，同樣對(duì)對(duì)更新時(shí)間也有影響。一般來(lái)說(shuō)，數(shù)據(jù)庫(kù)中的update_time都會(huì)設(shè)置成ON UPDATE CURRENT_TIMESTAMP，即自動(dòng)更新時(shí)間戳列。在主從復(fù)制下，
如果日志格式類型是STATEMENT，由于記錄的是sql語(yǔ)句，在salve端是進(jìn)行語(yǔ)句重放，那么更新時(shí)間也是重放時(shí)的時(shí)間，此時(shí)slave會(huì)有時(shí)間延遲的問(wèn)題；
如果日志格式類型是ROW，這是記錄行數(shù)據(jù)最終被修改成什么樣了，這種從庫(kù)的數(shù)據(jù)是與主服務(wù)器完全一致的。

什么時(shí)候產(chǎn)生

事務(wù) 提交的時(shí)候 ，一次性將事務(wù)中的sql語(yǔ)句（一個(gè)事物可能對(duì)應(yīng)多個(gè)sql語(yǔ)句）按照一定的格式記錄到binlog中。

binlog 文件是記錄了所有數(shù)據(jù)庫(kù)表結(jié)構(gòu)變更和表數(shù)據(jù)修改的日志，不會(huì)記錄查詢類的操作，比如 SELECT 和 SHOW 操作。

這里與redo log很明顯的差異就是binlog 是追加寫(xiě)，寫(xiě)滿一個(gè)文件，就創(chuàng)建一個(gè)新的文件繼續(xù)寫(xiě)，不會(huì)覆蓋以前的日志，保存的是全量的日志。redo log 是循環(huán)寫(xiě)，日志空間大小是固定，全部寫(xiě)滿就從頭開(kāi)始，保存未被刷入磁盤(pán)的臟頁(yè)日志。

也就是說(shuō)，如果不小心整個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)被刪除了，只能使用 bin log 文件恢復(fù)數(shù)據(jù)。因?yàn)閞edo log循環(huán)寫(xiě)會(huì)擦除數(shù)據(jù)。

主從復(fù)制的實(shí)現(xiàn)

MySQL 的主從復(fù)制依賴于 binlog ，也就是記錄 MySQL 上的所有變化并以二進(jìn)制形式保存在磁盤(pán)上。復(fù)制的過(guò)程就是將 binlog 中的數(shù)據(jù)從主庫(kù)傳輸?shù)綇膸?kù)上。

這個(gè)過(guò)程一般是異步的，也就是主庫(kù)上執(zhí)行事務(wù)操作的線程不會(huì)等待復(fù)制 binlog 的線程同步完成。

MySQL 集群的主從復(fù)制過(guò)程如下：

• 寫(xiě)入 Binlog：MySQL 主庫(kù)在收到客戶端提交事務(wù)的請(qǐng)求之后，會(huì)先寫(xiě)入 binlog，再提交事務(wù)，更新存儲(chǔ)引擎中的數(shù)據(jù)，事務(wù)提交完成后，返回給客戶端“操作成功”的響應(yīng)。
• 同步 Binlog：從庫(kù)會(huì)創(chuàng)建一個(gè)專門(mén)的 I/O 線程，連接主庫(kù)的 log dump 線程，來(lái)接收主庫(kù)的 binlog 日志，再把 binlog 信息寫(xiě)入 relay log 的中繼日志里，再返回給主庫(kù)“復(fù)制成功”的響應(yīng)。
• 回放 Binlog：從庫(kù)會(huì)創(chuàng)建一個(gè)用于回放 binlog 的線程，去讀 relay log 中繼日志，然后回放 binlog 更新存儲(chǔ)引擎中的數(shù)據(jù)，最終實(shí)現(xiàn)主從的數(shù)據(jù)一致性。

什么時(shí)候刷盤(pán)

在刷盤(pán)時(shí)機(jī)上與redolog不一樣，redolog即使事務(wù)沒(méi)提交，也可以每隔1秒就刷盤(pán)。但是一個(gè)事務(wù)的 binlog 是不能被拆開(kāi)的，因此無(wú)論這個(gè)事務(wù)有多大（比如有很多條語(yǔ)句），也要保證一次性寫(xiě)入。如果一個(gè)事務(wù)的 binlog 被拆開(kāi)的時(shí)候，在備庫(kù)執(zhí)行就會(huì)被當(dāng)做多個(gè)事務(wù)分段自行，這樣就破壞了原子性，是有問(wèn)題的。

bin log日志與redo log類似，也有對(duì)應(yīng)的緩存，叫 binlog cache。事務(wù)提交的時(shí)候，再把 binlog cache 寫(xiě)到 binlog 文件中。

• 圖中的 write，指的就是指把日志寫(xiě)入到 binlog 文件，但是并沒(méi)有把數(shù)據(jù)持久化到磁盤(pán)，因?yàn)閿?shù)據(jù)還緩存在文件系統(tǒng)的 page cache 里，write 的寫(xiě)入速度還是比較快的，因?yàn)椴簧婕按疟P(pán) I/O。
• 圖中的 fsync，才是將數(shù)據(jù)持久化到磁盤(pán)的操作，這里就會(huì)涉及磁盤(pán) I/O，所以頻繁的 fsync 會(huì)導(dǎo)致磁盤(pán)的 I/O 升高。

MySQL提供一個(gè) sync_binlog 參數(shù)來(lái)控制數(shù)據(jù)庫(kù)的 binlog 刷到磁盤(pán)上的頻率：

• sync_binlog = 0 的時(shí)候，表示每次提交事務(wù)都只 write，不 fsync，后續(xù)交由操作系統(tǒng)決定何時(shí)將數(shù)據(jù)持久化到磁盤(pán)；
• sync_binlog = 1 的時(shí)候，表示每次提交事務(wù)都會(huì) write，然后馬上執(zhí)行 fsync；
• sync_binlog =N(N>1) 的時(shí)候，表示每次提交事務(wù)都 write，但累積 N 個(gè)事務(wù)后才 fsync。

顯然，在MySQL中系統(tǒng)默認(rèn)的設(shè)置是 sync_binlog = 0，也就是不做任何強(qiáng)制性的磁盤(pán)刷新指令，這時(shí)候的性能是最好的，但是風(fēng)險(xiǎn)也是最大的。因?yàn)橐坏┲鳈C(jī)發(fā)生異常重啟，還沒(méi)持久化到磁盤(pán)的數(shù)據(jù)就會(huì)丟失。

而當(dāng) sync_binlog 設(shè)置為 1 的時(shí)候，是最安全但是性能損耗最大的設(shè)置。因?yàn)楫?dāng)設(shè)置為 1 的時(shí)候，即使主機(jī)發(fā)生異常重啟，最多丟失一個(gè)事務(wù)的 binlog，而已經(jīng)持久化到磁盤(pán)的數(shù)據(jù)就不會(huì)有影響，不過(guò)就是對(duì)寫(xiě)入性能影響太大。

如果能容少量事務(wù)的 binlog 日志丟失的風(fēng)險(xiǎn)，為了提高寫(xiě)入的性能，一般會(huì) sync_binlog 設(shè)置為 100~1000 中的某個(gè)數(shù)值。

兩階段提交

事務(wù)提交后，redo log 和 binlog 都要持久化到磁盤(pán)，但是這兩個(gè)是獨(dú)立的邏輯，可能出現(xiàn)半成功的狀態(tài)，這樣就造成兩份日志之間的邏輯不一致。如下：

1. 如果在將 redo log 刷入到磁盤(pán)之后， MySQL 突然宕機(jī)了，而 binlog 還沒(méi)有來(lái)得及寫(xiě)入。那么機(jī)器重啟后，這臺(tái)機(jī)器會(huì)通過(guò)redo log恢復(fù)數(shù)據(jù)，但是這個(gè)時(shí)候binlog并沒(méi)有記錄該數(shù)據(jù)，后續(xù)進(jìn)行機(jī)器備份的時(shí)候，就會(huì)丟失這一條數(shù)據(jù)，同時(shí)主從同步也會(huì)丟失這一條數(shù)據(jù)。
2. 如果在將 binlog 刷入到磁盤(pán)之后， MySQL 突然宕機(jī)了，而 redo log 還沒(méi)有來(lái)得及寫(xiě)入。由于 redo log 還沒(méi)寫(xiě)，崩潰恢復(fù)以后這個(gè)事務(wù)無(wú)效，而 binlog 里面記錄了這條更新語(yǔ)句，在主從架構(gòu)中，binlog 會(huì)被復(fù)制到從庫(kù)，從庫(kù)執(zhí)行了這條更新語(yǔ)句，那么就與主庫(kù)的值不一致性；

兩階段提交把單個(gè)事務(wù)的提交拆分成了 2 個(gè)階段，分別是「準(zhǔn)備（Prepare）階段」和「提交（Commit）階段」

具體過(guò)程

事務(wù)的提交過(guò)程有兩個(gè)階段，就是將 redo log 的寫(xiě)入拆成了兩個(gè)步驟：prepare 和 commit，中間再穿插寫(xiě)入binlog，具體如下：

• prepare 階段：將 XID（內(nèi)部 XA 事務(wù)的 ID） 寫(xiě)入到 redo log，同時(shí)將 redo log 對(duì)應(yīng)的事務(wù)狀態(tài)設(shè)置為 prepare，然后將 redo log 持久化到磁盤(pán)（innodb_flush_log_at_trx_commit = 1 的作用）；
• commit 階段：把 XID 寫(xiě)入到 binlog，然后將 binlog 持久化到磁盤(pán)（sync_binlog = 1 的作用），接著調(diào)用引擎的提交事務(wù)接口，將 redo log 狀態(tài)設(shè)置為 commit，此時(shí)該狀態(tài)并不需要持久化到磁盤(pán)，只需要 write 到文件系統(tǒng)的 page cache 中就夠了，因?yàn)橹灰?binlog 寫(xiě)磁盤(pán)成功，就算 redo log 的狀態(tài)還是 prepare 也沒(méi)有關(guān)系，一樣會(huì)被認(rèn)為事務(wù)已經(jīng)執(zhí)行成功；

總的來(lái)說(shuō)就是，事務(wù)提交后，redo log變成prepare 階段，再寫(xiě)入binlog，返回成功后redo log 進(jìn)入commit 階段。

總結(jié)三個(gè)日志的具體流程

當(dāng)優(yōu)化器分析出成本最小的執(zhí)行計(jì)劃后，執(zhí)行器就按照?qǐng)?zhí)行計(jì)劃開(kāi)始進(jìn)行更新操作。

具體更新一條記錄 UPDATE t_user SET name = 'xiaolin' WHERE id = 1; 的流程如下:

1. 檢查在不在buffer Pool。 執(zhí)行器負(fù)責(zé)具體執(zhí)行，會(huì)調(diào)用存儲(chǔ)引擎的接口，通過(guò)主鍵索引樹(shù)搜索獲取 id = 1 這一行記錄：
   • 如果 id=1 這一行所在的數(shù)據(jù)頁(yè)本來(lái)就在 buffer pool 中，就直接返回給執(zhí)行器更新；
   • 如果記錄不在 buffer pool，將數(shù)據(jù)頁(yè)從磁盤(pán)讀入到 buffer pool，返回記錄給執(zhí)行器。
2. 檢查是否已經(jīng)是要更新的值。執(zhí)行器得到聚簇索引記錄后，會(huì)看一下更新前的記錄和更新后的記錄是否一樣：
   • 如果一樣的話就不進(jìn)行后續(xù)更新流程；
   • 如果不一樣的話就把更新前的記錄和更新后的記錄都當(dāng)作參數(shù)傳給 InnoDB 層，讓 InnoDB 真正的執(zhí)行更新記錄的操作；
3. 開(kāi)啟事務(wù)，記錄undo log，并記錄修改undo log對(duì)應(yīng)的redo log：開(kāi)啟事務(wù)， InnoDB 層更新記錄前，首先要記錄相應(yīng)的 undo log，因?yàn)檫@是更新操作，需要把被更新的列的舊值記下來(lái)，也就是要生成一條 undo log，undo log 會(huì)寫(xiě)入 Buffer Pool 中的 Undo 頁(yè)面，不過(guò)在內(nèi)存修改該 Undo 頁(yè)面后，需要記錄對(duì)應(yīng)的 redo log。
4. 標(biāo)記為臟頁(yè)，并寫(xiě)入redo log：InnoDB 層開(kāi)始更新記錄，會(huì)先更新內(nèi)存（同時(shí)標(biāo)記為臟頁(yè)），然后將記錄寫(xiě)到 redo log 里面，這個(gè)時(shí)候更新就算完成了。為了減少磁盤(pán)I/O，不會(huì)立即將臟頁(yè)寫(xiě)入磁盤(pán)，后續(xù)由后臺(tái)線程選擇一個(gè)合適的時(shí)機(jī)將臟頁(yè)寫(xiě)入到磁盤(pán)。這就是 WAL 技術(shù)，MySQL 的寫(xiě)操作并不是立刻寫(xiě)到磁盤(pán)上，而是先寫(xiě) redo 日志，然后在合適的時(shí)間再將修改的行數(shù)據(jù)寫(xiě)到磁盤(pán)上。
5. 至此，一條記錄更新完了。
6. 記錄binlog：在一條更新語(yǔ)句執(zhí)行完成后，然后開(kāi)始記錄該語(yǔ)句對(duì)應(yīng)的 binlog，此時(shí)記錄的 binlog 會(huì)被保存到 binlog cache，并沒(méi)有刷新到硬盤(pán)上的 binlog 文件，在事務(wù)提交時(shí)才會(huì)統(tǒng)一將該事務(wù)運(yùn)行過(guò)程中的所有 binlog 刷新到硬盤(pán)。
7. 事務(wù)提交，redo log和binlog刷盤(pán)。

面試題專欄

Java面試題專欄 已上線，歡迎訪問(wèn)。

• 如果你不知道簡(jiǎn)歷怎么寫(xiě)，簡(jiǎn)歷項(xiàng)目不知道怎么包裝；
• 如果簡(jiǎn)歷中有些內(nèi)容你不知道該不該寫(xiě)上去；
• 如果有些綜合性問(wèn)題你不知道怎么答；

那么可以私信我，我會(huì)盡我所能幫助你。