一次几乎不可能的数据库运维迁移

最初，咱们把一个文件当作数据库，将数据转化为 JSON 大目标写入进去，后来，它的速度越来越慢，咱们决议进行数据库的搬迁，这个过程中咱们遇到了一些问题和妨碍，但终究咱们成功完成了这一次不太或许的数据库运维搬迁。

Brad 参加一家草创公司

大约一年前，当我刚参加 Tailscale时，我问 Crawshaw的榜首件事是：“嗯……你们运用的是什么数据库呢？MySQL、PostgreSQL、SQLite？“我知道他喜欢 SQLite。

“一个文本文件，”他回答道。

“嗯?”

“是的，咱们将一个大型 JSON 目标写入一个文本文件。”

“怎样写？什么时候写？写什么？”

“嗯，无论什么时候，只需有什么东西一变，咱们都会在咱们的单进程中获取一个锁，然后重写这个文件！”他快乐地笑着说。

听起来很疯狂。其实便是很疯狂。的确，它很简略测验，可是，不能扩展。这些，咱们都知道。可是，其时它还行得通。

后来，它不行了。

即便运用高速 NVMe 驱动器，而且将数据库分红两部分 (重要数据和 tmpfs 上的或许丢失的临时数据)，有些工作也会变得越来越慢。咱们知道这一天终将到来。文件达到了 150MB 的峰值，咱们正在以磁盘 I/O 允许的最快速度写入它。这已经到了极限。

那么，搬迁到 MySQL 或 PostgreSQL，怎么？或者是 SQLite？

不，Crawshaw 另有主见。

聊聊大卫的布景故事

Tailscale 的协调服务器（咱们的“控制面板”）以控制 CONTROL闻名遐迩。它目前是单个 VM 上的单个 Go 进程。它最早的原型运用的是 SQLite。咱们最初的规划与终究的规划有十分大的差异，包含同步到客户端机器上的装备数据库，以及一切咱们终究不再需求的其他概念。在这个过程中，咱们每周都要对 SQL 数据模型进行十分大规模的重组，这需求很多的键盘输入工作。SQL 已经得到了广泛运用，它耐久、有效，但将其引入到任何编程言语中简直都需求做很多的粘合。（一般咱们都试图用 ORM 来防止这种状况，用令人生厌的很多魔法字和功率损失来取代那些相同令人生厌的键盘输入工作。）

一天，我厌恶了重构，就把它彻底丢在一边，建了一个内存数据模型进行实验。这样，迭代速度更快了。几周后，一位客户想要试用一下。我还没有做好提交数据模型和用 SQL 来完成它的预备，所以我选择了一条捷径：将持有一切数据的目标包装在一个 sync.Mutex 中。一切访问都要经过它，在编辑时，将整个结构传递给 json.Marshal，然后写入磁盘。这便是咱们用大约 20 行 Go 完成的数据模型耐久层。

咱们原本方案要搬迁为其他言语的，但忙着忙着就给忘记了。

当我在规划一个包时，我感触到了编写 Go 时它的类型体系的局限性，这样的感触并不多，它是其中之一。假如我运用的是一种具有各种花哨功能的言语，那么我能够在脱离缓存的目标上放置某种 const 限定符，然后防止对内存进行克隆。即便如此，在咱们的服务器上执行的功能分析却表明，仿制并不是一个功能问题，所以该例或许说明，我实际上并不需求那些心心念念的更复杂的类型体系。一般状况下，假定很或许并不正确，功能分析才更具启发含义。

一个妨碍：索引

选择最小可行的“nosql”的最大问题是缺少每个标准 SQL DBMS 所提供的超卓的索引体系。咱们要么在 etcd 中存储索引，要么在客户端的内存中办理索引。咱们运用 JSONMutexDB 在内存中生成它们，由于更改数据模型要简略得多。运用 etcd 的一个简略做法是将它们写入数据库，但这将发生十分复杂的数据模型。不幸的是，假如咱们想要一起运转多个控制进程以完成高可用性和更好的发布办理，就意味着咱们不再只要一个办理数据的进程，因此咱们的索引需求支撑业务 (以及回滚)。因此，咱们投入了大约两到三周的工程时刻来规划业务共同的内存索引。这一点描述起来有些复杂，所以笔者将在后续的博客文章中专题解说，敬请期待。

迁 移

而迁徙自身却没什么特别值得注意的，这其实件功德。咱们这两个体系并行运转了一段时刻，并在某个时刻点中止了旧体系的运用。最令人兴奋的是，当咱们关闭 JSON 写入时，提交推迟降低了很多。在办理面板中编辑网络时这一点尤为明显。咱们有美丽的 Grafana 图表，在切换之前咱们就调整了 Prometheus 装备以坚持更多的历史纪录。不管在哪种状况下，写操作都能从简直一秒 (有时更糟!) 的时刻缩短到毫秒级。刚开始的时候，写入并不是咱们的第二目标。永久不要轻视“临时”起意会发生多么长久的影响！

未 来

在这项工作中，除了确保 Tailscale 控制面板能够在可预见的未来扩展外，最令人兴奋的工作是咱们发布过程的改善。咱们能够轻松地将多个控制面板实例附加到一个共同的数据库中，这意味着咱们能够切换为蓝绿部署（https://en.wikipedia.org/wiki/Blue-green_deployment）。这将让 Tailscale 的工程师们有信心去尝试部署特性，由于变更所能造成的最差结果是有限的。咱们的目标是将开发速度坚持在挨近 JSONMutexDB 前期的水平，其时咱们能够在不到一秒的时刻内重新编译并在本地运转，每天部署上 10 几次。