這篇文章主要介紹“MySQL的binlog、redo log和undo log怎么使用”，在日常操作中，相信很多人在MySQL的binlog、redo log和undo log怎么使用問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”MySQL的binlog、redo log和undo log怎么使用”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

成都創(chuàng)新互聯(lián)公司是由多位在大型網(wǎng)絡公司、廣告設計公司的優(yōu)秀設計人員和策劃人員組成的一個具有豐富經(jīng)驗的團隊，其中包括網(wǎng)站策劃、網(wǎng)頁美工、網(wǎng)站程序員、網(wǎng)頁設計師、平面廣告設計師、網(wǎng)絡營銷人員及形象策劃。承接：網(wǎng)站制作、成都網(wǎng)站制作、網(wǎng)站改版、網(wǎng)頁設計制作、網(wǎng)站建設與維護、網(wǎng)絡推廣、數(shù)據(jù)庫開發(fā),以高性價比制作企業(yè)網(wǎng)站、行業(yè)門戶平臺等全方位的服務。

1、binlog

binlog用于記錄數(shù)據(jù)庫執(zhí)行的寫入性操作(不包括查詢)信息，以二進制的形式保存在磁盤中。binlog是mysql的邏輯日志，并且由Server層進行記錄，使用任何存儲引擎的mysql數(shù)據(jù)庫都會記錄binlog日志。

• 邏輯日志：可以簡單得理解為sql語句；

• 物理日志：MySQL中數(shù)據(jù)都是保存在數(shù)據(jù)頁中的，物理日志記錄的是數(shù)據(jù)頁上的變更；在這里插入代碼片

binlog是通過追加的方式進行寫入的，可以通過max_binlog_size參數(shù)設置每個binlog文件的大小，當文件大小達到給定值之后，會生成新的文件來保存日志。

binlog使用場景
項目 在實際應用中，binlog的主要使用場景有兩個，分別是主從復制和數(shù)據(jù)恢復。

• 主從復制：在Master端開啟binlog，然后將binlog發(fā)送到各個Slave端，Slave端重放binlog從而達到主從數(shù)據(jù)一致。

• 數(shù)據(jù)恢復：通過使用mysqlbinlog工具來恢復數(shù)據(jù)。

MySQL主從同步原理

• 主節(jié)點 binlog dump 線程
  當從節(jié)點連接主節(jié)點時，主節(jié)點會創(chuàng)建一個log dump 線程，用于發(fā)送binlog的內(nèi)容。在讀取binlog中的操作時，此線程會對主節(jié)點上的binlog加鎖，當讀取完成，甚至在發(fā)動給從節(jié)點之前，鎖會被釋放；

• 從節(jié)點I/O線程
  當從節(jié)點上執(zhí)行start slave命令之后，從節(jié)點會創(chuàng)建一個I/O線程用來連接主節(jié)點，請求主庫中更新的binlog。I/O線程接收到主節(jié)點binlog dump進程發(fā)來的更新之后，保存在本地relaylog中；

• 從節(jié)點SQL線程
  SQL線程負責讀取relaylog中的內(nèi)容，解析成具體的操作并執(zhí)行，最終保證主從數(shù)據(jù)的一致性；
  MySQL 數(shù)據(jù)庫主從同步原理

binlog的內(nèi)容
上面說了，binlog是一種邏輯日志，可以簡單得理解為sql語句，但是實際上還包含著執(zhí)行的sql語句的反向邏輯。delete對應著delete本身以及反向的insert信息；update包含著對應的update執(zhí)行前后數(shù)據(jù)行的相關信息；insert包含自身的insert以及對應的delete信息。

binlog的格式
binlog共有三種格式，分別是statement、row以及mixed。MySQL 5.7.7版本之前默認使用的是statement，MySQL 5.7.7之后默認使用的是row。日志的格式可以通過my.ini配置文件中的binlog-format來修改。
(1)statement：基于sql語句的復制（statement-based replication,SBR），每一條修改數(shù)據(jù)的sql語句都會記錄到binlog中。

• 優(yōu)點：不需要具體記錄某一行的變化，節(jié)約空間，減少io，提高性能；

• 缺點：在執(zhí)行sysdate()或者sleep()等操作的時候，可能導致主從數(shù)據(jù)不一致的情況；

(2)row：基于行記錄的復制（row-based replication,RBR），不記錄sql語句上下文相關信息，而是記錄哪條記錄被修改的細節(jié)。

• 優(yōu)點：非常詳細地記錄每一行記錄修改的細節(jié)，因而不會出現(xiàn)數(shù)據(jù)無法被正確復制的情況；

