几个技巧解析SQL Server群集的难题[2]

Posted 2023-05-06

参考技术A

　　为了将停机时间减到最少 您很可能必须使用日志传送 除非您的数据库相当小并且在一段时间内没有用户建立连接 在移交之前 您都可以正确执行日志传送 接着 删除这些用户 剪切并传送最后的日志 然后指向新实例上的应用程序 (有关感兴趣的日志传送替代方法 请参阅下面的数据库镜像部分 )如果使用DNS别名 您甚至可能不需要指向新实例上的应用程序 而是只需更新 DNS 别名 这种方法的优点是 如果您的迁移只进行了一部分 但必须要回退到原始状态 那您至少还有原始文件

　　您还可以采用一种成本较低的方案 但需要您做更多的预先规划 一个群集可以支持多个SQL Server实例 但每个实例必须有其自己的磁盘资源 因此 在划分SAN时 请留出一个LUN 以备将来升级 要执行升级 请在此磁盘资源上安装 SQL Server 二进制文件 您可以演习一下该系统 当您准备好后 关闭当前SQL Server 将磁盘资源从旧的 SQL Server组中移出 更新依赖关系 然后使新SQL Server实例在线 连接旧实例中的数据库 然后启动并运行 (您已提早备份了所有数据 对吗?)

　　这就是成本较低的方法 实行这个方法需要承担一些风险 如果出现故障 您无法将数据库与新实例分离开来并放回原来位置 您的操作已简化为从备份恢复 这意味着需要很长的停机时间

　　还有一种方法是将两个SQL Server实例都放在您的SAN中 前提是您有足够的磁盘空间 将生产备份(和日志传送)恢复为新实例 然后按前面介绍的步骤继续进行 但现在您有退路了 而且 一旦完成迁移 您还可以释放旧实例占用的SAN资源 您只需增加额外的磁盘

　　负载平衡

　　让我们首先揭穿这样一个常见误解 MSCS群集是用于获得高可用性的 而非用于实现负载平衡 此外 SQL Server没有任何内置的 自动负载平衡功能 您必须通过应用程序的物理设计来实现负载平衡 这意味着什么?

　　随着表的逐渐增长 您可能会预料到性能会降低 特别是在涉及到表扫描操作时 当行数达到数百万或数十亿时 传统的解决方案会使用已分区视图 这种视图由若干具有相同结构 使用 union ALL 挂接在一起的表组成 此外 还会在适当位置放置 CHECK 约束来区分这些成员表 而这会阻止跨已分区视图复制数据 如果在 CHECK 约束中使用的列也是主键的一部分 则该视图是可更新的

　　如果成员表在其自己的文件组中 则如果这些文件组中的文件分别位于不同的物理驱动器上 那么您会获得更佳的磁盘性能 这些表甚至也可以位于不同的数据库中 但是 在SQL Server 中 只要所有数据均在同一个数据库中 您就可以使用表分区 而表分区实现起来就容易得多了

　　但是 假设您已经尽可能地利用了表分区或(本地)已分区视图 但性能仍然很低 如果您拥有SQL Server 或SQL Server 就可以利用分布式已分区视图了 主要差别在于 成员表可以位于不同的 SQL Server 实例上 而且这些实例可以安装在 N+ 群集上 为什么鼓励您这样做?如果已分区视图中的任何一个成员表转入离线状态 则整个视图也将转入离线状态 使这些成员成为群集的一部分可以为您提供支持性能和实现负载平衡所需的可靠性

　　您真的需要群集吗?

　　或许您有一些备用服务器无事可做 但这些服务器不在 Windows 目录的群集部分中 如果您在这些服务器可用的情况下 只是为了支持群集就必须出去购置新服务器 那么这是一种浪费可耻的行为

