为了获得一个全托管的解决方案，英国卫报在 2018 年将 CMS 的数据存储从一个自托管的 MongoDB 集群迁移到了 Amazon RDS 上的 PostgreSQL。团队在没有停机的情况下进行了基于 API 的迁移。
英国卫报的内部 CMS（名为 Composer）存储着文章、博客内容、照片库和视频，它最初是以 MongoDB 为数据存储构建的。在此之前，用的是一个后台是 Oracle 数据库的供应商软件。在这种设置下，每当必须迁移模式时，都需要停机时间。作为替代方案，团队研究了各种 NoSQL 数据库，选择 MongoDB 的其中一个关键原因似乎是灵活性。MongoDB 最初托管在他们自己的数据中心里，在一次宕机后，他们将其转移到了 AWS 服务器上。安装和管理脚本必须由卫报的团队手写。他们选择了一项支持合同，并购买了 OpsManager 工具，这是一个管理 MongoDB 的前端应用程序。然而，不清楚因为什么原因，该团队没有选择 MongoDB Atlas 服务，这是一个“全托管的数据库”。OpsManager 不管理部署。
在迁移到 AWS 之后，团队遇到了两次 MongoDB 宕机。其中一些原因是基本的系统管理问题，比如不允许 NTP 访问时间服务器以保持时钟同步。根据这篇文章，还有一些和 OpsManager 本身管理困难以及很难从供应商那里获得及时的支持有关。其团队觉得，迁移到需要最少数据库管理工作的解决方案最适合他们。
该团队选择 PostgreSQL 的原因是，作为 Amazon RDS 上的托管数据库，它非常成熟，而且支持 jsonb 数据类型。Jsonb 类型允许对 JSON 对象中的字段进行索引。迁移计划是在 Postgres 上编写一个新的 API，并使用一个代理向这两个 API 发送流量，使它们对于新传入的数据保持同步。使用 API 迁移现有数据，然后将代理切换到新的 API。他们之前从 Oracle 迁移也是使用类似的方法完成的。为了跟踪迁移过程，迁移脚本日志被推送到 Elasticsearch。在此过程中，他们还改进了他们的结构化日志。
代理实时地将所有流量定向到 MongoDB API，并异步地定向到 Postgres API。响应中的任何差异都会被记录并分析。为了确保新的 API 和后端能够支撑生产流量，他们运行 GoReplay 进程来生成流量。GoReplay 可以捕获流量，并在不同的环境下进行回放——在本例中是预生产环境。他们在预生产环境上完成了完整的迁移过程。生产迁移的最后一步是将 DNS 名称从代理的端点（一个 Amazon ELB）切换到 Postgres API（另一个 ELB）。这使得它们的客户端可以在不做任何更改的情况下正常工作。迁移之后，他们的集成测试失败了，因为他们没有迁移到新的 API。
还有其他一些组织出于各种原因从 MongoDB 迁移到了 PostgreSQL。
查看英文原文：The Guardian’s Migration From MongoDB to PostgreSQL on Amazon RDS
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论