快捷導(dǎo)航

MySQL保證數(shù)據(jù)不丟失的方案詳解

更新時(shí)間：2023年12月21日 09:59:07 作者：王二蛋！

MySQL作為一個(gè)存儲(chǔ)數(shù)據(jù)的產(chǎn)品,怎么確保數(shù)據(jù)的持久性和不丟失才是最重要的,感興趣的可以跟隨本文一探究竟,文中通過圖文結(jié)合給大家講解的非常詳細(xì),需要的朋友快來跟著小編一起來學(xué)習(xí)吧

Buffer Pool 和 DML 的關(guān)系

InnoDB中的「Buffer Pool」除了在查詢時(shí)起到提高效率作用，同樣，在insert、update、delete這些DML操作時(shí)為了減少和磁盤的頻繁交互，也會(huì)將這些更新先在Buffer Pool中緩存的數(shù)據(jù)頁進(jìn)行操作，隨后將這些有更新的「臟頁」刷到磁盤中。

這個(gè)時(shí)候就涉及到一個(gè)問題：如果MySQL服務(wù)宕機(jī)了，這些在內(nèi)存中更新的數(shù)據(jù)會(huì)不會(huì)丟失？

答案是一定會(huì)存在丟失現(xiàn)象的，只不過MySQL做到了盡量不讓數(shù)據(jù)丟失。接下來來看一下MySQL是怎么做的。

這里還是把結(jié)構(gòu)圖貼一下，方便下面介紹時(shí)看圖理解。

在這里插入圖片描述

DML操作流程

加載數(shù)據(jù)頁

通過上文可以知道，行記錄是在數(shù)據(jù)頁中，所以，當(dāng)InnoDB接收到DML操作請(qǐng)求后，還是會(huì)去找「數(shù)據(jù)頁」，查找的過程跟上文查詢行記錄流程是一樣。這里說一下，insert的請(qǐng)求會(huì)根據(jù)主鍵索引去找數(shù)據(jù)頁，update、delete根據(jù)查詢條件去找數(shù)據(jù)頁，總之「數(shù)據(jù)頁」要加載到「Buffer Pool」之后才會(huì)進(jìn)行下一步操作。

更新記錄

定位到數(shù)據(jù)頁后，insert操作就是往數(shù)據(jù)頁中添加一行記錄，delete是標(biāo)記一下行記錄的‘刪除標(biāo)記’，而update則是先刪除再添加，這是因?yàn)榇嬖诳勺冮L的字段類型，比如varchar，每次更新時(shí)，這種類型的數(shù)據(jù)占用內(nèi)存是不固定的，所以先刪除再添加。

這里的刪除標(biāo)記是行記錄的字段，也就是除了業(yè)務(wù)字段數(shù)據(jù)，InnoDB默認(rèn)為每行記錄添加的字段，所以一個(gè)行記錄大概如下圖，這也是之前提到過的「行格式」。

在這里插入圖片描述

找到數(shù)據(jù)頁并且更新記錄之后DML操作就算完成了，但是還沒有落地到磁盤。

這個(gè)時(shí)候直接刷新到磁盤視為完成不可以嗎？

數(shù)據(jù)持久化方案

可以是可以，但是如果每次的DML操作都要將一個(gè)16KB的數(shù)據(jù)頁刷到磁盤，其效率是極低的，估計(jì)也就沒有人用MySQL了。但是如果不刷新到磁盤，就會(huì)發(fā)生MySQL服務(wù)宕機(jī)數(shù)據(jù)會(huì)丟失現(xiàn)象。MySQL在這里的處理方案是：

等待合適的時(shí)機(jī)將批量的「臟頁」異步刷新到磁盤。
先快速將更新的記錄以日志的形式刷新到磁盤。

先看第一點(diǎn)，什么時(shí)候是合適的時(shí)機(jī)？

合適的時(shí)機(jī)刷盤

當(dāng)「臟頁」在「Buffer Pool」中達(dá)到某個(gè)閾值的時(shí)候，InnoDB會(huì)將這些臟頁刷新到磁盤中。這個(gè)閾值可以通過 innodb_max_dirty_pages_pct 這個(gè)參數(shù)查看或設(shè)置，相關(guān)命令如下：

-- 查看臟頁刷新閾值
show variables like 'innodb_max_dirty_pages_pct'
-- 在線設(shè)置臟頁刷新閾值，當(dāng)臟頁在Buffer Pool占用70%的時(shí)候刷新
SET GLOBAL innodb_max_dirty_pages_pct = 70