　　数据库镜像可能是最适合替代群集的一种方法 镜像涉及到三个元素 存储镜像数据库的实例称为主体;备份服务器称为镜像;如果要实现自动故障转移 还需要第三台服务器 称为见证方 简而言之 主体上的数据库中的事务会在镜像中再次运行 当主体出现故障时 如果有见证方 数据库会自动故障转移到镜像 您必须为每个应用程序数据库设置镜像 但不能镜像系统数据库

　　镜像是单独的SQL Server 实例 与群集不同的是 镜像可以位于几千英里以外 其高速缓存中填充的是由于从主体中复制事务而发生的更新活动 当然 还可以假设 除了从主体接收镜像事务之外 镜像上没有其他活动 既然 SQL Server 已经在镜像中运行 所以 故障转移的速度通常要比在群集中快 由于至少有部分高速缓存已准备好 所以 初始性能并不像在群集方案中那样低 另请注意 当镜像数据库发生故障转移时 主体和镜像会互换角色

　　数据库镜像的不足之处是 需要的总磁盘容量是群集的两倍 如果您想在同步模式下运行且不想丢失任何数据 那么您还会需要更多的 CPU 处理能力 正如我所说的 要想实现高可用性 需要花费很高的成本

　 　组合方法

　　由于镜像与主体之间的距离可以相当遥远 所以对于灾难恢复 (DR) 计划来说 选择镜像是非常明智的 群集是您的第一道防线 但是 如果您要同时利用群集和镜像 那会出现什么情况呢?在群集故障转移中 如果您的镜像配置中有见证方 则当群集 SQL Server 转入在线状态时 镜像会成为主体 但是 请注意 从新主体回到(群集的)新镜像的故障转移不是自动进行的 因此 当与群集结合使用时 最好不要对您的镜像数据库启用自动故障转移

　　灾难恢复并不是您使用镜像的唯一原因;当您必须向主体应用服务包或修补程序时 镜像也是非常有用的 在这种情况下 您可以手动故障转移到镜像 在应用服务包或修补程序时 旧的主体服务器暂时处于离线状态 在新主体上发生的已提交事务会排队等候 等待被发送回新镜像(旧主体) 在完成服务包或修补程序的安装之后将会进行同步 最终 这两台服务器将完全处于同步状态 现在您便可以在主体和镜像之间转换角色了 故障转移与恢复只需要几秒钟的停机时间 您可以使用这种方法将 SQL Server 迁移到另一台计算机 只是不能实现故障恢复

　　虚拟服务器添加灵活性

　　虚拟化允许您在一台物理服务器上并行运行一个或多个操作系统 虚拟化软件为群集概念添加了另外一层功能 因为您可以将软件加入群集 因此 如果主机正在其上运行的服务器出现故障 则主机及其来宾 OS 会故障转移到备份节点 这可能是迁移来宾服务器的最简便方法 补充一点 来宾 OS 不必具有群集功能 因此 您可以在运行于某群集中的 Microsoft Virtual Server 之上的来宾 Windows Server 内部运行 SQL Server Workgroup Edition 实质上 您会间接拥有群集 Workgroup Edition

　 　在控制之下

　　如果您在负责 SQL Server 实现 您需要确信您的服务器始终处于可用状态 服务器群集会帮助确保您的服务器始终可用 本文提供了一些来之不易的技巧 以帮助您入门 您可以在 群集资源 边栏中找到更多有用信息

lishixinzhi/Article/program/SQLServer/201311/22476

sql server alwaysOn理论篇

转自：https://www.cnblogs.com/jenrrychen/p/5199488.html

前言

SQL Server 2012引入了全新的HADR技术 -- AlwaysOn。AlwaysOn可谓是集SQL Server 2012之前各种HADR的优点于一身，比如故障转移群集的高可用行，日志传送的数据副本可访问，镜像技术的高同步和自动页面修复。同时它的可用性组概念又规避了故障转移群集必须是整个实例完全转移的“缺点”。在架构上的可拓展性也是其一大优势。多只读辅助副本来帮助减轻主副本的数据读取负载对于某些大型应用是一大利器。以及可以再与故障转移群集相结合来实现更高层次的高可用也体现了其对于大型应用的支持。

 

