在 Rails 应用程序中，我有一个需要一段时间才能完成的迁移。首先它更新列的默认值，然后重新索引 Solr 索引。问题是，在迁移运行时，旧版本的应用程序使用部分新数据库和 solr 索引来处理请求。而且由于新的默认列，它会引发一些错误。
是否有避免这种行为的最佳实践方法？我们应该使用第二个数据库和 solr 索引吗？我们正在使用 capistrano 进行部署。
【问题讨论】：
标签： mysql ruby-on-rails deployment solr capistrano
这是长期运行的复杂 Rails 数据库迁移的常见问题。
有几种方法：
(1) 在运行数据库迁移之前，将您的网络流量重定向到带有消息的页面，例如“我们将在接下来的 30 分钟内进行维护”。这将防止任何请求进入并使用仅部分迁移的数据库访问您的应用程序。由于停机时间，这并不理想。
(2) 在代码部署之前运行数据库迁移，但要确保数据库向后和向前兼容。然后部署您的代码以使用新架构。如果您需要“回滚”，您可能也想写入旧模式（直到下一个版本）。然后稍后在另一个迁移中删除或重命名列以清理架构。这称为“零停机数据库迁移”。
(3) 您可以有两个数据库，一旦准备好新数据库，您就可以进行切换。但是这里的问题是如何让它们保持同步，如果有来自应用程序的频繁写入。之后您可以运行一个脚本来同步它们。
作为预防措施，您应该在迁移之前对数据库进行备份转储，以防您需要回滚。由于某些数据库迁移是不可逆的，例如，删除列。 或者您可以将受影响的表复制到临时表中作为备份。
当然，在相对平静的时期进行迁移。
对于 solr，它应该处理增量更新而不抛出错误。
【讨论】：