在這里插入圖片描述

當(dāng)然，這個(gè)合適的時(shí)機(jī)只是為了減少與磁盤的交互，用來提高性能的，并不能確保數(shù)據(jù)不丟失。

雙寫機(jī)制

在刷新「臟頁」這里還有一個(gè)非常重要的注意事項(xiàng)就是：因?yàn)镮nnoDB的頁大小為16KB，而一般操作系統(tǒng)的頁大小為4KB。意味著InnoDB將這些「臟頁」向磁盤刷新時(shí)，在操作系統(tǒng)層面會(huì)被分成4個(gè)4KB的頁，這樣的話，如果其中有一頁因?yàn)镸ySQL宕機(jī)或者其他異常導(dǎo)致沒有成功刷新到磁盤，就會(huì)出現(xiàn)「頁損壞現(xiàn)象」，數(shù)據(jù)也就不完整了。

在這里插入圖片描述

所以InnoDB在這里采用的雙寫機(jī)制，在將這些「臟頁」刷新到磁盤之前先會(huì)往結(jié)構(gòu)圖中的「Doublewrite Buffer」中寫入，隨后再刷新到對(duì)應(yīng)的表空間中，當(dāng)出現(xiàn)故障時(shí)就可以通過雙寫緩沖區(qū)進(jìn)行恢復(fù)。

向「Doublewrite Buffer」就不會(huì)發(fā)生「頁損壞現(xiàn)象」？

「Doublewrite Buffer」的大小是獨(dú)立且固定的，不是基于頁的大小來劃分的。所以不受操作系統(tǒng)中的頁大小限制，也不會(huì)發(fā)生「頁損壞現(xiàn)象」。并且先以順序IO的方式向「Doublewrite Buffer」寫入數(shù)據(jù)頁，再以隨機(jī)IO異步刷新到表空間這種方式還可以提高寫入性能。

在這里插入圖片描述

再看第二點(diǎn)，為什么以日志的形式先刷新到磁盤？

日志先行機(jī)制

在「Buffer Pool」中更新完數(shù)據(jù)頁后，由于不會(huì)及時(shí)將這些「臟頁」刷新到磁盤，為了避免數(shù)據(jù)丟失，會(huì)將本次的DML操作向「Log Buffer」中寫一份并且刷新到磁盤中，相比16KB的數(shù)據(jù)頁來說，這個(gè)數(shù)據(jù)量會(huì)小很多，而且寫入日志文件時(shí)是追加操作，屬于順序IO，效率較高。如下圖，哪種方式寫入效率更高是顯而易見的。

在這里插入圖片描述

這里說的日志文件就是經(jīng)常會(huì)聽到的「Redo Log」，即使MySQL宕機(jī)了，通過磁盤的redolog，也可以在MySQL啟動(dòng)時(shí)盡可能的將數(shù)據(jù)恢復(fù)到宕機(jī)之前樣子。當(dāng)然，還有「Undo Log」，因?yàn)閷?duì)本文重點(diǎn)沒有直接影響，所以不對(duì)此展開說明。

這種日志先行（WAL）的機(jī)制也是MySQL用于提高效率和保障數(shù)據(jù)可靠的一種方式。

為什么是盡可能的恢復(fù)？

日志刷盤機(jī)制

因?yàn)椤?strong>Log Buffer」中的日志數(shù)據(jù)什么時(shí)候向磁盤刷新則是由 innodb_flush_log_at_trx_commit 和 innodb_flush_log_at_timeout 這兩個(gè)參數(shù)決定的。

innodb_flush_log_at_trx_commit默認(rèn)為1，也就是每次事務(wù)提交后就會(huì)刷新到磁盤。
當(dāng)innodb_flush_log_at_trx_commit設(shè)置為0時(shí)，則不會(huì)根據(jù)事務(wù)提交來刷新，而是根據(jù)innodb_flush_log_at_timeout設(shè)置的時(shí)間定時(shí)刷新，這個(gè)時(shí)間默認(rèn)為1秒。
當(dāng)innodb_flush_log_at_trx_commit設(shè)置為2時(shí)，僅將日志寫入操作系統(tǒng)中的緩存中，隨后跟隨根據(jù)innodb_flush_log_at_timeout定時(shí)刷新。

如果在MySQL服務(wù)宕機(jī)的時(shí)候，「Log Buffer」中的日志沒有刷新到磁盤，這部分?jǐn)?shù)據(jù)也是會(huì)丟失的，在重啟后也不會(huì)恢復(fù)。所以如果不想丟失數(shù)據(jù)，在性能還可以的情況下，盡量將innodb_flush_log_at_trx_commit設(shè)置為1。

