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

【问题标题】：Best practice for updating production database?更新生产数据库的最佳实践？
【发布时间】：2016-12-06 04:35:26
【问题描述】：

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

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

【问题讨论】：

【解决方案1】：

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

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

此迁移将在users 表中添加一个discount_token 列，并可应用于：

rake db:migrate

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

记住，一些规则：

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

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

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

【讨论】：

【解决方案2】：

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

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

【讨论】：