MySQL四種日志binlog/redolog/relaylog/undolog詳解
一、binlog
binlog
記錄數(shù)據(jù)庫表結(jié)構(gòu)和表數(shù)據(jù)變更,比如update/delete/insert/truncate/create
,它不會記錄select
。存儲著每條變更的SQL
語句和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語句 /*!*/; # at 669 #168654 20:22:45 server id 1 end_log_pos 876 Xid = 12 #執(zhí)行的時間和事務(wù)ID
主要有兩個作用:復(fù)制和恢復(fù)數(shù)據(jù)
【1】MySQL
架構(gòu)為了高可用性都是一主多從,從服務(wù)器需要與主服務(wù)器保持數(shù)據(jù)一致,這就是通過binlog
進行復(fù)制;
【2】數(shù)據(jù)庫的數(shù)據(jù)如果被誤刪,可以通過binlog
數(shù)據(jù)進行恢復(fù)。
因為
binlog
記錄了數(shù)據(jù)庫表的邏輯變更,所以可以用binlog
進行主從復(fù)制和恢復(fù)數(shù)據(jù)。
二、redo log
MySQL
執(zhí)行SQL
修改語句時,肯定是先把這條記錄查出來,然后再將這條進行進行修改。因為Mysql
的基本存儲結(jié)構(gòu)是頁,記錄都存在頁里邊,所以MySQL
是先把這條記錄所在的頁找到,然后把該頁加載到內(nèi)存中,將對應(yīng)記錄進行修改?,F(xiàn)在就可能存在一個問題:如果在內(nèi)存中把數(shù)據(jù)改了,還沒來得及落磁盤,而此時的數(shù)據(jù)庫掛了,導(dǎo)致這次修改丟失了怎么辦?
如果每個請求都需要將數(shù)據(jù)立馬同步到磁盤,那速度會很慢,MySQL
可能也頂不住。所以MySQL
引入了redo log
,內(nèi)存寫完了,然后會寫一份redo log
,這份redo log
記載著這次在某個頁上做了什么修改。
寫redo log
的時候,也會有buffer
,是先寫buffer
,再真正落到磁盤中的。至于從buffer
什么時候落磁盤,會有配置供我們配置。
寫redo log
也是需要寫磁盤的,但它的好處就是順序IO
(我們都知道順序IO
比隨機IO
快非常多)。
所以,redo log
的存在為了:當(dāng)我們修改的時候,寫完內(nèi)存了,但數(shù)據(jù)還沒真正寫到磁盤的時候。此時我們的數(shù)據(jù)庫掛了,我們可以根據(jù)redo log
來對數(shù)據(jù)進行恢復(fù)。因為redo log
是順序IO
,所以寫入的速度很快,并且redo log
記載的是物理變化(x頁做了y修改),文件的體積很小,恢復(fù)速度很快。
三、binlog與redolog的區(qū)別
兩個日志較為相似,這里總結(jié)下兩者的主要區(qū)別:
【1】存儲內(nèi)容不同: binlog
記載的是update/delete/insert
這樣的SQL
語句,而redo log
記載的是物理修改的內(nèi)容(x頁修改了y)。redo log
記錄的是數(shù)據(jù)的物理變化,binlog
記錄的是數(shù)據(jù)的邏輯變化。
【2】功能: redo log
的作用是為持久化而生的。寫完內(nèi)存,如果數(shù)據(jù)庫掛了,那我們可以通過redo log
來恢復(fù)內(nèi)存還沒來得及刷到磁盤的數(shù)據(jù),將redo log
加載到內(nèi)存里邊,那內(nèi)存就能恢復(fù)到掛掉之前的數(shù)據(jù)了。binlog
的作用是復(fù)制和恢復(fù)而生的。主從服務(wù)器需要保持數(shù)據(jù)的一致性,通過binlog
來同步數(shù)據(jù)。如果整個數(shù)據(jù)庫的數(shù)據(jù)都被刪除了,binlog
存儲著所有的數(shù)據(jù)變更情況,那么可以通過binlog
來對數(shù)據(jù)進行恢復(fù)。
如果整個數(shù)據(jù)庫的數(shù)據(jù)都被刪除了,那我可以用redo log
的記錄來恢復(fù)嗎?
不能,因為功能的不同,redo log 存儲的是物理數(shù)據(jù)的變更,如果我們內(nèi)存的數(shù)據(jù)已經(jīng)刷到了磁盤了,那redo log的數(shù)據(jù)就無效了。所以redo log不會存儲著歷史所有數(shù)據(jù)的變更,文件的內(nèi)容會被覆蓋的。
【3】寫入細節(jié)不同: redo log
是MySQL
的InnoDB
引擎所產(chǎn)生的。binlog
無論MySQL
任何引擎都會有的。InnoDB
是有事務(wù)的,事務(wù)的四大特性之一:持久性就是靠redo log
來實現(xiàn)的(如果寫入內(nèi)存成功,但數(shù)據(jù)還沒真正刷到磁盤,如果此時的數(shù)據(jù)庫掛了,我們可以靠redo log
來恢復(fù)內(nèi)存的數(shù)據(jù),這就實現(xiàn)了持久性)。
上面也提到,在修改的數(shù)據(jù)的時候,binlog
會記載著變更的類容,redo log
也會記載著變更的內(nèi)容。(只不過一個存儲的是物理變化,一個存儲的是邏輯變化)。那他們的寫入順序是什么樣的呢?
redo log
事務(wù)開始的時候,就開始記錄每次的變更信息,而binlog
是在事務(wù)提交的時候才記錄。
于是新有的問題又出現(xiàn)了:我寫其中的某一個log
,失敗了,那會怎么辦?現(xiàn)在我們的前提是先寫redo log
,再寫binlog
,我們來看看:
■ 如果寫redo log
失敗了,那我們就認為這次事務(wù)有問題,回滾,不再寫binlog
。
■ 如果寫redo log
成功了,寫binlog
,寫binlog
寫一半了,但失敗了怎么辦?我們還是會對這次的事務(wù)回滾,將無效的binlog
給刪除(因為binlog
會影響從庫的數(shù)據(jù),所以需要做刪除操作)
■ 如果寫redo log
和binlog
都成功了,那這次算是事務(wù)才會真正成功。
簡單來說:MySQL
需要保證redo log
和binlog
的數(shù)據(jù)是一致的,如果不一致,那就亂套了。
■ 如果redo log
寫失敗了,而binlog
寫成功了。那假設(shè)內(nèi)存的數(shù)據(jù)還沒來得及落磁盤,機器就掛掉了。那主從服務(wù)器的數(shù)據(jù)就不一致了。(從服務(wù)器通過binlog
得到最新的數(shù)據(jù),而主服務(wù)器由于redo log
沒有記載,沒法恢復(fù)數(shù)據(jù))
■ 如果redo log
寫成功了,而binlog
寫失敗了。那從服務(wù)器就拿不到最新的數(shù)據(jù)了。
MySQL
通過兩階段提交來保證redo log
和binlog
的數(shù)據(jù)是一致的。
階段1:InnoDB redo log
寫盤,InnoDB
事務(wù)進入prepare
狀態(tài)
階段2:binlog
寫盤,InooDB
事務(wù)進入commit
狀態(tài)
每個事務(wù)binlog
的末尾,會記錄一個XID event
,標(biāo)志著事務(wù)是否提交成功,也就是說,恢復(fù)過程中,binlog
最后一個XID event
之后的內(nèi)容都應(yīng)該被purge
。
如果binlog
沒有正常關(guān)閉,mysql server
可能crash
過,我們需要調(diào)用MYSQL_BIN_LOG::recover:
找到最后一個XID
完成最后一次事務(wù)的兩階段提交InnoDB commit
。因此,需要遍歷binlog
文件,找到最后一個合法event
集合,并purge
無效binlog
四、relay-log
從服務(wù)器I/O
線程將主服務(wù)器的二進制日志讀取過來記錄到從服務(wù)器本地文件,然后從服務(wù)器SQL
線程會讀取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
,則默認值為max_binlog_size (1G)
。如果不為0
,則max_relay_log_size
則為最大的relay_log
文件大?。?/p>
relay_log
: 定義relay_log
的位置和名稱,如果值為空,則默認位置在數(shù)據(jù)文件的目錄;
relay_log_index
:定義relay_log
索引的位置和名稱,記錄有幾個relay_log
文件,默認為2
個
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
主庫的binary_log
的恢復(fù)位置和從庫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
:是否自動清空中繼日志,默認值為1(啟用);
relay_log_recovery
:
當(dāng)slave
從庫宕機后,假如relay-log
損壞了,導(dǎo)致一部分中繼日志沒有處理,則自動放棄所有未執(zhí)行的relay-log
,并且重新從master
上獲取日志,這樣就保證了relay-log
的完整性。默認情況下該功能是關(guān)閉的,將relay_log_recovery
的值設(shè)置為1
時,可在slave
從庫上開啟該功能,建議開啟;
sync_relay_log
:當(dāng)設(shè)置為1
時,slave
的I/O
線程每次接收到master
發(fā)送過來的binlog
日志都要寫入系統(tǒng)緩沖區(qū),然后刷入relay log
中繼日志里,這樣是最安全的,因為在崩潰的時候,你最多會丟失一個事務(wù),但會造成磁盤的大量I/O
。當(dāng)設(shè)置為0
時,并不是馬上就刷入中繼日志里,而是由操作系統(tǒng)決定何時來寫入,雖然安全性降低了,但減少了大量的磁盤I/O
操作。這個值默認是0
,可動態(tài)修改;
sync_relay_log_info
:這個參數(shù)和sync_relay_log
參數(shù)一樣。
五、undo log
undo log
主要有兩個作用:回滾和多版本控制MVCC
在數(shù)據(jù)修改的時候,不僅記錄了redo log
,還記錄undo log
,如果因為某些原因?qū)е率聞?wù)失敗或回滾了,可以用undo log
進行回滾
undo log
主要存儲的也是邏輯日志,比如我們要insert
一條數(shù)據(jù)了,那undo log
會記錄的一條對應(yīng)的delete
日志。我們要update
一條記錄時,它會記錄一條對應(yīng)相反的update
記錄。
這也應(yīng)該容易理解,畢竟回滾嘛,跟需要修改的操作相反就好,這樣就能達到回滾的目的。因為支持回滾操作,所以我們就能保證:“一個事務(wù)包含多個操作,這些操作要么全部執(zhí)行,要么全都不執(zhí)行”?!驹有浴?/p>
因為undo log
存儲著修改之前的數(shù)據(jù),相當(dāng)于一個前版本,MVCC
實現(xiàn)的是讀寫不阻塞,讀的時候只要返回前一個版本的數(shù)據(jù)就行了。
到此這篇關(guān)于MySQL四種日志binlog/redolog/relaylog/undolog的文章就介紹到這了,更多相關(guān)mysql日志binlog/redolog/relaylog/undolog內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
MySQL升級PostgreSQL遇到的一些常見問題及解決方案
MySQL是一款性能優(yōu)越、數(shù)據(jù)可靠性高的數(shù)據(jù)庫軟件,然而為了保證其長期有效運行,數(shù)據(jù)庫升級是非常重要的,下面這篇文章主要給大家介紹了關(guān)于MySQL升級PostgreSQL遇到的一些常見問題及解決方案的相關(guān)資料,需要的朋友可以參考下2024-05-05MySQL5.7限制general_log日志大小的實現(xiàn)
MySQL5.7.41中為避免通用查詢?nèi)罩緂eneral_log快速增長占用硬盤空間,可以通過定時任務(wù)執(zhí)行腳本進行每日備份或清理,從而限制其大小,文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2024-10-10以mysql為例詳解ToplingDB?的?UintIndex
本文主要介紹了以mysql為例詳解ToplingDB的UintIndex,在ToplingDB的CO-Index(Compressed?Ordered?Index)家族中,Nest?Succinct?Trie是最通用的,更多相關(guān)內(nèi)容需要的朋友可以參考一下2022-08-08Mysql 5.7 服務(wù)下載安裝圖文教程(經(jīng)典版)
MySQL 5.7在諸多方面都進行了大幅的改進,主要在于安全性、靈活性、易用性、可用性和性能等幾個方面。這篇文章主要介紹了Mysql5.7服務(wù)下載安裝圖文教程(經(jīng)典版),需要的朋友可以參考下2016-09-09update.where無索引導(dǎo)致MySQL死鎖問題解決
這篇文章主要為大家介紹了update.where無索引導(dǎo)致MySQL死鎖問題解決,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2022-11-11詳解MySQL監(jiān)控工具 mysql-monitor
這篇文章主要介紹了解MySQL監(jiān)控工具 mysql-monitor的相關(guān)知識,本文通過實例代碼給大家介紹的非常詳細,對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友參考下吧2020-07-07Linux下安裝Mysql多實例作為數(shù)據(jù)備份服務(wù)器實現(xiàn)多主到一從多實例的備份
由于第一次接觸LINUX,花了三天時間才算有所成就,發(fā)出來希望可以給大伙帶來方便2010-07-07