我公司的应用程序今天早上遇到了数据库连接问题，导致我必须故障转移到我们的辅助数据库。在我们的 Azure 应用服务中，这是更改配置中的连接字符串的一个简单步骤，但是我找不到在不重新部署的情况下更改 Service Fabric 服务上的这些设置的简单方法。
我正在考虑允许这些服务在运行时故障转移到辅助数据库的选项，但不知道“最佳实践”是什么。我有几个选择:
我可以为我管理的数据库服务器创建一个 DNS 条目，然后在需要故障转移时将其切换到新的服务器名称。
我可以使用某种剩余 API 来调用我的应用程序服务，该服务将返回是否转到辅助数据库。
还有其他想法吗？我希望尽可能无缝地将故障转移到辅助数据库，以便快速完成。
最佳答案
您是否考虑过将主数据库连接字符串和辅助数据库连接字符串都放入应用程序的配置中，并编写一些代码，以便在检测到问题时在它们之间自动切换？您提供的这两个选项都需要人工介入，这意味着您的用户将经历停机，直到人工解决问题为止(可能人工正在 sleep ，或者在度假，或者在度假并睡着了)。
在 Service Fabric 中，应用程序(和系统)升级始终是 rolling upgrades 。滚动升级的优点是可以防止全局中断。例如，假设在某个时刻您使用错误的连接字符串更新了配置。全局配置更改可能既快速又简单，但现在您遇到了全局中断和一些心烦意乱的客户。滚动升级会捕获第一个升级域中的错误，然后回滚，因此只有一小部分应用程序会受到影响。
您可以进行仅配置的滚动升级。您可以在此处更改 config package然后创建一个differential upgrade package这样只有配置更改才会消失，并且您的服务进程不必重新启动。
关于azure - 在 Azure Service Fabric 中实现数据库故障转移，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41876137/