• 缺點：由于會非常詳細地記錄每一條記錄修改的細節(jié)，這樣會產(chǎn)生大量的日志內(nèi)容。假設現(xiàn)在有一條update語句，修改了很多條記錄，則每條修改記錄都會記錄到binlog中。特別地，alter table這個操作，由于表結構的變化，每行記錄都會發(fā)生變化，導致日志量暴增；

(3)mixed：根據(jù)上面所說的，statement和row各有優(yōu)缺點，因此出現(xiàn)了mixed這個版本，將這二者進行混合。一般情況下使用statement格式來進行保存，當遇到statement無法解決時，切換為row格式來進行保存。
特別地，上面說了，新版本（MySQL 5.7.7之后）默認使用的row格式，這里的row也做了相應的優(yōu)化，在遇到alter table這個操作時采用statement格式進行記錄，其余操作仍然使用row格式。

binlog刷盤時機

對于InnoDB存儲引擎來說，只有在事務提交的時候才會記錄binlog，此時記錄還在內(nèi)存中，MySQL通過sync_binlog來控制binlog的刷盤時機，取值范圍為0-N：

• 0：不強制刷到磁盤，由系統(tǒng)自行判斷何時寫入磁盤中；

• 1：每次提交后都要將binlog寫入磁盤中；

• N：每N個事務，才會將binlog寫入磁盤中；

從上面可以看出，sync_binlog最安全的是設置是1，這也是MySQL 5.7.7之后版本的默認值。但是設置一個大一些的值可以提升數(shù)據(jù)庫性能，因此實際情況下也可以將值適當調(diào)大，犧牲一定的一致性來獲取更好的性能。

binlog的物理文件大小

在my.ini配置文件中，可以通過max_binlog_size來配置binlog的大小。當日志量超過binlog文件的大小時，系統(tǒng)會重新生成一個新的文件來繼續(xù)保存文件。當一個事務比較大時，或者是當日志越來越多的時候，此時占據(jù)的物理空間太大怎么辦？MySQL提供了一種自動刪除的機制，還是在my.ini配置文件中，可以通過配置expire_logs_days這個參數(shù)來解決，單位為天。當這個參數(shù)為0，表示永不刪除；為N時，表示第N天后自動刪除。

2、redo log

redolog是InnoDB引擎專有的日志系統(tǒng)。主要是用來實現(xiàn)事務的持久性以及實現(xiàn)crash-safe功能。redolog屬于物理日志，記錄的是sql語句執(zhí)行之后數(shù)據(jù)頁上的具體修改內(nèi)容。
我們都知道，當MySQL運行的時候，會將數(shù)據(jù)從磁盤中加載到內(nèi)存當中。當執(zhí)行sql語句對數(shù)據(jù)進行修改時，修改后的內(nèi)容其實都只是暫時保存到內(nèi)存當中，如果此時斷電或者出現(xiàn)其他情況，這些修改就會丟失。因而，當修改完數(shù)據(jù)之后，MySQL會尋找機會將這些內(nèi)存中的記錄刷回到磁盤當中。但這就出現(xiàn)一個性能問題，主要有兩個方面：

InnoDB中是以頁為數(shù)據(jù)單位與磁盤進行交互的，而一個事務很可能只是修改了一個頁上的幾個字節(jié)，如果將一個完整的數(shù)據(jù)頁刷回磁盤當中，浪費資源；

一個事務可能涉及到多個數(shù)據(jù)頁，這些數(shù)據(jù)頁只是邏輯上連續(xù)，在物理上并不連續(xù)，使用隨機IO性能太差；

因此，MySQL設計了redolog來記錄事務對數(shù)據(jù)頁具體做了哪些修改，之后將redolog再刷回磁盤當中。你可能會有疑惑，本來就是想減少io，這不又加上一次io么？InnoDB的設計者在設計之初就已經(jīng)考慮到了這些。redolog文件一般都比較小，且在刷回磁盤的過程中是順序io，相比于隨機io來說，性能更好。

redo log基本概念
redolog由兩部分組成，一個是內(nèi)存中的日志緩存redo log buffer，一個是磁盤中的日志文件redo log file。當每次對數(shù)據(jù)記錄進行修改的時候，都會將這些修改內(nèi)容先寫入redo log buffer中，后續(xù)等待合適的時機將內(nèi)存中的修改刷回到redo log file中。這種先寫日志，再寫磁盤的技術就是WAL(Write-Ahead Logging)技術。需要注意的是redolog比數(shù)據(jù)頁先刷回磁盤，聚簇索引，二級索引，undo頁面的修改，均需要記錄redolog。

在計算機操作系統(tǒng)中，用戶空間(user space)下的緩沖區(qū)數(shù)據(jù)一般情況下是無法直接寫入磁盤的，中間必須經(jīng)過操作系統(tǒng)內(nèi)核空間(kernel space)緩沖區(qū)(OS Buffer)。因此，redo log buffer寫入redo log file實際上是先寫入OS Buffer，然后再通過系統(tǒng)調(diào)用fsync()將其刷到redo log file中，過程如下：

