一、binlog

binlog記錄數(shù)據(jù)庫(kù)表結(jié)構(gòu)和表數(shù)據(jù)變更，比如update/delete/insert/truncate/create，它不會(huì)記錄select。存儲(chǔ)著每條變更的SQL語(yǔ)句和XID事務(wù)Id等等。binlog日志文件如下：

[root@192.168.10.11]# mysqlbinlog mysql-binlog.0000012
..........
# at 523
# 168654 20:22:43 server id 1 end_log_pos 843 Query thread_id=3 exec_time=0 error_code=0
SET TIMESTAMP=156521934/*!*/;
INSERT INTO student('name','age','sex') VALUES('ZZX',20,'1');  # 執(zhí)行的SQL語(yǔ)句
/*!*/;
# at 669
#168654 20:22:45 server id 1 end_log_pos 876 Xid = 12              #執(zhí)行的時(shí)間和事務(wù)ID

主要有兩個(gè)作用：復(fù)制和恢復(fù)數(shù)據(jù)
【1】MySQL架構(gòu)為了高可用性都是一主多從，從服務(wù)器需要與主服務(wù)器保持?jǐn)?shù)據(jù)一致，這就是通過(guò)binlog進(jìn)行復(fù)制；
【2】數(shù)據(jù)庫(kù)的數(shù)據(jù)如果被誤刪，可以通過(guò)binlog數(shù)據(jù)進(jìn)行恢復(fù)。

因?yàn)?code>binlog記錄了數(shù)據(jù)庫(kù)表的邏輯變更，所以可以用binlog進(jìn)行主從復(fù)制和恢復(fù)數(shù)據(jù)。

二、redo log

MySQL執(zhí)行SQL修改語(yǔ)句時(shí)，肯定是先把這條記錄查出來(lái)，然后再將這條進(jìn)行進(jìn)行修改。因?yàn)?code>Mysql的基本存儲(chǔ)結(jié)構(gòu)是頁(yè)，記錄都存在頁(yè)里邊，所以MySQL是先把這條記錄所在的頁(yè)找到，然后把該頁(yè)加載到內(nèi)存中，將對(duì)應(yīng)記錄進(jìn)行修改?，F(xiàn)在就可能存在一個(gè)問(wèn)題：如果在內(nèi)存中把數(shù)據(jù)改了，還沒來(lái)得及落磁盤，而此時(shí)的數(shù)據(jù)庫(kù)掛了，導(dǎo)致這次修改丟失了怎么辦？

如果每個(gè)請(qǐng)求都需要將數(shù)據(jù)立馬同步到磁盤，那速度會(huì)很慢，MySQL可能也頂不住。所以MySQL引入了redo log，內(nèi)存寫完了，然后會(huì)寫一份redo log，這份redo log記載著這次在某個(gè)頁(yè)上做了什么修改。

寫redo log的時(shí)候，也會(huì)有buffer，是先寫buffer，再真正落到磁盤中的。至于從buffer什么時(shí)候落磁盤，會(huì)有配置供我們配置。

寫redo log也是需要寫磁盤的，但它的好處就是順序IO（我們都知道順序IO比隨機(jī)IO快非常多）。

所以，redo log的存在為了：當(dāng)我們修改的時(shí)候，寫完內(nèi)存了，但數(shù)據(jù)還沒真正寫到磁盤的時(shí)候。此時(shí)我們的數(shù)據(jù)庫(kù)掛了，我們可以根據(jù)redo log來(lái)對(duì)數(shù)據(jù)進(jìn)行恢復(fù)。因?yàn)?code>redo log是順序IO，所以寫入的速度很快，并且redo log記載的是物理變化（x頁(yè)做了y修改），文件的體積很小，恢復(fù)速度很快。

三、binlog與redolog的區(qū)別

兩個(gè)日志較為相似，這里總結(jié)下兩者的主要區(qū)別：
【1】存儲(chǔ)內(nèi)容不同： binlog記載的是update/delete/insert這樣的SQL語(yǔ)句，而redo log記載的是物理修改的內(nèi)容（x頁(yè)修改了y）。redo log記錄的是數(shù)據(jù)的物理變化，binlog記錄的是數(shù)據(jù)的邏輯變化。

【2】功能： redo log的作用是為持久化而生的。寫完內(nèi)存，如果數(shù)據(jù)庫(kù)掛了，那我們可以通過(guò)redo log來(lái)恢復(fù)內(nèi)存還沒來(lái)得及刷到磁盤的數(shù)據(jù)，將redo log加載到內(nèi)存里邊，那內(nèi)存就能恢復(fù)到掛掉之前的數(shù)據(jù)了。
binlog的作用是復(fù)制和恢復(fù)而生的。主從服務(wù)器需要保持?jǐn)?shù)據(jù)的一致性，通過(guò)binlog來(lái)同步數(shù)據(jù)。如果整個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)都被刪除了，binlog存儲(chǔ)著所有的數(shù)據(jù)變更情況，那么可以通過(guò)binlog來(lái)對(duì)數(shù)據(jù)進(jìn)行恢復(fù)。