AlwaysOn可用性组的前提条件

1）服务器不能是域控制器

2）服务器OS需要是Windows Server 2008或以后的版本

3）服务器需要是Windows故障转移群集的节点

 

AlwaysOn可用行组数据库的要求

1）只能是用户数据库，这点和镜像技术是一样的；

2）可读写；

3）多用户模式；

4）完全恢复模式；

5）做过完整备份；

6）不属于其他的可用性组；

 

重要特性

1）多用户数据库为可用性单位

2）虚拟网络服务器名

3）三种故障转移模式

4）最多可以有8个辅助服务器（SQL SERVER 2012最多4个，SQL SERVER 2014最多8个）

5）主服务器和辅助服务器数据加密和压缩

6）自动修复某些类型的数据页面损坏

7）辅助服务器数据只读，分担一部分主服务器负载

8）辅助服务器可以执行备份和DBCC命令

9）AlwaysOn专属Dashboard、DMV、Performance Counter和Extended Events支持

 

与其他高可用与灾难恢复（HADR）技术对比

SQL Server 2012之前的版本提供的高可用与灾难恢复（HADR）技术众多，但是难有一种是“完美”或者说可以被看成是一种解决方案的。各自都存在一些优缺点。

集群：优点是可以故障转移；缺点是共享了同一份数据，无副本，一旦数据出问题就完全不可访问；自动故障转移是整个实例级别；

日志传送：最老的HADR技术，依赖于事务日志。优点是一个数据库可以同时有一个或多个数据库副本，而且还是可以访问的，可以实现读写分离分担主服务器压力，缺点是一旦灾难发生，会出现短暂的数据丢失。不支持自动故障转移。恢复时间相当长。相当于把副本备份然后还原到当前的生产数据库，在承当数据丢失的情况下，前提是故障是数据库级别，不能是硬件或者实例（Windows服务）级别。

事务复制：这个不是灾难恢复技术，只是作为高可用技术的一种。依赖于事务日志。优点是高可用的对象可以细化到表级别，也可以把它看成是ETL技术的一种选择，用于分发数据到其他的订阅节点是非常好的技术，对于实现读写分离也是一个选择。缺点是一旦灾难发生，会出现数据丢失，而且会给服务器增加负担。和日志传送一样依赖于事务日志，注定很多缺点两者都相似。

数据库镜像：SQL Server 2005后的HADR技术。优点是可以保证不会出现任何数据丢失，也支持故障转移；缺点是副本不可访问，仅在故障转移时才可访问，无法读写分离减轻服务器压力。

AlwaysOn：可以说它就是对其他高可用与灾难恢复（HADR）技术的集大成者，吸取了数据库镜像的数据库级别的故障转移，日志传送的副本可访问（只读）特点，故障转移集群的多节点和自动故障转移和检测的能力。它不像故障转移集群必须是对整个实例级，也不像数据库镜像和日志传送只能对单个数据库，AlwaysOn的核心思想是“可用性组”，每个可用性组包含的是一个或若干个数据库，然后把整个可用性组一起进行故障转移。

 

《SQL Server 2012实施与管理实战指南》一书中总结了这5种技术的一些特点。

 

 AlwaysOn和Windows群集的关系

AlwaysOn的故障转移特性是基于Windows群集实现的。因为故障侦测和转移也具备了一些Windows群集的特性：

1）同一可用性组的可用性副本必须处在同一Windows群集内

2）同一可用性组的可用性副本必须运行在不同的Windows节点上

3）如果某个可用性副本是一个SQL群集实例，同一SQL群集的其他非活跃节点上安装的任何其他SQL实例不能作为它的辅助副本

4）一个数据库只能属于一个可用性组

 