mysql支持三種將redo log buffer寫入redo log file的時機，可以通過innodb_flush_log_at_trx_commit參數(shù)配置，各參數(shù)值含義如下：

參數(shù)值	含義
0（延遲寫）	事務提交時不會將redo log buffer中日志寫入到os buffer，而是每秒寫入os buffer并調(diào)用fsync()寫入到redo log file中。也就是說設置為0時是(大約)每秒刷新寫入到磁盤中的，當系統(tǒng)崩潰，會丟失1秒鐘的數(shù)據(jù)。
1（實時寫，實時刷）	事務每次提交都會將redo log buffer中的日志寫入os buffer并調(diào)用fsync()刷到redo log file中。這種方式即使系統(tǒng)崩潰也不會丟失任何數(shù)據(jù)，但是因為每次提交都寫入磁盤，IO的性能較差。
2（實時寫，延遲刷）	每次提交都僅寫入到os buffer，然后是每秒調(diào)用fsync()將os buffer中的日志寫入到redo log file。

redo log記錄形式
redolog采用固定大小，循環(huán)寫入的格式，當redolog寫滿之后，會重新從頭開始寫。為什么這么設計呢？
redo log存在的意義主要就是降低對數(shù)據(jù)頁刷盤的要求。redolog記錄了數(shù)據(jù)頁上的修改，但是當數(shù)據(jù)頁也刷回到磁盤后，這些記錄就失去作用了。因此當MySQL判斷之前的redolog已經(jīng)失去作用之后，新數(shù)據(jù)會將這些失效的數(shù)據(jù)進行覆蓋。那如何判斷該不該進行覆蓋呢？

上圖是redo log file的示意圖，write pos表示redolog當前記錄的日志序列號LSN(log sequence number)。當數(shù)據(jù)頁也已經(jīng)刷回磁盤之后，會更新redo log file中的LSN，表示到這個LSN之前的數(shù)據(jù)已經(jīng)落盤，這個LSN就是check point。write pos到check point之間的部分是redolog空余的部分，用于記錄新的記錄；check point到write pos之間是redolog已經(jīng)記錄的數(shù)據(jù)頁修改部分，但此時數(shù)據(jù)頁還未刷回磁盤的部分。當write pos追上check point時，會先推動check point向前移動，空出位置再記錄新的日志。

啟動innodb的時候，不管上次是正常關閉還是異常關閉，總是會進行恢復操作。恢復時，會先檢查數(shù)據(jù)頁中的LSN，如果這個LSN小于redolog中的LSN，即write pos位置，說明在redolog上記錄著數(shù)據(jù)頁上尚未完成的操作，接著就會從最近的一個check point出發(fā)，開始同步數(shù)據(jù)。

那有沒有可能數(shù)據(jù)頁中的LSN大于redolog中的LSN呢？答案是當然可能。出現(xiàn)這種情況時，這時超出redolog的部分將不會重做，因為這本身就表示已經(jīng)做過的事情，無需再重做。
redo log與binlog區(qū)別

	redo log	binlog
文件大小	redo log的大小是固定的。	binlog可通過配置參數(shù)max_binlog_size設置每個binlog文件的大小。
實現(xiàn)方式	redo log是InnoDB引擎層實現(xiàn)的，并不是所有引擎都有。	binlog是Server層實現(xiàn)的，所有引擎都可以使用 binlog日志
記錄方式	redo log 采用循環(huán)寫的方式記錄，當寫到結尾時，會回到開頭循環(huán)寫日志。	binlog 通過追加的方式記錄，當文件大小大于給定值后，后續(xù)的日志會記錄到新的文件上
適用場景	redo log適用于崩潰恢復(crash-safe)	binlog適用于主從復制和數(shù)據(jù)恢復

由binlog和redo log的區(qū)別可知：binlog日志只用于歸檔，只依靠binlog是沒有crash-safe能力的。但只有redo log也不行，因為redo log是InnoDB特有的，且日志上的記錄落盤后會被覆蓋掉。因此需要binlog和redo log二者同時記錄，才能保證當數(shù)據(jù)庫發(fā)生宕機重啟時，數(shù)據(jù)不會丟失。
兩階段提交
上面簡單介紹了redolog和binlog，在對數(shù)據(jù)進行修改時，他們都會對這些修改進行保存落地，只是一個是物理日志，一個是邏輯日志。那他倆具體在修改過程中是如何執(zhí)行的呢？

假設現(xiàn)在有一條update語句要執(zhí)行，update from table_name set c=c+1 where id=2，執(zhí)行流程如下：

• 先定位到id=2這一條記錄；

