混沌工程

第19章 数据库中的混沌工程 数据库中的混沌工程

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

刘唐、翁浩

我们为什么需要混沌工程？

自从 ，Netflix在2011年开源了 Chaos Monkey，这个程序就变得越来越受欢迎。如果你想构建一个分布式系统，让Chaos Monkey在你的集群上疯狂一下，可以帮助构建一个容错性更强、更健壮、更可靠的系统。¹

TiDB是 开放源代码、分布式、混合事务/分析处理（HTAP）数据库。²数据库，主要由 PingCAP 开发。它存储的是我们认为对任何数据库用户来说都是最重要的资产：数据本身。我们的系统最基本也是最重要的要求之一就是容错。传统上，我们通过运行单元测试和集成测试来确保系统为生产做好准备，但随着集群规模的扩大、复杂性的增加以及数据量以 PB 级的速度增长，这些测试只是冰山一角。混沌工程（Chaos Engineering）对我们来说是天作之合。 在本章中，我们将详细介绍我们的实践，以及像TiDB这样的分布式系统需要混沌工程的具体原因。

鲁棒性和稳定性

要在 上建立用户对新发布的分布式数据库（如 TiDB，数据保存在相互通信的多个节点中）的信任，就必须随时防止数据丢失或损坏。但在现实世界中，故障随时随地都可能发生，这是我们无法预料的。那么，我们该如何应对这些故障呢？一种常见的方法是使我们的系统具有容错性。如果一个服务崩溃，另一个备用服务可以立即接管，而不会影响在线服务。在实践中，我们需要警惕容错会增加分布式系统的复杂性。

我们如何 才能确保容错的稳健性？测试容错能力的典型方法包括编写单元测试和集成测试。在内部测试生成工具的帮助下，我们已经开发了 2000 多万个单元测试用例。我们还利用了大量开源测试用例，如 MySQL 测试用例和 ORM 框架测试用例。然而，即使是 100% 的单元覆盖率也不等于容错系统。同样，一个经过精心设计的集成测试的系统，也不能保证它在实际生产环境中能够很好地运行。在现实世界中，任何事情都有可能发生，比如磁盘故障或网络时间协议（NTP）不同步。为了使 TiDB 这样的分布式数据库系统更加健壮，我们需要一种方法来模拟不可预测的故障，并测试我们对这些故障的响应。

一个真实世界的例子

在 TiDB 中，我们使用 Raft 共识算法将数据从领导者复制到追随者，以保证各副本之间的数据一致性。当副本组中新加入一个跟随者时，它很有可能会比领导者落后多个版本。为了保持数据的一致性，领导者会发送快照文件供跟随者应用。这是一个可能出错的地方。图 19-1显示了我们在生产环境中遇到的一个典型案例。

图 19-1. 在 TiDB 快照中发现的一个实际错误。根据.meta文件中的信息，_write.sst和_lock.sst文件不应为 0 字节。

如图 19-1 所示，快照由四部分组成：一个元文件（后缀名为.meta）和三个数据文件（后缀名为.sst）。元文件包含所有数据文件的大小信息和相应的校验和，我们可以用它来检查接收到的数据文件是否有效。

对于新创建的副本，图 19-2显示了如何在 Raft Leader 和跟随者之间验证 快照的一致性。从日志中可以看到，有些大小为零，但实际上在元文件中并不为零。这意味着快照已损坏。