為什么數(shù)據(jù)庫會(huì)丟失數(shù)據(jù)

今天就跟大家聊聊有關(guān)為什么數(shù)據(jù)庫會(huì)丟失數(shù)據(jù)，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

數(shù)據(jù)庫管理系統(tǒng)在今天已經(jīng)是軟件的重要組成部分，開源的 MySQL、PostgreSQL 以及商業(yè)化的 Oracle 等數(shù)據(jù)庫已經(jīng)隨處可見，幾乎所有的服務(wù)都需要依賴數(shù)據(jù)庫管理系統(tǒng)存儲(chǔ)數(shù)據(jù)。

圖 1 - 數(shù)據(jù)庫

數(shù)據(jù)庫不會(huì)丟失數(shù)據(jù)聽起來像是理所當(dāng)然的事情，持久化能力也應(yīng)該是數(shù)據(jù)庫的最基本保障，但是在這個(gè)復(fù)雜的世界上想要保證數(shù)據(jù)不丟失是很困難的。在今天，我們能找到很多數(shù)據(jù)庫出現(xiàn)問題導(dǎo)致數(shù)據(jù)丟失的例子：

•  MongoDB 在過去很長(zhǎng)的一段時(shí)間都不能保證持久性，很容易就會(huì)丟失數(shù)據(jù)[^1]；

•  RocksDB DeleteRange 功能導(dǎo)致的數(shù)據(jù)丟失問題[^2]；

•  騰訊云硬盤故障，導(dǎo)致創(chuàng)業(yè)公司線上生產(chǎn)數(shù)據(jù)完全丟失[^3]；

無論是開源數(shù)據(jù)庫還是云服務(wù)商提供的服務(wù)，都有可能發(fā)生數(shù)據(jù)丟失的。本文將數(shù)據(jù)庫丟失數(shù)據(jù)的原因歸結(jié)到以下的幾個(gè)方面，我們將詳細(xì)展開介紹這些原因：

•  人為因素導(dǎo)致的運(yùn)維和配置錯(cuò)誤是數(shù)據(jù)庫丟失數(shù)據(jù)的首要原因；

•  數(shù)據(jù)庫存儲(chǔ)數(shù)據(jù)使用的磁盤損壞導(dǎo)致數(shù)據(jù)丟失；

•  數(shù)據(jù)庫的功能和實(shí)現(xiàn)復(fù)雜，數(shù)據(jù)沒有及時(shí)刷入磁盤就有丟失的風(fēng)險(xiǎn)；

人為錯(cuò)誤

人為錯(cuò)誤是造成數(shù)據(jù)丟失的首要原因。在騰訊云數(shù)據(jù)丟失事故中，我們會(huì)發(fā)現(xiàn)，雖然事故的起因是硬件故障，但是最終導(dǎo)致數(shù)據(jù)完整性受損的還是運(yùn)維人員的不當(dāng)操作：

第一是正常數(shù)據(jù)搬遷流程默認(rèn)開啟數(shù)據(jù)校驗(yàn)，開啟之后可以有效發(fā)現(xiàn)并規(guī)避源端數(shù)據(jù)異常，保障搬遷數(shù)據(jù)正確性，但是運(yùn)維人員為了加速完成搬遷任務(wù)，違規(guī)關(guān)閉了數(shù)據(jù)校驗(yàn)；

第二是正常數(shù)據(jù)搬遷完成之后，源倉庫數(shù)據(jù)應(yīng)保留24小時(shí)，用于搬遷異常情況下的數(shù)據(jù)恢復(fù)，但是運(yùn)維人員為了盡快降低倉庫使用率，違規(guī)對(duì)源倉庫進(jìn)行了數(shù)據(jù)回收。

減少人為錯(cuò)誤的最好方式是將數(shù)據(jù)的備份和運(yùn)維等操作標(biāo)準(zhǔn)化，使用自動(dòng)化的流程處理涉及數(shù)據(jù)安全的操作，這樣才能降低人為干預(yù)帶來的風(fēng)險(xiǎn)。

對(duì)于軟件工程師來說，我們應(yīng)該敬畏生產(chǎn)環(huán)境，謹(jǐn)慎地在生產(chǎn)環(huán)境執(zhí)行一切操作，認(rèn)識(shí)到所有的操作都可能對(duì)線上正在運(yùn)行的服務(wù)產(chǎn)生影響，這樣才能降低類似問題發(fā)生的概率。