• 執(zhí)行器拿到引擎給的行數(shù)據(jù)，把這個值加上 1，得到新的一行數(shù)據(jù)，再調(diào)用引擎接口寫入這行新數(shù)據(jù)；

• 引擎將這行新數(shù)據(jù)更新到內(nèi)存中，同時將這個更新操作記錄到redolog里面，此時 redolog 處于 prepare 狀態(tài)。然后告知執(zhí)行器執(zhí)行完成了，隨時可以提交事務；

• 執(zhí)行器生成這個操作的 binlog，并把binlog寫入磁盤；

• 執(zhí)行器調(diào)用引擎的提交事務接口，引擎把剛剛寫入的 redo log 改成提交（commit）狀態(tài)，更新完成；

示意圖如下所示：

這種將redolog的寫入拆分成prepare和commit兩個步驟的過程稱之為兩階段提交。

redolog 和binlog都可以用于表示事務的提交狀態(tài)，而兩階段提交就是讓這兩個狀態(tài)保持邏輯上的一致。如果不使用兩階段提交，而是先寫其中一個再寫另外一個可能會帶來一些問題。

此時還是使用update來舉例。假設當前id=2，有一個字段c=0，分別分析以下情況：
先寫redolog再寫binlog
假設先寫redolog，當redolog寫完，但是binlog還未寫完的時候，此時MySQL突然出現(xiàn)異常導致重啟。由于之前redolog已經(jīng)寫完，系統(tǒng)重啟后，修改的記錄仍然存在，所以恢復后這一行 c 的值是 1。但由于系統(tǒng)重啟，binlog中并未有這條記錄。之后備份日志的時候，存起來的binlog里面就沒有這條語句。然后你會發(fā)現(xiàn)，如果需要用這個 binlog 來恢復臨時庫的話，由于這個語句的binlog丟失，這個臨時庫就會少了這一次更新，恢復出來的這一行 c 的值就是 0，與原庫的值不同。
先寫binlog再寫redolog
假如先寫binlog，然后寫redolog的時候系統(tǒng)重啟。重啟之后，redolog中沒有對c進行修改的記錄，此時c的值還是0。但是 binlog里面已經(jīng)記錄了“把 c 從 0 改成 1”這個日志。所以，在之后用 binlog來恢復的時候就多了一個事務出來，恢復出來的這一行 c 的值就是 1，與原庫的值不同。

因此，綜上所述，如果是先寫某一個日志再寫另一個日志，就會出現(xiàn)數(shù)據(jù)庫的狀態(tài)與使用binlog恢復出來的庫的狀態(tài)不一致的情況。

3、undo log

undolog主要用來記錄某條行記錄被修改之前的狀態(tài)，記錄的是修改前的數(shù)據(jù)。這樣的話，當事務進行回滾時，就可以通過undolog將記錄恢復到事務開始前的樣子。事務的原子性和持久性也是依靠undolog來實現(xiàn)的。undo log主要記錄了數(shù)據(jù)的邏輯變化，比如一條INSERT語句，對應一條DELETE的undo log，對于每個UPDATE語句，對應一條相反的UPDATE的undo log，這樣在發(fā)生錯誤時，就能回滾到事務之前的數(shù)據(jù)狀態(tài)。同時，在進行數(shù)據(jù)恢復的時候，與binlog，redolog結合使用，保證了數(shù)據(jù)恢復的正確性。

undolog的作用流程如下所示：

• 在事務開始之前將修改前的版本寫入到undo log中；

• 開始進行修改，將修改過的數(shù)據(jù)保存到內(nèi)存當中；

• 將undolog持久化到磁盤當中；

• 將數(shù)據(jù)頁刷回到磁盤當中；

• 事務提交；

需要注意的是，與redolog一樣，undolog也是要先于數(shù)據(jù)頁刷回到磁盤當中。在恢復數(shù)據(jù)時，如果undolog是完整的，可以根據(jù)undolog來回滾事務。

在一個事務當中，可能會對同一條數(shù)據(jù)進行多次修改，那么是不是每一次修改前的記錄都要記錄到undolog中呢？這樣的話，會導致undolog日志量太大，此時redolog就要上場了。在一個事務當中，如果是對同一條記錄進行修改，undolog只會記錄事務開始前的原始記錄，當再次對這條記錄進行修改時，redolog會記錄后續(xù)的變化。在數(shù)據(jù)恢復時，redolog完成前滾，undolog完成回滾，二者相互協(xié)調(diào)完成數(shù)據(jù)的恢復。過程如下所示：

到此，關于“MySQL的binlog、redo log和undo log怎么使用”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>

網(wǎng)頁題目：MySQL的binlog、redolog和undolog怎么使用
分享地址：http://www.rwnh.cn/article42/jgpcec.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、、商城網(wǎng)站、企業(yè)建站、網(wǎng)站維護、網(wǎng)站建設

廣告

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