数据库架构升级清单答案

【问题标题】：Checklist for Database Schema Upgrades数据库架构升级清单
【发布时间】：2008-08-27 21:11:20
【问题描述】：

必须升级数据库架构使得安装新版本的软件变得更加棘手。这样做的最佳做法是什么？

我正在寻找行动项目的清单或时间表，例如

8:30 关闭应用程序
8:45 修改架构
9:15 安装新应用
9:30 重启数据库

等，展示如何将风险和停机时间降至最低。诸如

之类的问题

如果出现问题则退出升级
尽量减少对现有应用的影响
数据库运行时的“热”更新
从开发服务器升级到测试服务器到生产服务器

特别感兴趣。

【问题讨论】：

标签： database installation version-control

【解决方案1】：

我在这方面有很多经验。我的应用程序是高度迭代的，并且架构更改经常发生。我大约每 2 到 3 周发布一次生产版本，从我的 FogBugz 列表中为每个项目清除 50-100 项。过去几年我们发布的每个版本都需要更改架构以支持新功能。

这样做的关键是在测试环境中多次练习更改，然后在实时服务器上实际进行更改。

我保留了一个从模板复制的部署清单文件，然后对每个版本进行大量编辑，其中包含任何不寻常的内容。

我有两个在数据库上运行的脚本，一个用于模式更改，一个用于可编程性（过程、视图等）。更改脚本是手工编写的，带有 procs 的脚本是通过 Powershell 编写的。更改脚本在所有内容都关闭时运行（您必须为此选择一个惹恼最少用户的时间），并且它是手动逐个命令运行的，以防万一出现任何异常情况。我遇到的最常见的问题是添加了一个由于重复行而失败的唯一约束。

在准备集成测试周期时，我会在测试服务器上检查我的清单，就好像该服务器是生产服务器一样。然后，除此之外，我还获得了生产数据库的实际副本（这是交换异地备份的好时机），并在恢复的本地版本上运行脚本（这也很好，因为它证明了我的最新的备份是健全的）。我在这里用一块石头杀死了很多鸟。

所以总共有 4 个数据库：

开发：所有更改都必须在更改脚本中进行，绝不能在工作室中进行。
测试：在这里进行集成测试
生产副本：最后一分钟的部署实践
生产

当你在生产中做这件事时，你真的，真的需要把它做好。退出架构更改很困难。

就修补程序而言，我只会修补程序，而不是架构，除非它是一个非常孤立的更改并且对业务至关重要。

【讨论】：

【解决方案2】：

我猜你考虑过 Scott Ambler 的读物吗？ http://www.agiledata.org/essays/databaseRefactoring.html

【讨论】：

【解决方案3】：

这是我刚刚在工作中谈论的话题。主要的问题是，除非你的框架很好地处理了数据库迁移，例如 rails 和它们的迁移脚本，否则它就由你决定了。

我们目前的做法存在明显缺陷，我愿意接受其他建议。

有一个包含静态数据的模式转储，这些数据需要保持最新并处于版本控制中。
每次您执行架构更改操作时，ALTER、CREATE 等都会将其转储到文件中，并将其放入版本控制中。
确保更新原始 sql db 转储。
在进行实时推送时，请确保您或您的脚本将 sql 文件应用到数据库。
清理旧的版本控制中的旧 sql 文件。

这绝不是最佳的，实际上也不打算作为“备份”数据库。这只是为了让推送变得轻松，并使开发人员保持在同一页面上。就自动将 sql 文件应用到 db 而言，您可以使用 capistrano 设置一些很酷的东西。

特定于 Db 的版本控制会非常棒。可能有一些东西可以做到这一点，如果没有，可能应该有。

【讨论】：

【解决方案4】：

如果 Scott Ambler 的论文激起了您的兴趣，我可以推荐他与 Pramod J Sadolage 合着的书，名为“重构数据库”-http://www.ambysoft.com/books/refactoringDatabases.html

在雅虎的敏捷数据库小组中也有很多有用的建议和信息 - http://tech.groups.yahoo.com/group/agileDatabases/

【讨论】：

【解决方案5】：

两个快速说明：

不用说...所以我会说两次。
验证您是否有有效的备份。
验证您是否有有效的备份。
@mk。查看Jeff's blog post 了解数据库版本控制（如果您还没有的话）

【讨论】：