數據庫管理系統在今天已經是軟件的重要組成部分，開源的 MySQL、PostgreSQL 以及商業化的 Oracle 等數據庫已經隨處可見，幾乎所有的服務都需要依賴數據庫管理系統存儲數據。
數據庫不會丟失數據聽起來像是理所當然的事情，持久化能力也應該是數據庫的最基本保障，但是在這個複雜的世界上想要保證數據不丟失是很困難的。在今天，我們能找到很多數據庫出現問題導致數據丟失的例子：
- MongoDB 在過去很長的一段時間都不能保證持久性，很容易就會丟失數據[^1]；
- RocksDB DeleteRange 功能導致的數據丟失問題[^2]；
- 騰訊雲硬盤故障，導致創業公司線上生產數據完全丟失[^3]；
無論是開源數據庫還是雲服務商提供的服務，都有可能發生數據丟失的。本文將數據庫丟失數據的原因歸結到以下的幾個方面，我們將詳細展開介紹這些原因：
- 人為因素導致的運維和配置錯誤是數據庫丟失數據的首要原因；
- 數據庫存儲數據使用的磁盤損壞導致數據丟失；
- 數據庫的功能和實現複雜，數據沒有及時刷入磁盤就有丟失的風險；
人為錯誤
人為錯誤是造成數據丟失的首要原因。在騰訊雲數據丟失事故中，我們會發現，雖然事故的起因是硬件故障，但是最終導致數據完整性受損的還是運維人員的不當操作：
第一是正常數據搬遷流程默認開啟數據校驗，開啟之後可以有效發現並規避源端數據異常，保障搬遷數據正確性，但是運維人員為了加速完成搬遷任務，違規關閉了數據校驗；
第二是正常數據搬遷完成之後，源倉庫數據應保留24小時，用於搬遷異常情況下的數據恢復，但是運維人員為了儘快降低倉庫使用率，違規對源倉庫進行了數據回收。
減少人為錯誤的最好方式是將數據的備份和運維等操作標準化，使用自動化的流程處理涉及數據安全的操作，這樣才能降低人為干預帶來的風險。
對於軟件工程師來說，我們應該敬畏生產環境，謹慎地在生產環境執行一切操作，認識到所有的操作都可能對線上正在運行的服務產生影響，這樣才能降低類似問題發生的概率。
硬件錯誤
任何一個線上的服務能夠正常運行都是極其偶然的，只要時間拉的足夠長，我們就沒有辦法保證服務 100% 的可用性[^4]。
磁盤等硬件如果使用的時間足夠長，很有可能會發生損壞，根據 Google 論文中的數據，5 年內硬盤的年平均故障率（Annualized Failure Rates，AFR）為 8.6%[^5]。
2018 年，騰訊雲數據損壞事故的起因就是磁盤靜默錯誤（Silent data corruption）[^6]導致的單副本數據錯誤。磁盤靜默錯誤是沒有被磁盤固件或者宿主操作系統發現的錯誤，包括以下情況：電纜鬆了、電源供給不可靠、外部震動、網絡引起的數據丟失等問題。
正是因為磁盤的數據損壞非常常見，所以我們需要數據冗餘的方式保證磁盤在發生不可修復讀錯誤（Unrecoverable Read Error）時能夠恢復磁盤數據。
獨立冗餘磁盤陣列（Redundant Array of Independent Disks，RAID）是一種能夠將多個物理磁盤組合成一個邏輯磁盤的數據存儲虛擬化技術，它能夠增加數據冗餘並提高性能[^7]。
raid-strategy
RAID 主要使用分割（Striping）、鏡像（Mirroring）和奇偶校驗（Parity）三大策略管理磁盤中的數據，我們這裡舉幾個簡單的例子：
- RAID 0 使用了數據分割技術，但是沒有鏡像和奇偶校驗。它對磁盤上的數據幾乎不進行任何的保護，任意一塊磁盤磁盤損壞都意味著其中的數據無法恢復，但是因為不存在冗餘，所以它也會提供較好的性能；
- RAID 1 使用了數據鏡像的功能，但是沒有奇偶校驗和數據分割。所有的數據都會寫入兩個相同的磁盤，兩個磁盤都能對外提供數據讀取的服務。這種方式降低了磁盤的使用率，但是能夠提高讀取性能並提供備份；
- ...
RAID 使用的分割和鏡像策略與分佈式數據庫中的分片（Partition）和副本（Replication）比較相似，分割和分片將數據切分後分配到不同的磁盤或者機器，而鏡像和副本的作用都是複製數據。
很多現代的操作系統都會提供基於軟件的 RAID 實現，一些雲服務廠商也會使用自研的文件系統或者冗餘備份機制：
- Google 使用 Google 文件系統管理文件，它以塊的方式存儲文件並且通過主服務管理所有的文件塊[^8]；
- Microsoft 在 Azure 中使用擦除編碼的方式計算冗餘數據[^9]；
硬件錯誤在生產環境中很常見，我們只有通過數據冗餘和校驗才能降低數據丟失的可能性，但是增加冗餘的方式也只能不斷降低數據丟失的概率，不能 100% 的避免。
實現複雜
數據庫管理系統最終會將數據存儲在磁盤上，對於很多數據庫來說，數據落到磁盤上就意味著持久化完成了。磁盤作為數據庫系統的下層，磁盤能夠穩定存儲數據是數據庫能夠持久化數據的基礎。
database-and-disk
很多人都誤認為使用 write 就能將數據寫入到磁盤上，然而這是錯誤的。函數 write 不僅不能保證數據寫入磁盤，有的實現甚至都不能保證目標空間保留給了寫入的數據[^10]。
一般情況下，對文件的 write 只會更新內存中的頁緩存，這些頁緩存不會立刻刷入磁盤，操作系統的 flusher 內核線程會在滿足以下條件時將數據落盤[^11]：
- 空閒內存下降到了特定的閾值，需要釋放髒頁佔用的內存空間；
- 髒數據持續了一定時間，最老的數據就會被寫入磁盤；
- 用戶進程執行 sync 或者 fsync 系統調用；
如果我們想要將數據立刻刷入磁盤，就需要在執行 write 後立刻調用 fsync 等函數[^12]，當 fsync 等函數返回後，數據庫才會通知調用方數據已經成功寫入。
write-and-fsyn
write 和 fsync 在數據庫管理系統中非常重要，它們是提供持久性保證的核心方法，一些開發者對 write 的理解錯誤寫出錯誤的代碼就會導致數據丟失。
除了持久化的特性之外，數據庫可能還需要提供 ACID（Atomicity, Consistency, Isolation, Durability）或者 BASE（Basically Available, Soft state, Eventual consistency）的保證，有些數據庫還會提供分片、副本以及分佈式事務等複雜功能，這些功能的引入也增加了數據庫系統的複雜性，而隨著程序複雜性的增加，出現問題的可能性也隨之增長。
總結
數據庫管理系統是軟件工程中最複雜、最重要的系統之一，幾乎所有服務的正常運行都建立在數據庫不會丟失數據的假設上。
然而因為如下所示的原因，數據庫不能完全保證數據的安全：
- 運維人員在配置和運維時極有可能因為操作失誤導致數據丟失；
- 數據庫依賴的底層磁盤發生硬件錯誤，導致數據無法恢復；
- 數據庫系統支持的功能非常多而且複雜，數據沒有及時落盤就可能造成數據丟失；
一旦發生數據丟失的事故，造成的影響就會非常大，我們在使用數據庫存儲核心業務數據時也不能完全信任數據庫的穩定性，可以考慮使用熱備以及快照等方式容災。
到最後，我們還是來看一些比較開放的相關問題，有興趣的讀者可以仔細思考一下下面的問題：
- 除了文中列出的數據丟失事故，還有哪些數據庫或者雲服務商丟失過數據？
- Redis 的 RDB 和 AOF 機制什麼時候會將數據落盤？
- 數據成功寫入數據庫究竟應該如何定義？
來源：https://mp.weixin.qq.com/s/Wo5GkfE8VtXTiyL9Kn4LlQ
閱讀更多 老男孩的成長之路 的文章
