<返回更多

为什么数据库会丢失数据?

2020-03-26    
加入收藏

来源:真没什么逻辑

为什么这么设计(Why’s THE Design)是一系列关于计算机领域中程序设计决策的文章,我们在这个系列的每一篇文章中都会提出一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。如果你有想要了解的问题,可以在文章下面留言。

数据库管理系统在今天已经是软件的重要组成部分,开源的 MySQL、PostgreSQL 以及商业化的 Oracle 等数据库已经随处可见,几乎所有的服务都需要依赖数据库管理系统存储数据。

database-banner

图 1 - 数据库

数据库不会丢失数据听起来像是理所当然的事情,持久化能力也应该是数据库的最基本保障,但是在这个复杂的世界上想要保证数据不丢失是很困难的。在今天,我们能找到很多数据库出现问题导致数据丢失的例子:

无论是开源数据库还是云服务商提供的服务,都有可能发生数据丢失的。本文将数据库丢失数据的原因归结到以下的几个方面,我们将详细展开介绍这些原因:

人为错误

人为错误是造成数据丢失的首要原因。在腾讯云数据丢失事故中,我们会发现,虽然事故的起因是硬件故障,但是最终导致数据完整性受损的还是运维人员的不当操作:

第一是正常数据搬迁流程默认开启数据校验,开启之后可以有效发现并规避源端数据异常,保障搬迁数据正确性,但是运维人员为了加速完成搬迁任务,违规关闭了数据校验;

第二是正常数据搬迁完成之后,源仓库数据应保留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

图 2 - RAID 三大策略

RAID 主要使用分割(Striping)、镜像(Mirroring)和奇偶校验(Parity)三大策略管理磁盘中的数据,我们这里举几个简单的例子:

RAID 使用的分割和镜像策略与分布式数据库中的分片(Partition)和副本(Replication)比较相似,分割和分片将数据切分后分配到不同的磁盘或者机器,而镜像和副本的作用都是复制数据。

很多现代的操作系统都会提供基于软件的 RAID 实现,一些云服务厂商也会使用自研的文件系统或者冗余备份机制:

硬件错误在生产环境中很常见,我们只有通过数据冗余和校验才能降低数据丢失的可能性,但是增加冗余的方式也只能不断降低数据丢失的概率,不能 100% 的避免。

实现复杂

数据库管理系统最终会将数据存储在磁盘上,对于很多数据库来说,数据落到磁盘上就意味着持久化完成了。磁盘作为数据库系统的下层,磁盘能够稳定存储数据是数据库能够持久化数据的基础。

database-and-disk

图 3 - 数据库依赖磁盘

很多人都误认为使用 write就能将数据写入到磁盘上,然而这是错误的。函数 write不仅不能保证数据写入磁盘,有的实现甚至都不能保证目标空间保留给了写入的数据[^10]。一般情况下,对文件的 write只会更新内存中的页缓存,这些页缓存不会立刻刷入磁盘,操作系统的 flusher 内核线程会在满足以下条件时将数据落盘[^11]:

如果我们想要将数据立刻刷入磁盘,就需要在执行 write后立刻调用 fsync等函数[^12],当 fsync等函数返回后,数据库才会通知调用方数据已经成功写入。

write-and-fsyn

图 4 - 写入和落盘

write和 fsync在数据库管理系统中非常重要,它们是提供持久性保证的核心方法,一些开发者对 write的理解错误写出错误的代码就会导致数据丢失。

除了持久化的特性之外,数据库可能还需要提供 ACID(Atomicity, Consistency, Isolation, Durability)或者 BASE(Basically Available, Soft state, Eventual consistency)的保证,有些数据库还会提供分片、副本以及分布式事务等复杂功能,这些功能的引入也增加了数据库系统的复杂性,而随着程序复杂性的增加,出现问题的可能性也随之增长。

总结

数据库管理系统是软件工程中最复杂、最重要的系统之一,几乎所有服务的正常运行都建立在数据库不会丢失数据的假设上。然而因为如下所示的原因,数据库不能完全保证数据的安全:

一旦发生数据丢失的事故,造成的影响就会非常大,我们在使用数据库存储核心业务数据时也不能完全信任数据库的稳定性,可以考虑使用热备以及快照等方式容灾。到最后,我们还是来看一些比较开放的相关问题,有兴趣的读者可以仔细思考一下下面的问题:

如果对文章中的内容有疑问或者想要了解更多软件工程上一些设计决策背后的原因,可以在博客下面留言,作者会及时回复本文相关的疑问并选择其中合适的主题作为后续的内容。

[^1]: Brandur. May 7, 2017. "The long road to Mongo's durability" https://brandur.org/fragments/mongo-durability

[^2]: Huachao HUANG. Fri, Sep 8, 2017. "How We Found a Data Corruption Bug in RocksDB" https://pingcap.com/blog/2017-09-08-rocksdbbug/

[^3]: 腾讯云. Aug, 2018. 关于客户“前沿数控”数据完整性受损的技术复盘 https://mp.weixin.qq.com/s/8JSPY6vHPhg8pX0JwjqttQ

[^4]: Draven. Dec, 2019. "为什么基础服务不应该高可用 · Why's THE Design?" https://draveness.me/whys-the-design-unstable-infrastructure

[^5]: Eduardo Pinheiro, Wolf-Dietrich Weber and Luiz Andre Barroso. Feb, 2007. "Failure Trends in a Large Disk Drive Population" https://static.googleusercontent.com/media/research.google.com/en//archive/disk_failures.pdf

[^6]: Wikipedia: Silent Data corruption https://en.wikipedia.org/wiki/Data_corruption#Silent

[^7]: Wikipedia: RAID https://en.wikipedia.org/wiki/RAID

[^8]: Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. Oct, 2003. "The Google File System" https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf

[^9]: Cheng Huang. Jun, 2012. "Erasure Coding in windows Azure Storage" https://www.cs.princeton.edu/courses/archive/spring13/cos598C/atc12-final181.pdf

[^10]: write(2) - linux man page https://linux.die.net/man/2/write

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍最近更新
更多资讯 >>>