在实时数据库上运行迁移是否安全？

Question

我有一个简单的支持rails的应用程序，每天从Heroku Ronin数据库运行2-3百万次综合浏览量。但是，数据库上的负载非常轻，而且它可以处理的比我们投入的要多得多。

在不进入维护模式的情况下运行迁移以将表添加到此数据库是否安全？另外，运行迁移是否可以安全地将几列添加到核心表中，几乎所有的读写操作都可以？

即使几分钟也不接受停机时间。

如果不建议实时运行迁移，我可能会做的是设置一个新数据库，在其上运行迁移，编写脚本以同步两个数据库，然后将应用指向新数据库。

但如果可能，我宁愿避免这样做。 ：）

Answer 1

听起来您的迁移包括：

• 添加新表（可能是索引？如果是这样，可能需要比预期更长的时间）
• 添加新列（默认值和/或可空？）
• 将更改包装在事务中（？）

建议您通过以下方式衡量您的更改对Prod环境的影响：

• 备份Prod（包含所有Prod数据）
• 针对该目标运行更改脚本。每次操作的时间

平衡上面2点与典型读数和在你期望运行它时写入负载（02:00，对吧？）。

通过禁用（以某种方式）对正在执行的表的写操作来考虑“软”停机时间。

总体而言（或者一般而言），在没有任何停机时间或性能影响的情况下，可能/可能会将n个表和新的可空列添加到现有表中。

始终衡量您的更改对Prod副本的影响。在对此副本应用更改时测量“响应性”。当然，这也意味着要部署Prod应用程序的另一个副本，但这样做是值得的。

Answer 2

假设它是一个pg数据库（它应该是Heroku）。

http://www.postgresql.org/docs/current/static/explicit-locking.html

alter table将获得访问独占锁。因此，该表将被锁定。

除此之外，您还需要重新启动Rails应用程序，以便了解任何新模型。如果您要将表添加到应用程序或以任何方式修改模型代码。

至于指向具有新修改数据库的新应用程序，您将如何进行数据同步，并在同步所需的时间内同步两个数据库之间的数据更改？

Answer 3

添加表不应该是一个问题，因为在完成适当的升级之前，您的应用程序将不会意识到它们。至于将列添加到核心表，我不太确定。如果你真的需要防止停机，也许最好添加一个辅助表（通过ID与核心表链接）添加你的额外列。

只是我的两分钱。