硬件錯(cuò)誤

我們?cè)?為什么基礎(chǔ)服務(wù)不應(yīng)該高可用 一文中曾經(jīng)介紹過任何一個(gè)線上的服務(wù)能夠正常運(yùn)行都是極其偶然的，只要時(shí)間拉的足夠長(zhǎng)，我們就沒有辦法保證服務(wù) 100% 的可用性[^4]。磁盤等硬件如果使用的時(shí)間足夠長(zhǎng)，很有可能會(huì)發(fā)生損壞，根據(jù) Google 論文中的數(shù)據(jù)，5 年內(nèi)硬盤的年平均故障率（Annualized Failure Rates，AFR）為 8.6%[^5]。

2018 年，騰訊云數(shù)據(jù)損壞事故的起因就是磁盤靜默錯(cuò)誤（Silent data corruption）[^6]導(dǎo)致的單副本數(shù)據(jù)錯(cuò)誤。磁盤靜默錯(cuò)誤是沒有被磁盤固件或者宿主操作系統(tǒng)發(fā)現(xiàn)的錯(cuò)誤，包括以下情況：電纜松了、電源供給不可靠、外部震動(dòng)、網(wǎng)絡(luò)引起的數(shù)據(jù)丟失等問題。

正是因?yàn)榇疟P的數(shù)據(jù)損壞非常常見，所以我們需要數(shù)據(jù)冗余的方式保證磁盤在發(fā)生不可修復(fù)讀錯(cuò)誤（Unrecoverable Read Error）時(shí)能夠恢復(fù)磁盤數(shù)據(jù)。獨(dú)立冗余磁盤陣列（Redundant Array of Independent Disks，RAID）是一種能夠?qū)⒍鄠€(gè)物理磁盤組合成一個(gè)邏輯磁盤的數(shù)據(jù)存儲(chǔ)虛擬化技術(shù)，它能夠增加數(shù)據(jù)冗余并提高性能[^7]。

raid-strategy

圖 2 - RAID 三大策略

RAID 主要使用分割（Striping）、鏡像（Mirroring）和奇偶校驗(yàn)（Parity）三大策略管理磁盤中的數(shù)據(jù)，我們這里舉幾個(gè)簡(jiǎn)單的例子：

•  RAID 0 使用了數(shù)據(jù)分割技術(shù)，但是沒有鏡像和奇偶校驗(yàn)。它對(duì)磁盤上的數(shù)據(jù)幾乎不進(jìn)行任何的保護(hù)，任意一塊磁盤磁盤損壞都意味著其中的數(shù)據(jù)無法恢復(fù)，但是因?yàn)椴淮嬖谌哂啵运矔?huì)提供較好的性能；

•  RAID 1 使用了數(shù)據(jù)鏡像的功能，但是沒有奇偶校驗(yàn)和數(shù)據(jù)分割。所有的數(shù)據(jù)都會(huì)寫入兩個(gè)相同的磁盤，兩個(gè)磁盤都能對(duì)外提供數(shù)據(jù)讀取的服務(wù)。這種方式降低了磁盤的使用率，但是能夠提高讀取性能并提供備份；   

•  ...

RAID 使用的分割和鏡像策略與分布式數(shù)據(jù)庫中的分片（Partition）和副本（Replication）比較相似，分割和分片將數(shù)據(jù)切分后分配到不同的磁盤或者機(jī)器，而鏡像和副本的作用都是復(fù)制數(shù)據(jù)。

很多現(xiàn)代的操作系統(tǒng)都會(huì)提供基于軟件的 RAID 實(shí)現(xiàn)，一些云服務(wù)廠商也會(huì)使用自研的文件系統(tǒng)或者冗余備份機(jī)制：

•  Google 使用 Google 文件系統(tǒng)管理文件，它以塊的方式存儲(chǔ)文件并且通過主服務(wù)管理所有的文件塊[^8]；

•  Microsoft 在 Azure 中使用擦除編碼的方式計(jì)算冗余數(shù)據(jù)[^9]；

硬件錯(cuò)誤在生產(chǎn)環(huán)境中很常見，我們只有通過數(shù)據(jù)冗余和校驗(yàn)才能降低數(shù)據(jù)丟失的可能性，但是增加冗余的方式也只能不斷降低數(shù)據(jù)丟失的概率，不能 100% 的避免。

實(shí)現(xiàn)復(fù)雜

