在Azure服务结构中实现数据库故障转移
问题描述：
今天早上，我公司的应用程序遇到了数据库连接问题，导致我不得不故障切换到辅助数据库。在我们的Azure应用程序服务中，这是更改配置中连接字符串的一个简单步骤，但是我无法找到在不重新部署的情况下更改Service Fabric服务上的这些设置的简单方法。在Azure服务结构中实现数据库故障转移
我正在考虑允许在运行时将这些服务故障切换到辅助数据库的选项，但不知道“最佳实践”是什么。一对夫妇的选择，我有：
我可以创造我管理的，然后只是那个换成新的服务器名称，当我需要故障转移数据库服务器，DNS条目。
我可以有某种休息API调用我的应用程序服务，将返回是否转到辅助数据库。
还有其他想法吗？我希望尽可能无缝地将故障转移到辅助中心，以便快速完成。
答
您是否考虑过将主数据库连接字符串和辅助数据库连接字符串放入应用程序的配置中，并编写一些能够在检测到问题时自动切换的代码？你提出的两个选项都将人放在了路径上，这意味着你的用户将会经历停机时间，直到人类解决问题（也许人类正在睡着，或者在度假，或者休假和睡着）。
在服务结构中，应用程序（和系统）升级始终为rolling upgrades。滚动升级具有防止全球中断的优势。例如，假设您在某个时候使用错误的连接字符串更新了您的配置。全局配置更改可能快速简单，但现在您的全球中断和一些令人不安的客户。滚动升级会在第一个升级域中遇到错误，然后回滚，所以只有一小部分应用程序会受到影响。
您可以执行仅配置滚动升级。这是您对config package进行更改的地方，然后创建一个differential upgrade package，以便只更改配置并且您的服务过程不必重新启动。
纠正我，如果我错了，但与SQL Azure，如果主数据库有问题，我必须做手动故障转移，所以仍然会有一个人在混合。 – MikeS
嗨Vaclav，有没有任何功能来更新配置参数，通过PowerShell，通过资源管理器或类似的？如果不必重新部署应用程序\配置文件，就必须调整一些很好的设置，这与Web.config更改类似，它可以在应用程序发生时刷新应用程序。恼人的是必须更新新版本，签入代码，等待构建和部署过程，以便通过资源管理器界面或PowerShell实现。 –