一、什麼是binlog
binlog
其實在日常的開發中是聽得很多的,因爲很多時候數據的更新就依賴着binlog
。
舉個很簡單的例子:我們的數據是保存在數據庫裏邊的嘛,現在我們對某個商品的某個字段的內容改了(數據庫變更),而用戶檢索的出來數據是走搜索引擎的。爲了讓用戶能搜到最新的數據,我們需要把引擎的數據也改掉。
一句話:數據庫的變更,搜索引擎的數據也需要變更。
於是,我們就會監聽binlog
的變更,如果binlog
有變更了,那我們就需要將變更寫到對應的數據源。
什麼是
binlog
?
binlog
記錄了數據庫表結構和表數據變更,比如update/delete/insert/truncate/create
。它不會記錄select
(因爲這沒有對錶沒有進行變更)
binlog
長什麼樣?
binlog
我們可以簡單理解爲:存儲着每條變更的SQL
語句(當然從下面的圖看來看,不止SQL,還有XID「事務Id」等等)
binlog
一般用來做什麼
主要有兩個作用:複製和恢復數據
-
MySQL在公司使用的時候往往都是一主多從結構的,從服務器需要與主服務器的數據保持一致,這就是通過
binlog
來實現的 -
數據庫的數據被幹掉了,我們可以通過
binlog
來對數據進行恢復。
因爲binlog
記錄了數據庫表的變更,所以我們可以用binlog
進行復制(主從複製)和恢復數據。
二、什麼是redo log
假設我們有一條sql語句:
update user_table set name='java3y' where id = '3'
MySQL執行這條SQL語句,肯定是先把id=3
的這條記錄查出來,然後將name
字段給改掉。這沒問題吧?
實際上Mysql的基本存儲結構是頁(記錄都存在頁裏邊),所以MySQL是先把這條記錄所在的頁找到,然後把該頁加載到內存中,將對應記錄進行修改。
現在就可能存在一個問題:如果在內存中把數據改了,還沒來得及落磁盤,而此時的數據庫掛了怎麼辦?顯然這次更改就丟了。
如果每個請求都需要將數據立馬落磁盤之後,那速度會很慢,MySQL可能也頂不住。所以MySQL是怎麼做的呢?
MySQL引入了redo log
,內存寫完了,然後會寫一份redo log
,這份redo log
記載着這次在某個頁上做了什麼修改。
其實寫redo log
的時候,也會有buffer
,是先寫buffer
,再真正落到磁盤中的。至於從buffer
什麼時候落磁盤,會有配置供我們配置。
寫redo log
也是需要寫磁盤的,但它的好處就是順序IO
(我們都知道順序IO比隨機IO快非常多)。
所以,redo log
的存在爲了:當我們修改的時候,寫完內存了,但數據還沒真正寫到磁盤的時候。此時我們的數據庫掛了,我們可以根據redo log
來對數據進行恢復。因爲redo log
是順序IO,所以寫入的速度很快,並且redo log
記載的是物理變化(xxxx頁做了xxx修改),文件的體積很小,恢復速度很快。
三、binlog和redo log
看到這裏,你可能會想:binlog
和redo log
這倆也太像了吧,都是用作”恢復“的。
其實他倆除了"恢復"這塊是相似的,很多都不一樣,下面看我列一下。
存儲的內容
binlog
記載的是update/delete/insert
這樣的SQL語句,而redo log
記載的是物理修改的內容(xxxx頁修改了xxx)。
所以在搜索資料的時候會有這樣的說法:redo log
記錄的是數據的物理變化,binlog
記錄的是數據的邏輯變化
功能
redo log
的作用是爲持久化而生的。寫完內存,如果數據庫掛了,那我們可以通過redo log
來恢復內存還沒來得及刷到磁盤的數據,將redo log
加載到內存裏邊,那內存就能恢復到掛掉之前的數據了。
binlog
的作用是複製和恢復而生的。
-
主從服務器需要保持數據的一致性,通過
binlog
來同步數據。 -
如果整個數據庫的數據都被刪除了,
binlog
存儲着所有的數據變更情況,那麼可以通過binlog
來對數據進行恢復。
又看到這裏,你會想:”如果整個數據庫的數據都被刪除了,那我可以用redo log
的記錄來恢復嗎?“不能
因爲功能的不同,redo log
存儲的是物理數據的變更,如果我們內存的數據已經刷到了磁盤了,那redo log
的數據就無效了。所以redo log
不會存儲着歷史所有數據的變更,文件的內容會被覆蓋的。
binlog和redo log 寫入的細節
redo log
是MySQL的InnoDB引擎所產生的。
binlog
無論MySQL用什麼引擎,都會有的。
InnoDB是有事務的,事務的四大特性之一:持久性就是靠redo log
來實現的(如果寫入內存成功,但數據還沒真正刷到磁盤,如果此時的數據庫掛了,我們可以靠redo log
來恢復內存的數據,這就實現了持久性)。
上面也提到,在修改的數據的時候,binlog
會記載着變更的類容,redo log
也會記載着變更的內容。(只不過一個存儲的是物理變化,一個存儲的是邏輯變化)。那他們的寫入順序是什麼樣的呢?
redo log
事務開始的時候,就開始記錄每次的變更信息,而binlog
是在事務提交的時候才記錄。
於是新有的問題又出現了:我寫其中的某一個log
,失敗了,那會怎麼辦?現在我們的前提是先寫redo log
,再寫binlog
,我們來看看:
-
如果寫
redo log
失敗了,那我們就認爲這次事務有問題,回滾,不再寫binlog
。 -
如果寫
redo log
成功了,寫binlog
,寫binlog
寫一半了,但失敗了怎麼辦?我們還是會對這次的事務回滾,將無效的binlog
給刪除(因爲binlog
會影響從庫的數據,所以需要做刪除操作) -
如果寫
redo log
和binlog
都成功了,那這次算是事務纔會真正成功。
簡單來說:MySQL需要保證redo log
和binlog
的數據是一致的,如果不一致,那就亂套了。
-
如果
redo log
寫失敗了,而binlog
寫成功了。那假設內存的數據還沒來得及落磁盤,機器就掛掉了。那主從服務器的數據就不一致了。(從服務器通過binlog
得到最新的數據,而主服務器由於redo log
沒有記載,沒法恢復數據) -
如果
redo log
寫成功了,而binlog
寫失敗了。那從服務器就拿不到最新的數據了。
MySQL通過兩階段提交來保證redo log
和binlog
的數據是一致的。
過程:
-
階段1:InnoDB
redo log
寫盤,InnoDB 事務進入prepare
狀態 -
階段2:
binlog
寫盤,InooDB 事務進入commit
狀態 -
每個事務
binlog
的末尾,會記錄一個XID event
,標誌着事務是否提交成功,也就是說,恢復過程中,binlog
最後一個 XID event 之後的內容都應該被 purge。
四、什麼是undo log
undo log
有什麼用?
undo log
主要有兩個作用:回滾和多版本控制(MVCC)
在數據修改的時候,不僅記錄了redo log
,還記錄undo log
,如果因爲某些原因導致事務失敗或回滾了,可以用undo log
進行回滾
undo log
主要存儲的也是邏輯日誌,比如我們要insert
一條數據了,那undo log
會記錄的一條對應的delete
日誌。我們要update
一條記錄時,它會記錄一條對應相反的update記錄。
這也應該容易理解,畢竟回滾嘛,跟需要修改的操作相反就好,這樣就能達到回滾的目的。因爲支持回滾操作,所以我們就能保證:“一個事務包含多個操作,這些操作要麼全部執行,要麼全都不執行”。【原子性】
因爲undo log
存儲着修改之前的數據,相當於一個前版本,MVCC實現的是讀寫不阻塞,讀的時候只要返回前一個版本的數據就行了。