为什么数据库会丢失数据

今天，我将和你谈谈为什么数据库会丢失数据。可能很多人不太了解。为了让大家更好的了解，边肖为大家总结了以下内容。希望你能从这篇文章中有所收获。

数据库管理系统是当今软件的重要组成部分。开源的MySQL、PostgreSQL和商业化的Oracle数据库随处可见。几乎所有的服务都需要依靠数据库管理系统来存储数据。

图 1 - 数据库

听起来数据库不会丢失数据是理所当然的事情。持久化能力也应该是数据库最基本的保障，但是要保证数据在这个复杂的世界里不丢失是非常困难的。今天，我们可以找到许多由数据库问题导致的数据丢失的例子：

过去MongoDB不能保证长时间的持久性，容易丢失数据[1]；

RocksDB DeleteRange函数[2]导致数据丢失；

腾讯云硬盘故障导致创业公司上线生产数据完全丢失[3]；

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

人为因素导致的操作和配置错误是数据库数据丢失的主要原因。

数据丢失是由于数据库用来存储数据的磁盘损坏造成的；

数据库的功能和实现比较复杂，如果不及时刷入磁盘，数据会丢失。

人为错误

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

首先，正常的数据迁移过程默认开启数据验证，可以有效发现和避免源数据异常，保证迁移数据的正确性。但为了加快迁移任务，运维人员违规关闭数据验证；

其次，正常的数据迁移完成后，源仓库的数据要保存24小时，以备异常迁移时进行数据恢复。但是为了尽快降低仓库的利用率，运维人员非法回收了源仓库的数据。

减少人为错误的最好方法是规范数据备份、操作和维护，使用自动化流程处理涉及数据安全的操作，从而降低人为干预带来的风险。

对于软件工程师来说，要尊重生产环境，认真执行生产环境中的所有操作，认识到所有操作都可能对在线运行的服务产生影响，从而降低类似问题发生的概率。

硬件错误

在《为什么基本服务不应该高度可用》一文中，我们曾经介绍过，任何在线服务能够正常运行都是极其偶然的。只要时间足够长，我们就不能保证服务的100%可用性[4]。如果硬盘使用时间足够长，很可能会损坏。根据谷歌论文中的数据，硬盘五年的平均年化故障率(AFR)为8.6% [5]。

2018年，腾讯云的数据损坏事故是由静默数据损坏导致的单拷贝数据错误造成的[6]。磁盘静默错误是磁盘固件或主机操作系统没有发现的错误，包括以下几种情况：电缆松动、电源不可靠、外部震动、网络导致数据丢失等。

由于磁盘的数据损坏非常普遍，我们需要数据冗余，以确保磁盘在发生不可恢复的读取错误时能够恢复磁盘数据。独立磁盘冗余阵列(RAID)是一种数据存储虚拟化技术，可以将多个物理磁盘组合成一个逻辑磁盘，可以增加数据冗余，提高性能[7]。

突袭策略

图 2 - RAID 三大策略

RAID主要使用三种策略，即条带化、镜像和奇偶校验来管理磁盘中的数据。这里有几个简单的例子：

RAID 0使用数据分区技术，但没有镜像和奇偶校验。它几乎不保护磁盘上的数据，任何磁盘的损坏都意味着其中的数据无法恢复，但由于没有冗余，它也会提供更好的性能。

RAID 1使用数据镜像功能，但没有奇偶校验和数据分区。所有数据将被写入两个相同的磁盘，两个磁盘都可以向外界提供数据读取服务。这种方法降低了磁盘的利用率，但可以提高读取性能并提供备份。

.

i>

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

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

•  Google 使用 Google 文件系统管理文件，它以块的方式存储文件并且通过主服务管理所有的文件块[^8]；

•  Microsoft 在 Azure 中使用擦除编码的方式计算冗余数据[^9]；

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

实现复杂

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

database-and-disk

图 3 - 数据库依赖磁盘

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

•  空闲内存下降到了特定的阈值，需要释放脏页占用的内存空间；

•  脏数据持续了一定时间，最老的数据就会被写入磁盘；

•  用户进程执行 sync 或者 fsync 系统调用；

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

write-and-fsyn

图 4 - 写入和落盘

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

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

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

•  运维人员在配置和运维时极有可能因为操作失误导致数据丢失；

•  数据库依赖的底层磁盘发生硬件错误，导致数据无法恢复；

•  数据库系统支持的功能非常多而且复杂，数据没有及时落盘就可能造成数据丢失；

一旦发生数据丢失的事故，造成的影响就会非常大，我们在使用数据库存储核心业务数据时也不能完全信任数据库的稳定性，可以考虑使用热备以及快照等方式容灾。

看完上述内容，你们对为什么数据库会丢失数据有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注行业资讯频道，感谢大家的支持。