使用虚拟网络服务器名和Listener，由Listener来决定是否Failover

Listener决定把客户端请求是否重定向到其他的辅助副本上。它本身是不支持SQL Browser的，因为使用虚拟网络服务器名本身就是使用默认实例的一种用法。既然是使用默认实例，那也就不存在命令实例和其端口号一说了。那SQL Browser也就没用了。如果本身使用虚拟网络服务器名，每个副本都使用默认实例。

 

架构流程图

可用性模式

异步提交模式：事务被提交前无需先等待某个辅助副本将事务日志固化。这种模式下一般辅助数据库都是出于SYNCHRONIZING状态。这种模式一般适用于那些主副本和辅助副本物理距离远的情况。

同步提交模式：事务被提交前需要先等待某个辅助副本将事务日志固化。这种模式下辅助数据库会出于SYNCHRONIZED状态。

 

AlwaysOn事务提交流程

 

可用性副本连接状态

DISCONNECTED: 主副本和辅助副本间互相发送ping。默认超时时间为10秒。最低为5秒。建议10秒甚至更长，避免SQL Server过于繁忙。

 

可用性模式对事务复制的影响

事务复制的Log Reader不会去处理那些尚未复制到辅助副本的日志记录。因为如果事务复制处理了这些日志，就会造成订阅服务器的记录比辅助服务器的数据新鲜度要新。这时一旦发生Failover，辅助副本就会被自动切换成主副本，这样就会出现辅助副本的数据比订阅服务器的记录旧。这种情况是不允许。

 

故障转移形式

AlwaysOn通过加载了一个名为hadrres的DLL。因为AlwaysOn其实也是依托Windows群集服务，所以其实也是由RHS.exe进程来加载这个DLL。从名字可以看出是High Availibility Disaster Recovery Resource的简称。也就是其实这条进程是用于控制可用性组资源的上下线的。

AlwaysOn和SQL Server的群集其实是一样通过调用存储过程sp_server_dianostics来检查群集的状态。调用方法存在hadrres.dll中。hadrres.dll开启一条线程连接到SQL Server并且一直保持，不断调用这个存储过程来获取SQL Server的状态信息。返回结果和AlwaysOn可用性组的FailureConditionLevel配置进行对比，以决定是否切换到辅助副本上。

HealthCheckTimeout间隔为30000毫秒。一个实例只会运行一次sp_server_dianostics，不管有多少个可用性组。多个可用性组将选择最小的间隔设置值值除以3作为生效的间隔。sp_server_dianostics只是检查实例的状态，而不是检查数据库的状态。

 

故障恢复模式：自动，手动和强制

 

AlwaysOn是否触发故障转移是由故障恢复模式和可用性模式决定的

 

 自动故障转移：

1）主副本和辅助副本连接状态置为DISCONNECTED并且断开所有客户端连接；

2）等待辅助副本把日志操作前滚（redo）完毕

3）辅助副本切换为主副本，此时如果没有任何可用辅助副本，主副本的可用性组状态就是NOTSYNCHRONIZED

4）原来的主副本变成可用后变成辅助副本，同步现有主副本后面生成的日志记录

 

手动故障转移：

当主副本和辅助副本处于SYNCHRONIZED状态时，可以执行手动故障转移。此时不会出现数据丢失。

 

强制故障转移

当主副本停止，辅助副本进入“RESOLVING”角色。此时RESOLVING角色既不是主副本也不是辅助副本。如果执行强制故障转移把辅助副本转成主副本，可能出现数据丢失。而且，其他副本在执行完强制故障转移之后可能需要重新配置可用性组，因为强制故障转移形式导致新的主副本不能确定与其他副本间的数据一致性。

 

手动故障转移的途径：

1）T-SQL语句

2）SSMS UI界面

3) PowerShell

 

多子网可用性组的故障转移

客户端应用程序使用MultiSubsetFailover来支持多子网可用性组的故障转移，配置Listener

 

