ps

真實的流程沒有我說的那么簡單，下面的是最基本的情況。

預(yù)備知識redolog

binlog

WAL機(jī)制

redolog簡介

redolog是個循環(huán)日志，其大小固定為4g，存在2個指針來定位其是否已經(jīng)滿了。一個指針是當(dāng)前寫，一個指針是當(dāng)前checkpoint,其2個指針的順時針空間就是可寫的空間。

這個redolog就是完成mysql突然宕機(jī)后，如何無損恢復(fù)數(shù)據(jù)的。

binlog簡介

這個是mysql自身的日志，叫做歸檔日志。和redolog大致3個不同點。其為mysql自帶的，redolog是innodb里面的。

redolog是物理日志，binlog是邏輯日志。

redolog是循環(huán)日志，binlog是增量日志。

這里不對其過多介紹，下一篇文章關(guān)于主從的詳細(xì)介紹，主從就是通過binlog完成的。

WAL機(jī)制簡介

MySQL里經(jīng)常說到的 WAL 技術(shù)，意思就是數(shù)據(jù)入庫前先寫進(jìn)去日志，再寫磁盤里面。

這里采用的是數(shù)據(jù)安全性最高的雙1策略。

其數(shù)據(jù)更新順序也保持著其順序。

下面我來簡單介紹下。

1.當(dāng)要更新id=2這一行數(shù)據(jù)時，先通過這個表的索引，查詢到這行記錄所在的數(shù)據(jù)頁。然后判斷這個數(shù)據(jù)頁是否在buffer pool(這個是內(nèi)存)。

2.如果不在內(nèi)存則需要讀到內(nèi)存(其實也可以不用讀入內(nèi)存，當(dāng)要更新的這行數(shù)據(jù)沒有唯一索引時，mysql為了提高效率，采用了change buffer(別看有個buffer，但是人家也是持久化到磁盤的)這個東西，將對這行修改的動作記錄到change buffer里面，就不用讀到內(nèi)存了)。

3.在buffer pool 內(nèi)存上修改這行數(shù)據(jù)(僅僅只是在內(nèi)存上修改了這行數(shù)據(jù)，并沒有持久化到磁盤里面)。

4.將上面的操作，寫入到redolog里面，且將這個操作狀態(tài)設(shè)置為prepare狀態(tài)，首先寫到redologbuffer里面(為了提高效率，mysql做了組提交這個優(yōu)化，這里不擴(kuò)展)，等到這個事務(wù)提交后，redologbuffer然后再寫入到文件系統(tǒng)的page cache里面，然后立馬調(diào)用fsync,將其刷到磁盤。

5.然后寫入到binlog里面，先寫到binlog cache里面，然后寫入page cache,然后調(diào)用fsync，寫入磁盤。

6.redolog繼續(xù)寫一次，將其狀態(tài)設(shè)置為commit狀態(tài)。

如此就算完成了一個更新操作。

mysql 如何做到crash后，數(shù)據(jù)不丟失的

前面說了數(shù)據(jù)更新操作。

當(dāng)前buffer pool里面存在大量臟頁(就是一些數(shù)據(jù)頁，只在內(nèi)存里面修改了，沒有刷新到磁盤)，當(dāng)系統(tǒng)宕機(jī)了，內(nèi)存里面的數(shù)據(jù)全部丟失了怎么辦？

方法如下：我們需要redolog來完成災(zāi)難備份，check point到writ pos這塊空間記錄的所有的操作步驟派上用場了，根據(jù)這些redolog記錄從磁盤里面讀取所有相關(guān)的數(shù)據(jù)頁。然后按照redolog上的操作恢復(fù)數(shù)據(jù)即可，那么我們發(fā)現(xiàn)存再內(nèi)存的數(shù)據(jù)全部恢復(fù)了。

總結(jié)

以上是生活随笔為你收集整理的mysql crash 如何导出数据库_mysql 如何做到crash后无损恢复数据的的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。