11

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

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

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

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

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

特别感兴趣。

4

5 回答 5

5

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

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

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

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

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

所以总共有 4 个数据库：

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

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

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

于 2008-08-28T01:39:40.673 回答
2

我猜你考虑过斯科特·安布勒的读物吗？ http://www.agiledata.org/essays/databaseRefactoring.html

于 2008-08-27T21:15:14.257 回答
1

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

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

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

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

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

于 2008-08-28T01:29:11.930 回答
1

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

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

于 2008-08-28T02:43:33.780 回答
1

两个快速说明：

  1. 不用说...所以我会说两次。
    验证您是否有有效的备份。
    验证您是否有有效的备份。

  2. @mk。查看Jeff 关于数据库版本控制的博文（如果您还没有的话）

于 2008-08-28T04:44:58.077 回答