Split Brain（大脑分裂）

大脑分裂是指发生故障转移时存在新的主副本上线和旧的主副本仍然在线存在的这种同时出现两个主副本的情况。为了避免这种情况，AlwaysOn可用性组有一个叫LeaseTimeout，意思是如果主副本在LeaseTimeout之前没有收到Windows群集服务的消息，就会自动终止SQL Server的运行。因为其实主动权在Windows群及服务手中。它认定故障转移发生并转向另外的新的主副本，从而不发生通信消息给旧的主副本。LeaseTimeout很快就到，这样旧的主副本就会终止自己的服务。从而避免大脑分裂。

 

只读辅助数据库

辅助副本上的数据库是可以被配置成只读，然后通过AlwaysOn的只读路由功能将只读请求重定向到只读辅助副本上，从而已经分担主副本的工作负载。鉴于SQL Server允许最多可以有6个辅助副本，也就是意味着我们最多可以有6个只读辅助数据库来分担读的压力。当然越多的辅助副本，数据滞后的可能性就越大，因为每个辅助副本的负载都不尽相同，与其增加多副本，倒不如把资源集中在两个或者三个副本上。建议不要超过4个副本。把主副本和辅助副本都放置在同一局域网（同一台交换机相连），配置主副本和辅助副本的可用性模式为异步提交模式。虽然这样数据滞后的发生可能性会增大，也就是数据出现延迟。这里其实是有两种方案。一种是多个辅助副本，每个副本（包括主副本和辅助副本）的硬件配置相同（参考了携程的架构设计），而且把辅助副本的数量保持在2个内。另外一种是主副本和辅助副本的硬件配置不相同，根据其角色的特征选定硬件，这种可以参考携程的数据库架构。前者的好处是可以把可用性模式设置为同步提交模式，让可用性数据库的数据延迟降至最低。这是基于相同的硬件和处在局域网高速网络的条件考虑下做出的判断。加上限定了尽可能少的辅助副本来避免过多副本造成的数据滞后影响。理论上是可以。不过即便如此，数据的延迟也肯定还是会出现。最重要的一点，也是缺点，就是硬件代码太高了。容易造成硬件浪费。如果不是大型应用，而且对数据实时性的要求又很高，可以考虑这套做法，也就是把资源都尽量集中在两个或者三个机器或者群集上。第二种做法是主副本使用SAN存储结构，加上SQL Failover群集，多个辅助副本使用SSD存储结构保证数据读取和写入的速度，可用性模式配置成异步，最后加上负载均衡硬件机器来分散数据读取请求。可以参考《数据库技术与应用专场-03AlwaysOn技术在携程核心数据库的应用》。对于整个架构我唯一处在的疑问在于，配置成异步提交模式以为着会出现数据延迟。而携程的做法是通过一张代表可用性资源组时间戳的表来代表数据的新鲜度，然后应用程序在读取辅助副本数据的时候检查这张表以判断是否超过数据延迟的容许程度，以决定是否把数据读取访问返回给主副本。如果可以有效地控制好数据延迟的上限，那也可以接受。因为这样假设一旦出现N个线程排队等待修改同一行数据的情况，这个时候交易事务提交后到了主副本中检查数据行的数据版本（提交表单中带有的，来自于辅助副本上）和数据库中的当前行是否一致，不一致则说明数据过期，这个时候事务失败。其实也就是要结合应用程序和数据库技术，最后需要承当起一定的代价。我是这么看的。

 

SQL SERVER实现只读辅助数据库的重导向依靠的是：

1）它的“只读路由”功能；

2）辅助数据库配置为只读模式；

3）应用程序发起连接时指定了ApplicationIntent为READONLY。

 

ApplicationIntent

目前支持ApplicationIntent的数据库驱动有：SQLNCLI11 ODBC和OLEDB、.NET FRAMEWORK的SQLClient和JDBC for SQL Server 4.0

 

