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

[[320176]]

database-banner

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

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

•  MongoDB 在過去很長的一段時間都不能保證持久性，很容易就會丟失數(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é)到以下的幾個方面，我們將詳細展開介紹這些原因：

•  人為因素導(dǎo)致的運維和配置錯誤是數(shù)據(jù)庫丟失數(shù)據(jù)的首要原因；
•  數(shù)據(jù)庫存儲數(shù)據(jù)使用的磁盤損壞導(dǎo)致數(shù)據(jù)丟失；
•  數(shù)據(jù)庫的功能和實現(xiàn)復(fù)雜，數(shù)據(jù)沒有及時刷入磁盤就有丟失的風(fēng)險；

人為錯誤

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

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

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

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

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

硬件錯誤

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

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

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

raid-strategy

圖 2 - RAID 三大策略

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

•  RAID 0 使用了數(shù)據(jù)分割技術(shù)，但是沒有鏡像和奇偶校驗。它對磁盤上的數(shù)據(jù)幾乎不進行任何的保護，任意一塊磁盤磁盤損壞都意味著其中的數(shù)據(jù)無法恢復(fù)，但是因為不存在冗余，所以它也會提供較好的性能；
•  RAID 1 使用了數(shù)據(jù)鏡像的功能，但是沒有奇偶校驗和數(shù)據(jù)分割。所有的數(shù)據(jù)都會寫入兩個相同的磁盤，兩個磁盤都能對外提供數(shù)據(jù)讀取的服務(wù)。這種方式降低了磁盤的使用率，但是能夠提高讀取性能并提供備份；   
•  ...

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

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

•  Google 使用 Google 文件系統(tǒng)管理文件，它以塊的方式存儲文件并且通過主服務(wù)管理所有的文件塊[^8]；
•  Microsoft 在 Azure 中使用擦除編碼的方式計算冗余數(shù)據(jù)[^9]；

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

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

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

database-and-disk

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

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

•  空閑內(nèi)存下降到了特定的閾值，需要釋放臟頁占用的內(nèi)存空間；
•  臟數(shù)據(jù)持續(xù)了一定時間，最老的數(shù)據(jù)就會被寫入磁盤；
•  用戶進程執(zhí)行 sync 或者 fsync 系統(tǒng)調(diào)用；

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

write-and-fsyn

圖 4 - 寫入和落盤

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

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

總結(jié)

數(shù)據(jù)庫管理系統(tǒng)是軟件工程中最復(fù)雜、最重要的系統(tǒng)之一，幾乎所有服務(wù)的正常運行都建立在數(shù)據(jù)庫不會丟失數(shù)據(jù)的假設(shè)上。然而因為如下所示的原因，數(shù)據(jù)庫不能完全保證數(shù)據(jù)的安全：

•  運維人員在配置和運維時極有可能因為操作失誤導(dǎo)致數(shù)據(jù)丟失；
•  數(shù)據(jù)庫依賴的底層磁盤發(fā)生硬件錯誤，導(dǎo)致數(shù)據(jù)無法恢復(fù)；
•  數(shù)據(jù)庫系統(tǒng)支持的功能非常多而且復(fù)雜，數(shù)據(jù)沒有及時落盤就可能造成數(shù)據(jù)丟失；

一旦發(fā)生數(shù)據(jù)丟失的事故，造成的影響就會非常大，我們在使用數(shù)據(jù)庫存儲核心業(yè)務(wù)數(shù)據(jù)時也不能完全信任數(shù)據(jù)庫的穩(wěn)定性，可以考慮使用熱備以及快照等方式容災(zāi)。到最后，我們還是來看一些比較開放的相關(guān)問題，有興趣的讀者可以仔細思考一下下面的問題：

•  除了文中列出的數(shù)據(jù)丟失事故，還有哪些數(shù)據(jù)庫或者云服務(wù)商丟失過數(shù)據(jù)？
•  Redis 的 RDB 和 AOF 機制什么時候會將數(shù)據(jù)落盤？
•  數(shù)據(jù)成功寫入數(shù)據(jù)庫究竟應(yīng)該如何定義？