自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

突然掉電,為啥MySQL也不會(huì)丟失數(shù)據(jù)?

精選
數(shù)據(jù)庫 MySQL
MySQL采用buffer機(jī)制,避免每次讀寫進(jìn)行磁盤IO,提升效率,那么,問題來了,這個(gè)操作并非原子,如果執(zhí)行到一半斷電,會(huì)不會(huì)出現(xiàn)問題呢?

MySQL采用buffer機(jī)制,避免每次讀寫進(jìn)行磁盤IO,提升效率:

MySQL的buffer一頁的大小是16K,文件系統(tǒng)一頁的大小是4K,也就是說,MySQL將buffer中一頁數(shù)據(jù)刷入磁盤,要寫4個(gè)文件系統(tǒng)里的頁。

如上圖所示,MySQL里page=1的頁,物理上對應(yīng)磁盤上的1+2+3+4四個(gè)格。

那么,問題來了,這個(gè)操作并非原子,如果執(zhí)行到一半斷電,會(huì)不會(huì)出現(xiàn)問題呢?

會(huì),這就是所謂的“頁數(shù)據(jù)損壞”。

如上圖所示,MySQL內(nèi)page=1的頁準(zhǔn)備刷入磁盤,才刷了3個(gè)文件系統(tǒng)里的頁,掉電了,則會(huì)出現(xiàn):重啟后,page=1的頁,物理上對應(yīng)磁盤上的1+2+3+4四個(gè)格,數(shù)據(jù)完整性被破壞。

畫外音:redo無法修復(fù)這類“頁數(shù)據(jù)損壞”的異常,修復(fù)的前提是“頁數(shù)據(jù)正確”并且redo日志正常。

如何解決這類“頁數(shù)據(jù)損壞”的問題呢?

很容易想到的方法是,能有一個(gè)“副本”,對原來的頁進(jìn)行還原,這個(gè)存儲(chǔ)“副本”的地方,就是Double Write Buffer。

Double Write Buffer,但它與傳統(tǒng)的buffer又不同,它分為內(nèi)存和磁盤的兩層架構(gòu)。

畫外音:傳統(tǒng)的buffer,大部分是內(nèi)存存儲(chǔ);而DWB里的數(shù)據(jù),是需要落地的。

如上圖所示,當(dāng)有頁數(shù)據(jù)要刷盤時(shí):

  • 第一步:頁數(shù)據(jù)先memcopy到DWB的內(nèi)存里;
  • 第二步:DWB的內(nèi)存里,會(huì)先刷到DWB的磁盤上;
  • 第三步:DWB的內(nèi)存里,再刷到數(shù)據(jù)磁盤存儲(chǔ)上;

畫外音:DWB由128個(gè)頁構(gòu)成,容量只有2M。

步驟2和步驟3要寫2次磁盤,這就是“Double Write”的由來。

DWB為什么能解決“頁數(shù)據(jù)損壞”問題呢?

假設(shè)步驟2掉電,磁盤里依然是1+2+3+4的完整數(shù)據(jù)。

畫外音:只要有頁數(shù)據(jù)完整,就能通過redo還原數(shù)據(jù)。

假如步驟3掉電,DWB里存儲(chǔ)著完整的數(shù)據(jù)。

所以,一定不會(huì)出現(xiàn)“頁數(shù)據(jù)損壞”問題。

畫外音:寫了2次,總有一個(gè)地方的數(shù)據(jù)是OK的。

自己實(shí)驗(yàn)了幾十次,仍沒能復(fù)現(xiàn)“頁數(shù)據(jù)損壞”,在網(wǎng)上找了一個(gè)“頁數(shù)據(jù)損壞”時(shí),MySQL重啟過程利用DWB修復(fù)頁數(shù)據(jù)的圖。

可以看到,啟動(dòng)過程中:

  • InnoDB檢測到上一次為異常關(guān)閉;
  • 嘗試恢復(fù)ibd數(shù)據(jù),失?。?/li>
  • 從DWB中恢復(fù)寫了一半的頁;