「redo log」是怎么恢復(fù)數(shù)據(jù)的？

Redo Log 恢復(fù)數(shù)據(jù)

首先，redo log會(huì)記錄DML的操作類型、數(shù)據(jù)的表空間、數(shù)據(jù)頁以及具體操作內(nèi)容，以 insert into t1(1,'hi')為例，對(duì)應(yīng)的redo log內(nèi)容大概這樣的

在這里插入圖片描述

假如 innodb_flush_log_at_trx_commit 的值為1，那么當(dāng)該DML操作事務(wù)提交后，就會(huì)將 redo log 刷新到磁盤。成功刷新到磁盤后，就可以視為數(shù)據(jù)被寫入成功。

此時(shí)如果「臟頁」還沒刷新到磁盤便宕機(jī)，那么在下次MySQL啟動(dòng)時(shí)便去加載redo log，如果redo log存在數(shù)據(jù)則意味著需要恢復(fù)數(shù)據(jù)。這個(gè)時(shí)候就可以通過redo log中的內(nèi)容重新構(gòu)建「臟頁」，從而恢復(fù)到宕機(jī)之前的狀態(tài)。

怎么構(gòu)建「臟頁」呢？

其實(shí)在每次的redo log寫入時(shí)都會(huì)記錄一個(gè)「LSN（log sequence number）」，同時(shí)這個(gè)值在「數(shù)據(jù)頁」中記錄最后一次被修改的日志序列位置。MySQL在啟動(dòng)時(shí)通過LSN來對(duì)比 redo log 和數(shù)據(jù)頁，如果數(shù)據(jù)頁中的LSN小于 redo log 的LSN，則會(huì)將該數(shù)據(jù)頁加載到「Buffer Pool」，然后根據(jù) redo log 的內(nèi)容構(gòu)建出「臟頁」，等待下次刷新到磁盤，數(shù)據(jù)也就恢復(fù)了。如下圖

在這里插入圖片描述

注意：這個(gè)恢復(fù)的過程重點(diǎn)在redo上，實(shí)際上還涉及到「Change Buffer」、「Undo Log」等操作，這里沒有展開說明。

「Doublewrite Buffer」和「redo log」都是恢復(fù)數(shù)據(jù)的，不沖突嗎？

不沖突，「Doublewrite Buffer」是對(duì)「頁損壞現(xiàn)象」的整個(gè)數(shù)據(jù)頁進(jìn)行恢復(fù)，Redo Log只能對(duì)某次的DML操作進(jìn)行恢復(fù)。

總結(jié)

InnoDB通過以上的操作可以盡可能的保證MySQL不丟失數(shù)據(jù)，最后再總結(jié)一下MySQL是如何保障數(shù)據(jù)不丟失的：

為了避免頻繁與磁盤交互，每次DML操作先在「Buffer Pool」中的緩存頁中執(zhí)行，緩存頁有更新之后便成為「臟頁」，隨后根據(jù)innodb_max_dirty_pages_pct這個(gè)參數(shù)將「臟頁」刷新到磁盤。
因?yàn)椤?strong>臟頁」在刷新到磁盤之前可能會(huì)存在MySQL宕機(jī)等異常行為導(dǎo)致數(shù)據(jù)丟失，所以MySQL采用日志先行（WAL）機(jī)制，將DML操作以日志的形式進(jìn)行記錄到「Redo Log」中，隨后根據(jù)innodb_flush_log_at_trx_commit 和 innodb_flush_log_at_timeout這兩個(gè)參數(shù)將「Redo Log」刷新到磁盤，以便恢復(fù)。
在向磁盤刷新「臟頁」時(shí)，為了避免發(fā)生「頁損壞」現(xiàn)象，InnoDB采用雙寫機(jī)制，先將這些臟頁順序?qū)懭搿?strong>Doublewrite Buffer」中，隨后再將數(shù)據(jù)頁異步刷新到各個(gè)表空間中，這種方式既能提高寫入效率，又可以保障數(shù)據(jù)的完整性。
如果在「臟頁」刷新到磁盤之前，MySQL宕機(jī)了，那么會(huì)在下次啟動(dòng)時(shí)通過 redo log 將臟頁構(gòu)建出來，做到數(shù)據(jù)恢復(fù)。
通過以上步驟，MySQL做到了盡可能的不丟失數(shù)據(jù)。