數(shù)據(jù)庫管理系統(tǒng)最終會(huì)將數(shù)據(jù)存儲(chǔ)在磁盤上，對(duì)于很多數(shù)據(jù)庫來說，數(shù)據(jù)落到磁盤上就意味著持久化完成了。磁盤作為數(shù)據(jù)庫系統(tǒng)的下層，磁盤能夠穩(wěn)定存儲(chǔ)數(shù)據(jù)是數(shù)據(jù)庫能夠持久化數(shù)據(jù)的基礎(chǔ)。

database-and-disk

圖 3 - 數(shù)據(jù)庫依賴磁盤

很多人都誤認(rèn)為使用 write 就能將數(shù)據(jù)寫入到磁盤上，然而這是錯(cuò)誤的。函數(shù) write 不僅不能保證數(shù)據(jù)寫入磁盤，有的實(shí)現(xiàn)甚至都不能保證目標(biāo)空間保留給了寫入的數(shù)據(jù)[^10]。一般情況下，對(duì)文件的 write 只會(huì)更新內(nèi)存中的頁緩存，這些頁緩存不會(huì)立刻刷入磁盤，操作系統(tǒng)的 flusher 內(nèi)核線程會(huì)在滿足以下條件時(shí)將數(shù)據(jù)落盤[^11]：

•  空閑內(nèi)存下降到了特定的閾值，需要釋放臟頁占用的內(nèi)存空間；

•  臟數(shù)據(jù)持續(xù)了一定時(shí)間，最老的數(shù)據(jù)就會(huì)被寫入磁盤；

•  用戶進(jìn)程執(zhí)行 sync 或者 fsync 系統(tǒng)調(diào)用；

如果我們想要將數(shù)據(jù)立刻刷入磁盤，就需要在執(zhí)行 write 后立刻調(diào)用 fsync 等函數(shù)[^12]，當(dāng) fsync 等函數(shù)返回后，數(shù)據(jù)庫才會(huì)通知調(diào)用方數(shù)據(jù)已經(jīng)成功寫入。

write-and-fsyn

圖 4 - 寫入和落盤

write 和 fsync 在數(shù)據(jù)庫管理系統(tǒng)中非常重要，它們是提供持久性保證的核心方法，一些開發(fā)者對(duì) write 的理解錯(cuò)誤寫出錯(cuò)誤的代碼就會(huì)導(dǎo)致數(shù)據(jù)丟失。

除了持久化的特性之外，數(shù)據(jù)庫可能還需要提供 ACID（Atomicity, Consistency, Isolation, Durability）或者 BASE（Basically Available, Soft state, Eventual consistency）的保證，有些數(shù)據(jù)庫還會(huì)提供分片、副本以及分布式事務(wù)等復(fù)雜功能，這些功能的引入也增加了數(shù)據(jù)庫系統(tǒng)的復(fù)雜性，而隨著程序復(fù)雜性的增加，出現(xiàn)問題的可能性也隨之增長(zhǎng)。

數(shù)據(jù)庫管理系統(tǒng)是軟件工程中最復(fù)雜、最重要的系統(tǒng)之一，幾乎所有服務(wù)的正常運(yùn)行都建立在數(shù)據(jù)庫不會(huì)丟失數(shù)據(jù)的假設(shè)上。然而因?yàn)槿缦滤镜脑?，?shù)據(jù)庫不能完全保證數(shù)據(jù)的安全：

•  運(yùn)維人員在配置和運(yùn)維時(shí)極有可能因?yàn)椴僮魇д`導(dǎo)致數(shù)據(jù)丟失；

•  數(shù)據(jù)庫依賴的底層磁盤發(fā)生硬件錯(cuò)誤，導(dǎo)致數(shù)據(jù)無法恢復(fù)；

•  數(shù)據(jù)庫系統(tǒng)支持的功能非常多而且復(fù)雜，數(shù)據(jù)沒有及時(shí)落盤就可能造成數(shù)據(jù)丟失；

一旦發(fā)生數(shù)據(jù)丟失的事故，造成的影響就會(huì)非常大，我們?cè)谑褂脭?shù)據(jù)庫存儲(chǔ)核心業(yè)務(wù)數(shù)據(jù)時(shí)也不能完全信任數(shù)據(jù)庫的穩(wěn)定性，可以考慮使用熱備以及快照等方式容災(zāi)。

看完上述內(nèi)容，你們對(duì)為什么數(shù)據(jù)庫會(huì)丟失數(shù)據(jù)有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。