英国《卫报》是如何不停机从MongoDB迁移到Postgres？

这篇文章介绍了英国《卫报Guardian》为什么和如何从Mongo迁移到Postgres，英国卫报大部分内容 - 包括文章，实时博客，画廊和视频内容 - 都是内部CMS工具Composer中制作的。直到最近一直得到了在AWS上运行的Mongo DB数据库的支持。这个Mongo DB数据库是Guardian所有在线发布内容的“真实来源” - 大约230万内容项。

当初为了迁移到AWS，决定购买OpsManager- Mongo的数据库管理软件，使用OpsManager来管理备份，处理编排并为我们的数据库集群提供监控。

因为Mongo没有提供任何工具来轻松在AWS上进行设置 - 我们需要手工编写cloudformation来定义所有基础架构，最重要的是我们编写了数百行ruby脚本来处理安装监视/自动化代理和新数据库实例的编排。

自从迁移到AWS 以来，由于Mongo DB数据库问题，我们发生了两次严重的中断，每次在theguardian.com上被阻止发布内容至少一个小时。在这两种情况下，OpsManager和Mongo的支持服务人员都没有能够帮助我们，我们最终解决了这个问题 ：

• 时钟非常重要 - 不要将VPC锁定到NTP停止工作的程度。
• 在应用程序启动时自动生成数据库索引可能是一个坏主意。
• 数据库管理很重要而且很难 - 我们宁愿不自己做。

OpsManager并没有真正兑现其无障碍数据库管理的承诺。例如，实际管理OpsManager本身 - 特别是从OpsManager 1升级到2 - 非常耗时，并且需要有关我们的OpsManager设置的专业知识。

由于不同版本的Mongo DB之间的身份验证架构发生了变化，它也没有实现其“一键升级”承诺。我们每年至少花费两个月的工程时间来完成这项数据库管理工作。

所有这些问题，加上我们为支持合同和OpsManager支付的高额年费，让我们寻找替代数据库选项，具有以下要求：

• 需要最少的数据库管理。
• 支持静态加密。
• Mongo的可行迁移路径。

由于我们所有其他服务都在AWS中运行，因此显而易见的选择是DynamoDB - 亚马逊的NoSQL数据库产品。不幸的是，当时Dynamo不支持静态加密。在等待大约9个月后才添加此功能，我们最终放弃并寻找其他东西，最终选择在AWS RDS上使用Postgres。

“但是postgres不是文件存储!”我听到你哭了。嗯，不，它不是，但它确实有一个JSONB列类型，支持JSON blob中字段的索引。

我们希望通过使用JSONB类型，我们可以将Mongo迁移到Postgres，只需对我们的数据模型进行最小的更改。此外，如果我们希望将来转向更多的关系模型，我们就有了这个选择。关于Postgres的另一个好处是它有多成熟：在大多数情况下，我们想要提出的每个问题都已经在Stack Overflow上得到了解答。

从性能的角度来看，我们有信心Postgres可以应对 - 而Composer是一个写作繁重的工具(每次记者停止打字时都会写入数据库) - 通常只有几百个并发用户 - 而不是高性能计算!

第二部分 - 二十年的内容迁移，没有停机时间

以下是我们迁移数据库的步骤：

• 创建新数据库。
• 创建一种写入新数据库的方法(新API)。
• 创建一个代理，使用旧的数据库作为主数据库，将流量发送到旧数据库和新数据库。
• 将记录从旧数据库迁移到新数据库。
• 使新数据库成为主数据库。
• 删除旧数据库。

鉴于我们正在迁移的数据库为我们的CMS提供支持，因此迁移对我们的记者造成的影响很小。毕竟，新闻永远不会停止。

新API：

2017年7月底，新的Postgres驱动的API开始工作。所以我们的旅程开始了。

我们简化的CMS架构是这样的：数据库，API和与之交互的几个应用程序(例如Web前端)。堆栈是，现在仍然是使用Scala，Scalatra Framework和Angular.js构建的，它大约有四年的历史。

经过一些调查，我们得出结论，在我们可以迁移现有内容之前，我们需要一种方法来与新的PostgreSQL数据库进行对话，并且仍然像往常一样运行旧的API。毕竟，Mongo数据库是我们的真相来源。它在试验新API时为我们提供了安全毯。

这是为什么在旧API之上构建不是一个选项的原因之一。在原始API中几乎没有关注点分离，甚至在控制器级别也可以找到MongoDB细节。因此，在现有API中添加另一个数据库类型的任务风险太大。

我们采用了不同的路线，并复制了旧的API。这就是APIV2诞生的方式。它或多或少是Mongo的复制品，包含相同的端点和功能。我们使用doobie，一个用于Scala的纯功能JDBC层，添加了Docker以便在本地运行和测试，并改进了日志记录和关注点分离。APIV2将成为一个快速而现代的API。

到2017年8月底，我们部署了一个使用PostgreSQL作为其数据库的新API。但这只是一个开始。Mongo数据库中的文章最初是在二十年前创建的，所有这些文章都需要移到Postgres数据库中。

迁移

我们需要能够编辑网站上的任何文章，无论它们何时发布，因此所有文章都作为单一的“事实来源”存在于我们的数据库中。

虽然所有文章都存在于Guardian的内容API(CAPI)中，它为应用程序和网站提供支持，但正确的迁移是关键，因为我们的数据库是“真相的来源”。如果CAPI的Elasticsearch集群发生任何事情，那么我们将从Composer的数据库中重新索引它。

因此，在关闭Mongo之前，我们必须确信在Postgres驱动的API和Mongo驱动的API上的相同请求将返回相同的响应。

为此，我们需要将所有内容复制到新的Postgres数据库。这是使用直接与新旧API对话的脚本完成的。这样做的好处是，API已经提供了一个经过良好测试的界面，用于从数据库读取和写入文章，而不是直接编写访问相关数据库的内容。

迁移的基本流程是：

• 从Mongo获取内容。
• 将内容发布到Postgres。
• 从Postgres获取内容。
• 检查一个和三个的响应是否相同

如果您的最终用户完全没有意识到它已经发生并且一个好的迁移脚本始终是这个的重要组成部分，那么数据库迁移真的很顺利。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!