我对SQL的故障转移实际上是如何工作,以及我们需要实现什么和什么是开箱即用的东西感到有点困惑。
我读过这篇文章
https://azure.microsoft.com/en-us/blog/fault-tolerance-in-windows-azure-sql-database/
这是自动故障转移,不需要任何干预。这似乎意味着连接字符串甚至不需要更改。听起来,您可以使用相同的连接字符串同时拥有主站点和辅助站点。
到Windows数据库的所有连接都由一组负载平衡网关进程管理。网关负责接受来自客户端的入站数据库连接请求,并将它们绑定到当前承载数据库主副本的节点。网关与分布式结构进行协调,以定位客户数据库的主要副本。如果发生故障转移,网关将重新协商所有绑定到新主节点的失败主节点的连接绑定。
然后我读了这篇文章
接下来要创建某种连接监控应用程序,为我们做故障转移(听起来自己有点容易失败--为什么这不是一件标准的事情?)并表示辅助站点应该始终指向辅助数据库。也就是说,根本不像第一篇文章听起来的那样。
我看错了吗?第一篇文章(旧的)过时了吗?
发布于 2015-12-21 02:06:33
第一篇文章介绍了它如何在单个数据中心内进行故障转移,指出“除了整个数据中心的丢失之外,所有其他故障都可以通过服务减轻”。如果您的数据库硬件或存储失败,这将覆盖您(S)。
第二篇文章介绍了如何使用geo复制来处理数据中心本身失败的情况,“在本例中,应用程序部署拓扑是为处理所有应用程序组件受到影响并需要作为一个单元进行故障转移时处理区域性灾难而优化的。”
它们都是正确的,并且涵盖了使用相同服务的两种不同的场景。
https://serverfault.com/questions/738986
复制相似问题