英国《卫报》是如何不停机从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获取内容。
• 搜查一个和三个的相应是否沟通

假如您的最终用户完全没故意识到它已经产生而且一个好的迁徙剧本始终是这个的重要构成部门，那么数据库迁徙真的很顺遂。

（编辑：湖南网）

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