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

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