能夠通過DWB保證頁數(shù)據(jù)的完整性,但畢竟DWB要寫兩次磁盤,會(huì)不會(huì)導(dǎo)致數(shù)據(jù)庫性能急劇降低呢?

分析DWB執(zhí)行的三個(gè)步驟:

  • 第一步,頁數(shù)據(jù)memcopy到DWB的內(nèi)存,速度很快;
  • 第二步,DWB的內(nèi)存fsync刷到DWB的磁盤,屬于順序追加寫,速度也很快;
  • 第三步,刷磁盤,隨機(jī)寫,本來就需要進(jìn)行,不屬于額外操作;

另外,128頁(每頁16K)2M的DWB,會(huì)分兩次刷入磁盤,每次最多64頁,即1M的數(shù)據(jù),執(zhí)行也是非常之快的。

綜上,性能會(huì)有所影響,但影響并不大。

畫外音:

  • write--ahead-log之所以性能高,就是因?yàn)轫樞蜃芳訉懀?/li>
  • 有第三方測評,評估約10%性能損失;

更具體的,InnoDB里有兩個(gè)變量可以查看double write buffer相關(guān)的情況:

  • Innodb_dblwr_pages_written:記錄寫入DWB中頁的數(shù)量。
  • Innodb_dblwr_writes:記錄DWB寫操作的次數(shù)。

可以通過:

show global status like "%dblwr%"

來進(jìn)行查詢。

結(jié)尾

MySQL有很強(qiáng)的數(shù)據(jù)安全性機(jī)制:

  • 在異常崩潰時(shí),如果不出現(xiàn)“頁數(shù)據(jù)損壞”,能夠通過redo恢復(fù)數(shù)據(jù);
  • 在出現(xiàn)“頁數(shù)據(jù)損壞”時(shí),能夠通過double write buffer恢復(fù)頁數(shù)據(jù);

double write buffer:

  • 不是一個(gè)內(nèi)存buffer,是一個(gè)內(nèi)存/磁盤兩層的結(jié)構(gòu),是InnoDB里On-Disk架構(gòu)里很重要的一部分;
  • 是一個(gè)通過寫兩次,保證頁完整性的機(jī)制;

知其然,知其所以然。

思路比結(jié)論重要,希望大家有收獲。

責(zé)任編輯:趙寧寧 來源: 架構(gòu)師之路
相關(guān)推薦

2021-01-08 05:29:40

MySQL日志數(shù)據(jù)

2023-06-12 09:08:47

CSS語法雙斜杠

2022-09-16 17:25:26

加密貨幣存儲(chǔ)以太坊

2022-07-27 18:34:32

RabbitMQ宕機(jī)服務(wù)器

2022-10-19 09:05:45

編譯程序員后端

2018-09-06 14:18:05

硬盤數(shù)據(jù)恢復(fù)

2021-06-04 12:05:03

Redis Bitmap 數(shù)據(jù)庫

2017-12-01 06:02:14

耦合數(shù)據(jù)庫CA

2017-02-08 19:42:10

數(shù)據(jù)中心掉電電源

2021-06-23 09:52:22

Web開發(fā)數(shù)據(jù)

2022-07-31 22:07:03

宕機(jī)業(yè)務(wù)場景

2017-02-07 18:00:44

數(shù)據(jù)電源ORACLE

2024-08-07 08:02:08

2015-01-14 10:32:45

物聯(lián)網(wǎng)智能手機(jī)

2009-11-06 13:40:07

2009-02-03 13:11:09

冰島綠色I(xiàn)T數(shù)據(jù)中心

2021-08-02 09:01:29

PythonMySQL 數(shù)據(jù)庫

2010-05-25 09:29:04

MySQL數(shù)據(jù)庫

2017-12-13 09:21:29

內(nèi)存數(shù)據(jù)庫Redis

2022-12-16 17:15:33

MQRabbitMQ
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號