Tailscale 追踪数据库损坏至 16y/o SQLite WAL 重置错误

去年年底，我们的正常运行时间相当不稳定。您可以在我们的状态页面上看到这种趋势，并且这种不稳定持续到新的一年。其中许多中断是由 SQLite 深处的一个错误引起的。经过数月的紧张取证才找到它。现在正值夏天，我们相信我们已经找到了这个错误，我们理解了它，更重要的是，我们已经修复了它。我们知道我们的客户希望 Tailscale 提供可靠的服务，但几个月来我们并没有兑现这一承诺。这具有破坏性，我们很抱歉。我们发布这篇博文是为了解释出了什么问题、我们如何应对，以及我们如何最终帮助发现 SQLite 数据库核心中长期存在的错误。虽然我们的客户作为单个公共端点（controlplane.tailscale.com）与我们的控制平面进行交互，但在内部，我们的控制平面被分成一系列协调服务器（或“分片”）。每个尾网一次驻留在一个内部分片上，但可以从一个分片无缝迁移到另一个分片。这些分片是内部实现细节：您不知道您的尾网位于哪个分片上，而且您永远不需要知道。每个分片都有一个 SQLite 数据库，其中保存有关该分片上的 tailnets 的所有信息。单个 Go 进程专门访问该数据库，并为这些尾网的控制平面提供服务。这种单写入器设计正是 SQLite 的用途。自 2022 年以来，我们一直使用 SQLite 作为我们的主要数据库，我们选择它是因为它众所周知、可靠且使用广泛。 SQLite 是一种“无聊的技术”——从好的方面来说。许多公司在更大规模的部署中使用 SQLite 不会出现任何问题，我们期望同样无压力的使用。在我们当前的备份管道中，我们每隔几分钟拍摄一次数据库的完整快照，然后将整个 SQLite 文件上传到 S3 存储桶。自 2023 年初以来，我们一直在运行此设置，没有发生任何事故。快进到去年 8 月，当时读取这些 S3 备份的数据管道报告我们的一个数据库出现错误。我们对备份运行 SQLite 的 PRAGMAintegrity_check 命令，发现它确实已损坏。 SQLite 损坏是可能的，但这种情况非常不寻常，不应该在正常操作中遇到。我们修复了受影响的数据库，并调查了原因，但没有结果。当大规模运营时，即使是罕见的事件也可能以一定的频率发生，所以当它再次发生时我们应该不会感到惊讶——一次又一次，一次又一次。在我们最终解决潜在错误之前的六个月内，我们总共遇到了 19 次不同的数据库损坏实例。当您听到“数据库损坏”这个词时，很自然地担心数据丢失。由于我们的控制平面仅处理配置数据，因此这些数据库包含有关您的尾网和设备的元数据，但绝不包含您的私有加密密钥或网络流量。在最早的事件中，恢复过程意味着少数新添加的设备或配置更改不会持续存在，并且必须重新输入少量元数据。每当发生损坏时，我们就必须在修复或恢复数据库时停止分片上的控制平面进程。这对于该分片上的尾网来说是痛苦的，因为它们的整个控制平面在恢复窗口期间消失了。在早期事件中，停机时间超过一个小时，但我们在后续事件中逐渐加快了恢复过程。每个尾网都是一个网状网络，设备在其中相互建立点对点 WireGuard® 连接。当设备加入尾网时，它必须从控制平面获取其他设备的列表，然后才能建立新连接 - 因此，如果设备在 SQLite 停机期间上线，它将无法连接。在数据库修复期间，已在线的设备仍保持相互连接，但它们无法了解网络的变化。这些 tailnet 还暂时失去了对基于 Web 的管理控制台和 Tailscale API 的访问权限。这对信任也有更广泛的影响。即使只有少数尾网受到影响，我们也会在状态页面上发布全球事件。许多人看到了对他们没有影响的事件的状态页面事件。事实上，大多数分片和尾网从未涉及数据库损坏事件！尽管如此，无论您是否受到直接影响，反复的停机都会削弱信任。从第一次腐败事件起，我们就知道这对我们的可靠性构成严重威胁，我们投入了大量的工程时间来解决这个问题，但解决起来并不容易。这个错误阻止了我们最初寻找它的所有尝试。我们查看了最近的变化，但没有任何看起来相关的变化。没有人参与我们与 SQLite 交互的低级代码，因为它都是几年前编写的，并且在那之前没有出现任何问题。我们仔细地重新审查了所有代码，以查找以前遗漏的错误，但我们没有