sql-server – 群集与事务复制与可用性组
|
假设您需要确保依赖SQL Server 2012作为其数据库后端的应用程序全天候可用,即使一台服务器计算机出现故障. 作为开发人员而不是DBA,我很难理解何时使用哪种方案来实现故障转移/高可用性： > Windows故障转移群集中的两个(或更多)服务器,SQL Server作为群集实例 每种方案中的哪一种适用于哪种工作负载,以及这些方案可以处理哪种类型的故障/中断？它们甚至可比较/可交换吗？ 解决方法我总是喜欢可视化高可用性解决方案的方式如下：SQL Server故障转移群集实例(FCI) 什么是高可用性？整个实例.这包括所有服务器对象(登录,SQL Server代理作业等).这还包括数据库及其包含的实体.对于高度可用的SQL Server实例来说,这是一个很好的解决方案,因为这将是这个给定解决方案的遏制级别. 报告怎么样？无,NULL,不存在.故障转移群集实例具有主动节点,其传递包含实例,VNN等的群集组,并且所有其他节点都是被动的,处于空闲状态(就当前群集组而言)并等待故障转移. 发生故障转移时会发生什么？ FCI的停机时间将取决于被动节点获取群集资源并使SQL Server实例处于运行状态所花费的时间.这通常是最短的时间. 任何客户端抽象？是的,这将使用故障转移群集实例的虚拟网络名称进行内置.这将始终指向当前正在提供SQL Server群集资源的活动节点. AlwaysOn可用性组 什么是高可用性？可用性组将成为此处高可用性的逻辑包含,而可用性组由许多数据库和虚拟网络名称(侦听器,可选群集资源)组成.值得注意的是,登录和SQL Server代理作业等服务器对象不会成为HA解决方案的一部分,需要特别注意确保使用可用性组正确实现这些对象.这不是一个过度负担的要求,但需要得到照顾. 报告怎么样？这是一个很好的报告解决方案,虽然我可能不会使用同步副本作为我的报告实例.有两种提交关系,同步和异步.在我看来,从我在实践中看到的,是你的同步辅助副本在那里等待灾难.将其视为可以在出现问题时进行无数据丢失故障转移的副本.然后有异步副本可以处理该报告工作负载.您没有使用此副本作为上述解决方案,但更多的是用于报告等内容.报告工作负载可以指向此副本(直接或通过侦听器通过只读路由间接指向). 发生故障转移时会发生什么？对于与自动故障转移配对的同步提交辅助副本,这将是从SECONDARY_NORMAL到PRIMARY_NORMAL的副本角色状态更改.为了实现自动故障转移,您需要具有当前已同步的同步辅助副本,并且实现的是Flexible Failover Policy以确定何时应该发生此故障转移.该政策确实可配置. 任何客户端抽象？是的,您可以选择配置AlwaysOn可用性组侦听器.这基本上只是一个虚拟网络名称(可以通过WSFC看作AG集群组中的集群资源)指向当前主副本.这是转移报告工作负载的关键部分,以及在要重定向ReadOnly流量的任何服务器上设置只读路由列表(这是通过连接字符串,使用.NET Framework Provider for SQL设置的)服务器,这将是Application Intent参数,设置为ReadOnly).您还需要为辅助副本角色中要接收此报告工作负载的每个副本设置只读路由URL. 事务复制 什么是高可用性？这是有争议的,但我什么都不会说.我不认为复制是一种高可用性解决方案.是的,正在向订阅者推送数据修改,但我们正在发布/文章级别进行讨论.这将是数据的一个子集(可能包括所有数据,但不会强制执行.即,您在发布者数据库中创建一个新表,并且不会自动推送到订阅者).对于HA来说,这是最底层的,我不会在那里用坚如磐石的HA解决方案进行分组. 报告怎么样？报告数据子集的绝佳解决方案,毫无疑问.如果您有一个高度事务性的1 TB数据库,并且您希望将该报告工作负载保留在OLTP数据库之外,则事务复制是将一部分数据推送到订阅者(或订阅者)以报告工作负载的好方法.如果在1 TB的数据中,您的报告工作量仅为50 GB,会发生什么？这是一个智能解决方案,可相对配置以满足您的业务需求. 摘要 它归结为一些需要回答的问题(部分由业务部门解决)： >什么需要高度可用？> SLA对HA / DR的要求是什么？>将会发生什么样的报告以及可接受的延迟？>我们需要处理地理位置分散的HA？ (存储复制很昂贵,但必须使用FCI.AG不需要独立实例的共享存储,并且您可以使用文件共享见证来实现仲裁,从而可能无需共享存储) （编辑：济源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
