7

假设我有一个生产和暂存部署都使用他们自己的（SQL Azure）数据库。如果暂存中的模式已更改并需要部署到生产环境，是否有定义的方法可以在生产数据库上实现数据库升级（无需停机）？

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

我的想法是在 RoleEnvironmentChanging 中发现环境变化（尽管不确定 VIP 交换甚至会触发 RoleEnvironmentChanginging）并在那时针对未来的数据库（即 prod）运行 sql 脚本，但是我需要确保该脚本是只运行一次，就会有多个实例转换。

4

2 回答 2

5

因此，您拥有拥有自己的 SQL Azure 数据库的生产部署和拥有自己的 SQL Azure 数据库的登台部署。在这种情况下，两个应用程序的连接字符串都指向两个不同的数据库。

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

  1. 如果您在角色内部编写任何代码来执行“ONCE and only ONCE”操作，则无法保证这只会发生 ONCE。它会发生多次取决于几种情况，例如

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

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

  2. 因此，我建议当您准备好交换部署时，您可以：

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

    2.2 将 staging 部署中的配置更改为指向生产 SQL Azure（这根本不会有任何生产应用程序停机时间）

    2.3 交换部署（这也不会有应用程序停机时间）

因此，即使您手动更新数据库架构然后交换部署，除了数据库更新架构所花费的时间之外，也没有明显的停机时间。

于 2012-05-15T14:23:50.523 回答
4

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

  • 部署到登台（生产已在运行）
  • 将 app_offline.htm 文件复制到生产环境的 Web 根目录。这样我就阻止用户使用应用程序，从而阻止对数据库的更改。我只使用一个实例。
  • 备份数据库。
  • 运行 DDL、DML 和 SP 脚本。这会将生产数据库更新为最新模式。
  • 在 Staging 上测试应用程序。
  • 换VIP。这会使应用程序重新联机，因为 app_offline.htm 文件在暂存（新生产）上不存在。
  • 如果出现问题，再次交换 VIP，恢复数据库并删除 app_offline.htm。

使用这种方法，我的停机时间约为 5 分钟；我的数据库很小，这比等待创建虚拟机和用户出错要好。

于 2013-06-13T19:55:42.263 回答