如果整個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)都被刪除了，那我可以用redo log的記錄來(lái)恢復(fù)嗎？
不能，因?yàn)楣δ艿牟煌?，redo log 存儲(chǔ)的是物理數(shù)據(jù)的變更，如果我們內(nèi)存的數(shù)據(jù)已經(jīng)刷到了磁盤了，那redo log的數(shù)據(jù)就無(wú)效了。所以redo log不會(huì)存儲(chǔ)著歷史所有數(shù)據(jù)的變更，文件的內(nèi)容會(huì)被覆蓋的。

【3】寫入細(xì)節(jié)不同： redo log是MySQL的InnoDB引擎所產(chǎn)生的。binlog無(wú)論MySQL任何引擎都會(huì)有的。
InnoDB是有事務(wù)的，事務(wù)的四大特性之一：持久性就是靠redo log來(lái)實(shí)現(xiàn)的（如果寫入內(nèi)存成功，但數(shù)據(jù)還沒真正刷到磁盤，如果此時(shí)的數(shù)據(jù)庫(kù)掛了，我們可以靠redo log來(lái)恢復(fù)內(nèi)存的數(shù)據(jù)，這就實(shí)現(xiàn)了持久性）。

上面也提到，在修改的數(shù)據(jù)的時(shí)候，binlog會(huì)記載著變更的類容，redo log也會(huì)記載著變更的內(nèi)容。（只不過(guò)一個(gè)存儲(chǔ)的是物理變化，一個(gè)存儲(chǔ)的是邏輯變化）。那他們的寫入順序是什么樣的呢？

redo log事務(wù)開始的時(shí)候，就開始記錄每次的變更信息，而binlog是在事務(wù)提交的時(shí)候才記錄。

于是新有的問(wèn)題又出現(xiàn)了：我寫其中的某一個(gè)log，失敗了，那會(huì)怎么辦？現(xiàn)在我們的前提是先寫redo log，再寫binlog，我們來(lái)看看：
  ■ 如果寫redo log失敗了，那我們就認(rèn)為這次事務(wù)有問(wèn)題，回滾，不再寫binlog。
  ■ 如果寫redo log成功了，寫binlog，寫binlog寫一半了，但失敗了怎么辦？我們還是會(huì)對(duì)這次的事務(wù)回滾，將無(wú)效的binlog給刪除（因?yàn)?code>binlog會(huì)影響從庫(kù)的數(shù)據(jù)，所以需要做刪除操作）
  ■ 如果寫redo log和binlog都成功了，那這次算是事務(wù)才會(huì)真正成功。

簡(jiǎn)單來(lái)說(shuō)：MySQL需要保證redo log和binlog的數(shù)據(jù)是一致的，如果不一致，那就亂套了。
  ■ 如果redo log寫失敗了，而binlog寫成功了。那假設(shè)內(nèi)存的數(shù)據(jù)還沒來(lái)得及落磁盤，機(jī)器就掛掉了。那主從服務(wù)器的數(shù)據(jù)就不一致了。（從服務(wù)器通過(guò)binlog得到最新的數(shù)據(jù)，而主服務(wù)器由于redo log沒有記載，沒法恢復(fù)數(shù)據(jù)）
  ■ 如果redo log寫成功了，而binlog寫失敗了。那從服務(wù)器就拿不到最新的數(shù)據(jù)了。

MySQL通過(guò)兩階段提交來(lái)保證redo log和binlog的數(shù)據(jù)是一致的。

階段1：InnoDB redo log寫盤，InnoDB事務(wù)進(jìn)入prepare狀態(tài)
階段2：binlog寫盤，InooDB事務(wù)進(jìn)入commit狀態(tài)

每個(gè)事務(wù)binlog的末尾，會(huì)記錄一個(gè)XID event，標(biāo)志著事務(wù)是否提交成功，也就是說(shuō)，恢復(fù)過(guò)程中，binlog最后一個(gè)XID event之后的內(nèi)容都應(yīng)該被purge。

如果binlog沒有正常關(guān)閉，mysql server可能crash過(guò)，我們需要調(diào)用MYSQL_BIN_LOG::recover:找到最后一個(gè)XID完成最后一次事務(wù)的兩階段提交InnoDB commit。因此，需要遍歷binlog文件，找到最后一個(gè)合法event集合，并purge無(wú)效binlog

四、relay-log

從服務(wù)器I/O線程將主服務(wù)器的二進(jìn)制日志讀取過(guò)來(lái)記錄到從服務(wù)器本地文件，然后從服務(wù)器SQL線程會(huì)讀取relay-log日志的內(nèi)容并應(yīng)用到從服務(wù)器，從而使從服務(wù)器和主服務(wù)器的數(shù)據(jù)保持一致

