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

时间:2012-05-15 09:33:25

标签: azure

假设我使用自己的(SQL Azure)数据库进行生产和暂存部署。如果分段中的模式已更改并需要部署到生产中,那么是否有定义的方法可以在生产数据库上实现数据库升级(无需停机)?

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

我的想法是发现RoleEnvironmentChanging中的环境变化(虽然不确定VIP交换甚至会触发RoleEnvironmentChanginng)并在那时针对要成为数据库(即prod)运行sql脚本,但是我需要确保该脚本只运行一次,将有多个实例转换。

2 个答案:

答案 0 :(得分:4)

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

您的第一个要求是在交换部署或执行某些操作时动态更改数据库架构,并且我对该设计有以下关注:

  1. 如果您在角色中编写任何代码来执行“ONCE且仅ONCE”操作,则无法保证仅在ONCE上执行此操作。它会发生多次,取决于几个场景,如

    1.1在任何情况下,VM都需要由系统重新映像,并且此CODE将执行与上次重新映像时完全相同的操作

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

  2. 由于这个原因,我建议您在准备好SWAP部署时可以:

    2.1运行脚本以更新到与生产相关的SQL Azure架构(这对应用程序下载没有影响,因为它没有被触及但是在更新数据库架构时,您可能更清楚它对应用程序的影响)

    2.2将分段部署中的配置更改为指向生产SQL Azure(根本不会有任何生产应用程序停机)

    2.3 SWAP部署(这也没有应用程序停机时间)

  3. 因此,即使您手动更新数据库架构然后SWAP部署,除了DB更新架构所花费的时间之外,没有明显的停机时间。

答案 1 :(得分:4)

我一直在寻找这个地方的最佳实践并且没有找到。到目前为止,这就是我的工作:

  • 部署到暂存(生产已在运行)
  • 将app_offline.htm文件复制到Production上的Web根目录。这样我就阻止用户使用应用程序,从而阻止对数据库的更改。我只使用一个实例。
  • 备份数据库。
  • 运行DDL,DML和SP脚本。这会将生产数据库更新为最新的架构。
  • 在分段上测试应用程序。
  • 交换VIP。这使应用程序重新联机,因为Staging(新生产)上没有app_offline.htm文件。
  • 如果出现问题,请再次交换VIP,恢复数据库并删除app_offline.htm。

通过这种方法,我的停机时间约为5分钟;我的数据库很小,这比等待创建Vm和用户收到错误更好。