连接是只读的。不允许进行导致数据修改的查询_将数据库从Heroku迁移到AWS RDS...

1、准备迁移

我们使用的是PostgreSQL来存储数据，有几台数据库服务器，最大容量超过500 GB（在迁移当天）。从准备过程的一开始，我们预计在某些情况下停机是不可避免的，但这并没有阻止我们检查替代方案。

比较Heroku和RDS实例

比较Heroku PostgreSQL实例和AWS RDS实例是一项艰巨的任务，因为我们无法访问提供程序设置的所有参数。尽管如此，我们仍然必须找到不会导致网站性能明显下降的RDS参数和硬件配置。

通常，在资源方面，可以将Heroku的数据库一对一迁移到RDS中的数据库（请记住，Heroku也位于AWS上），因此性能差异可能是由于以下事实引起的：

• Heroku使用异步复制，而RDS使用同步，因此RDS上的写入时间可能会更长
• Heroku的基本参数与AWS上的默认参数不同（Heroku调整得更好，AWS更“安全默认”）

不幸的是，我们没有基础设施来测试带有生产流量（镜像/阴影）副本的新数据库设置，并且我们没有足够的时间来准备它。另外，由于我们无法准备生产数据库的忠实副本以进行测试而又不会造成停机，因此整个过程将极其复杂，因为Heroku不允许复制扩展到其基础架构之外。最终，我们决定使用来比较数据库性能和综合测试pgbench。此外，我们决定复制Heroku上的参数（仅限于我们可以复制的参数）。

我们进行了两轮基准测试–首先，我们使用了pgbench工具本身提供的方案。它显示Heroku和RDS之间没有明显的性能差异。不幸的是，这些测试并未确认RDS数据库在我们的生产工作负载下是否会执行相同的操作。

在下一次迭代中，我们准备了在生产数据库上运行最受欢迎查询的方案，并在具有类似Heroku的参数和默认参数的RDS实例上对其进行了测试。

测试结果表明，对于可比较的硬件配置，类似于Heroku的参数比类似生产的测试的RDS默认值提供55％的读取速度。对于所pg_bench提供的方案，基准测试显示类似Heroku的参数和默认参数之间没有差异。由此得出另一个结论- 始终根据生产工作负载而不是综合基准进行性能测试，否则您将陷入困境。

说到写入速度，所有测试均未显示参数更改有明显影响。主要变化因素是在RDS配置中启用了多可用区。这导致写入速度显着降低，但这是预期的变化，因为RDS使用同步复制，这可以大大减少当前主实例和故障转移实例之间的数据差异的机会。

最小化对客户的影响

• 选择合适的时间

大多数网页上的流量水平在一周中不是恒定的，因此很容易找到流量最低的时间段。此时迁移是减少对客户工作造成干扰的最简单方法。在我们的案例中，世界各地的客户都在不同的时区使用我们的系统。最安全的迁移时间是CET周日早上，但仍可能会影响我们常规流量的1/3。

• 应用程序只读模式

如果客户只能读取其数据，我们的某些服务仍可以为他们提供价值。对于这种情况，我们准备了只读模式。我们准备了只读数据库用户和交换服务，以便在迁移期间使用它。该应用程序代码已准备就绪，可以优雅地处理所有错误，因此用户仍然可以访问其数据。我们还确保在迁移期间不会对数据进行任何更改。这使我们能够转储并还原RDS实时系统上的数据。

• 维护方式与沟通

如果由于使用的特殊性而无法将数据库置于只读模式，则必须完全禁用我们的服务。这导致我们的客户无法使用关键功能。因此，非常重要的是提前通知他们将进行维护，并且他们将无法在停机期间访问系统。这为他们提供了为停机做好准备的机会。因为除了网站之外，我们还拥有移动应用程序，所以我们不得不为API的不可用做好准备。让客户端在迁移过程中看到连接错误是相当不合理的。他们应该看到一条消息，说明正在发生的事情。

• 争取减少停机时间！

由于某些数据库不可避免地会发生停机，因此我们正在寻找能够减少数据库迁移所需时间的解决方案。幸运的是，我们的服务处于脱机状态这一事实开辟了新的可能性-我们不必担心在进行转储时会加载多少数据库。对于实时只读数据库，我们使用了本地的Heroku备份工具，该工具非常慢，但不会给数据库带来太多负担。对于离线系统，我们可以根据需要pg_dump直接使用尽可能多的并行作业。如此小的更改使我们最大的数据库（500 GB）的迁移步骤从2小时缩短为20分钟。

迁移程序

迁移过程本身非常简单（并且由于事先准备而没有压力）。为了减少通信开销，整个过程由公司办公室的一个小型工作组在周日上午进行。我们还决定将迁移分为许多批次，分别在不同的周末进行。

对于切换为只读模式的数据库，我们将应用程序使用的凭据切换为权限受限的凭据。然后，我们使用Heroku工具备份数据库并将其上传到RDS。下一步是将应用程序切换到基于AWS的基础上。

需要停机的数据库要求我们在移动应用程序中启用维护模式（该应用程序定期查询API以进行配置更改），并开始在我们的网络域上显示信息板。之后，我们能够关闭Kubernetes集群上的所有服务，并启动数据库迁移过程，这与所有服务均处于活动状态（在Heroku上转储并在RDS上还原）非常相似。为了迁移最大的数据库，我们决定逐渐让客户回到我们的门户。根据之前的流量数据，我们准备了IP范围，并开始为这些范围允许流量进入群集。

摘要

完成此步骤后，我们的所有主要服务现在都托管在AWS上。Heroku上仍然有RabbitMQ和Redis，但是它们没有像数据库那样被广泛使用，移动它们只是时间问题。

一切顺利

由于我们花了很多时间在准备过程上，所以整个项目顺利进行，没有任何明显的延误。当然存在一些小问题，但是我们能够不断地减轻它们。将所有数据库迁移到较小的批次中，可以使我们从不太重要的数据库中学习，并改进流程以准备最重要的数据库。

有什么更好的？

迁移过程是半自动化的，并且手动配置中存在错误-例如，对于一个数据库，我们忘记了设置预配置的IOPS（幸运的是，由于我们向数据库实例添加了1 TB磁盘，因此EBS基准性能确实很高）。我们的第一次迁移以应用程序仍连接到旧数据库而告终，因为我们在PgBouncer容器中进行了配置更改和重新加载之间存在竞争状态（重新加载是在实际更改之前触发的）。我们在迁移过程中添加了一个清单，以确保下次可以快速检测到这种情况。