show variables like '%relay%';
#結(jié)果
+---------------------------+----------------------------------+
| Variable_name             | Value                            |
+---------------------------+----------------------------------+
| max_relay_log_size        | 0                                |
| relay_log                 | relay-mysql                      |
| relay_log_basename        | /var/lib/mysql/relay-mysql       |
| relay_log_index           | /var/lib/mysql/relay-mysql.index |
| relay_log_info_file       | relay-log.info                   |
| relay_log_info_repository | FILE                             |
| relay_log_purge           | ON                               |
| relay_log_recovery        | ON                               |
| relay_log_space_limit     | 0                                |
| sync_relay_log            | 10000                            |
| sync_relay_log_info       | 10000                            |
+---------------------------+----------------------------------+

max_relay_log_size：relay log允許的最大值，如果該值為0，則默認(rèn)值為max_binlog_size (1G)。如果不為0，則max_relay_log_size則為最大的relay_log文件大??；

relay_log: 定義relay_log的位置和名稱，如果值為空，則默認(rèn)位置在數(shù)據(jù)文件的目錄；

relay_log_index：定義relay_log索引的位置和名稱，記錄有幾個(gè)relay_log文件，默認(rèn)為2個(gè)

cat /var/lib/mysql/relay-mysql.index
#結(jié)果
./relay-mysql.000241
./relay-mysql.000242

relay_log_info_file：定義relay-log.info的位置和名稱。relay-log.info記錄master主庫(kù)的binary_log的恢復(fù)位置和從庫(kù)relay_log的位置；

[root@localhost ~]# cat /var/lib/mysql/relay-log.info
#結(jié)果
7
./relay-mysql.000242
19421766
mysql-bin.000094
34300252
0
0
1

relay_log_purge：是否自動(dòng)清空中繼日志，默認(rèn)值為1(啟用)；

relay_log_recovery：
當(dāng)slave從庫(kù)宕機(jī)后，假如relay-log損壞了，導(dǎo)致一部分中繼日志沒有處理，則自動(dòng)放棄所有未執(zhí)行的relay-log，并且重新從master上獲取日志，這樣就保證了relay-log的完整性。默認(rèn)情況下該功能是關(guān)閉的，將relay_log_recovery的值設(shè)置為1時(shí)，可在slave從庫(kù)上開啟該功能，建議開啟；

sync_relay_log：當(dāng)設(shè)置為1時(shí)，slave的I/O線程每次接收到master發(fā)送過(guò)來(lái)的binlog日志都要寫入系統(tǒng)緩沖區(qū)，然后刷入relay log中繼日志里，這樣是最安全的，因?yàn)樵诒罎⒌臅r(shí)候，你最多會(huì)丟失一個(gè)事務(wù)，但會(huì)造成磁盤的大量I/O。當(dāng)設(shè)置為0時(shí)，并不是馬上就刷入中繼日志里，而是由操作系統(tǒng)決定何時(shí)來(lái)寫入，雖然安全性降低了，但減少了大量的磁盤I/O操作。這個(gè)值默認(rèn)是0，可動(dòng)態(tài)修改；

sync_relay_log_info：這個(gè)參數(shù)和sync_relay_log參數(shù)一樣。

五、undo log

undo log主要有兩個(gè)作用：回滾和多版本控制MVCC

在數(shù)據(jù)修改的時(shí)候，不僅記錄了redo log，還記錄undo log，如果因?yàn)槟承┰驅(qū)е率聞?wù)失敗或回滾了，可以用undo log進(jìn)行回滾

undo log主要存儲(chǔ)的也是邏輯日志，比如我們要insert一條數(shù)據(jù)了，那undo log會(huì)記錄的一條對(duì)應(yīng)的delete日志。我們要update一條記錄時(shí)，它會(huì)記錄一條對(duì)應(yīng)相反的update記錄。

這也應(yīng)該容易理解，畢竟回滾嘛，跟需要修改的操作相反就好，這樣就能達(dá)到回滾的目的。因?yàn)橹С只貪L操作，所以我們就能保證：“一個(gè)事務(wù)包含多個(gè)操作，這些操作要么全部執(zhí)行，要么全都不執(zhí)行”?！驹有浴?/p>

因?yàn)?code>undo log存儲(chǔ)著修改之前的數(shù)據(jù)，相當(dāng)于一個(gè)前版本，MVCC實(shí)現(xiàn)的是讀寫不阻塞，讀的時(shí)候只要返回前一個(gè)版本的數(shù)據(jù)就行了。

到此這篇關(guān)于MySQL四種日志binlog/redolog/relaylog/undolog的文章就介紹到這了,更多相關(guān)mysql日志binlog/redolog/relaylog/undolog內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論