只读路由

SQL Server的只读路由功能会帮助你分流一部分的读取请求去到辅助数据库上。但是需要说明，在多个辅助数据库的情况下，到底最后面会去到哪个辅助数据库上是会收到路由配置和副本的状态影响的。所以说本身SQL Server自己是没有办法实现负载均衡。要实现比较真实的负载均衡，你需要依靠专业的负载均衡机器来帮助实现（通过直接访问实例名），或者通过应用程序层面编写一套自己的算法来分摊负载。

主副本的连接访问类型：ALL -- 默认，允许读写；READ_WRITE -- 不允许连接字符串带有Application_Intent = Readonly

辅助副本的连接访问类型：ALL -- 只是为了满足那些无法使用Application_Intent的客户端，其实无论如何只要尝试修改数据都会报错；READ_ONLY -- 为了支持只读路由自动分流数据读取；NONE -- 不接受任何访问请求；

只读路由的工作前提是Application_Intent = READONLY和使用Listener来连接可用性组。

 

辅助数据库上的潜在性能问题

阻塞和死锁

由于辅助数据库需要和主数据库进行数据同步，写入操作是几乎可能不间断的发生，而又因为可能同时也是一个只读的数据库，所以锁的冲突、阻塞和死锁是潜在的问题。阻塞问题在AlwaysOn是有行版本控制来解决的。所有对辅助数据库的数据查询都运行在快照隔离级别下。即便如此，查询还是会申请架构共享锁（Sch-S），所以还是存在和DDL语句相冲突。死锁也是可能发生的，不过AlwaysOn的事务日志重写是优先级别高而不可能被选为牺牲者。

行版本控制和临时统计信息带来的Tempdb的空间增长

行版本控制和临时统计信息可能带来的Tempdb的空间增长。需要对Tempdb的合理配置，比如Growth和Maximum Size的配置，数据文件数量的配置，文件location的选择。

 

监控AlwaysOn可用性组的运行状态

1）系统视图和动态管理视图（DMV）

实例级别的：

sys.dm_hadr_cluster

sys.dm_hadr_cluster_members

sys.dm_hadr_cluster_networks

sys.dm_hadr_instance_node_map

sys.dm_hadr_name_id_map

 

可用性组级别：

sys.availability_groups

sys.availability_groups_cluster

sys.dm_hadr_availability_groups_states

 

可用性副本级别：

sys.availability_replicas

sys.availability_read_only_routing_lists

sys.dm_hadr_availability_replica_cluster_nodes

sys.dm_hadr_availability_replica_cluster_states

sys.dm_hadr_availability_replica_states

sys.fn_hadr_backup_is_preferred_replica

 

可用性数据库级别：

sys.availability_databases_cluster

sys.databases

sys.dm_hadr_auto_page_repair

sys.dm_hadr_database_replica_states

sys.dm_hadr_database_replica_cluster_states

 

与可用性组的Listener相关

sys.availability_group_listener_ip_addresses

sys.availability_group_listeners

sys.dm_tcp_listener_states

 

2）性能计数器

SQL Server:Availability Replica

SQL Server:Database Replica

 

3）Dashboard

 

4) AlwaysOn_health会话（Extended Events）

 

5）SQLDIAG拓展事件日志

 

理论篇到此就结束了。接下来的实战篇因为篇幅原因被拆成了两部分：1）活动目录域、DNS服务器和Windows故障转移群集；2）AlwaysOn可用性组搭建；

 

参考：

《SQL Server 2012实施与管理实战指南》

AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution by Using Failover Cluster Instances and Availability Groups

SQL Server 2012 - High Availability - AlwaysOn in Real-life

Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server)

Windows Server Failover Clustering (WSFC) with SQL Server

SQL Server 2012 AlwaysOn High Availability and Disaster Recovery Design Patterns

AlwaysOn 可用性组概述 (SQL Server)