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

Question

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

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

Answer 1

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

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

此迁移会向discount_token表格添加users列，并可应用于：

rake db:migrate

在Capistrano中，一旦部署成功，就会为您完成这项任务。除了引入这个新领域之外，不会丢失任何数据，也不会改变任何记录。如果发生其他任何事情，您的迁移中会发生一些非常奇怪的事情。

请记住，一些规则：

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

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

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

Answer 2

除非您要删除表格或删除列migrations，否则不会出现任何问题。

要避免某些与迁移相关的问题，请确保遵循以下规则：

1. 如果可能，请尝试重命名table或column，而不是删除并创建具有相同结构的表格。
2. 如果您需要回滚，请检查您的迁移是否为reversible
3. 如果您正在编写脚本来更新数据库，请确保准备好counter-script。
4. 最重要了解迁移正在做什么在暂存环境中交叉验证，以确保您不会丢失数据 - 通过 @CraigRinger