当数据库架构更改时，Azure无缝升级

Question

假设我有一个生产部署和阶段部署，它们都使用自己的(SQL Azure)数据库。如果暂存中的架构已更改并需要部署到生产环境中，是否有明确的方法在生产数据库上实现数据库升级(而不停机)？

例如，如果我交换VIP staging <->生产(同时以某种方式自动更改连接字符串)，那么自动升级sql azure数据库的最佳过程是什么。

我的想法是发现RoleEnvironmentChanging中的环境变化(尽管不确定VIP交换是否会触发RoleEnvironmentChanginng)，并在这一点上对目标数据库(即prod)运行sql脚本，但是我需要确保该脚本只运行一次，并且将有多个实例转换。

Answer 1

所以你有生产部署，它有自己的SQL Azure数据库，阶段部署，它有自己的SQL Azure数据库。在这种情况下，两个应用程序的连接字符串都指向两个不同的数据库。

您的第一个要求是在交换部署或执行某些操作时动态更改数据库模式，我对该设计有以下关注：

1. 如果您在角色中编写任何代码来执行“一次且仅一次”操作，则不能保证此操作只会发生一次。它将多次发生，具体取决于几种情况，例如

1.1在任何情况下，您的VM都需要由系统重新映像，此代码将执行与上次重新映像完全相同的操作

1.2您可以通过一些外部密钥的注册表方法来保护它不会在角色启动或VM启动时发生，但是有一个完整的证明机制，不会对它进行happen.

• Because，我建议当您准备好交换部署时，您可以：

2.1运行脚本以更新到与生产相关的SQL Azure架构(这不会影响应用程序下载，因为它不会受到影响，但当您的数据库架构更新时，您可能会更好地了解它如何影响您的应用程序)

2.2更改暂存部署中的配置以指向生产SQL Azure (这将根本不会有任何生产应用程序宕机)

2.3交换部署(这也不会造成应用程序宕机)

因此，即使您手动更新DB schema，然后交换部署，除了DB更新模式所需的时间之外，也不会有明显的停机时间。

Answer 2

我一直在到处寻找这方面的最佳实践，但都没有找到。到目前为止，我是这样做的：

• Deploy to staging (生产环境已在运行)
• 将app_offline.htm文件拷贝到生产环境中的web根目录。这样，我就会阻止用户使用应用程序，从而阻止对数据库的更改。我只使用了一个instance.
• Backup数据库。
• 运行DDL，DML和SP脚本。这会将生产数据库更新为最新架构。Staging.
• Swap VIP上的
• 测试应用程序。这会使应用程序恢复在线，因为转移时不存在VIP文件(新的Production).
• If出现问题，请再次交换app_offline.htm.

，恢复数据库并删除app_offline.htm

使用这种方法，我有大约5分钟的停机时间；我的数据库很小，这比等待Vm创建和用户收到错误要好。