更新生产数据库的最佳实践？

Question

我是编程新手。我在生产中使用 Rails 4 和 Postgres 作为数据库。当我更改数据库结构时，使用 Capistrano 部署时更新生产数据库的最佳做法是什么？我想保持生产中的所有数据完好无损。

我注意到有时当我更改模式并部署到生产环境时，一些现有的数据记录会丢失。

Answer 1

除非您要删除 table 或删除列 migrations 永远不会给您带来任何问题。

为避免一些与迁移相关的问题，请确保您遵循以下内容：

Answer 2

通常在更改架构时，您将使用 rails g migration 生成新的迁移，然后执行如下操作：

class AddUsersDiscountToken < ActiveRecord::Migration
  def change
    add_column :users, :discount_token, :string
  end
end

此迁移将向 users table 添加一个 discount_token 列，并且可以应用于：

rake db:migrate

在 Capistrano 中，有一个任务会在部署成功后为您执行此操作。除了引入这个新字段之外，不应丢失任何数据，不应更改任何记录。如果发生任何其他事情，那么您的迁移过程中发生了一些非常奇怪的事情。

记住一些规则：

始终在使用适当的工具应用任何迁移之前备份您的数据。 mysqldump 是一个很好的起点。复制二进制 MySQL 数据文件是不够的，并且不能可靠地工作，如果有的话。
始终测试您的备份并确保一切都在那里。备份过程可能由于某种原因提前终止，未能正确备份所有 table 和数据。
从不在您的实时生产数据库上部署迁移，而不先在副本上进行测试。这是备份派上用场的地方，您有机会恢复它，运行迁移，并测试结果。

这就是为什么拥有一个临时服务器通常很方便，即使它只是一个临时服务器，或者不如您的生产服务器那么强大。它允许您在没有运行中断服务的风险的情况下测试实际的生产数据的迁移。运行您的新生产代码与新迁移的生产数据库并验证您添加的新功能是否正常运行，并检查您没有破坏任何旧代码的回归。

请记住，更改大型 table 架构的迁移（例如具有数百万行的架构）可能需要一些时间才能完成，尤其是在具有非 SSD 支持的数据库的服务器上。在您的暂存系统上进行测试时，记下完成所需的时间，因为您可能需要提前通知用户进行定期维护或更改您的计划以减少对迁移的干扰。

Best practice for updating production database?