当前位置: 澳门新濠3559 > 操作系统 > 正文

WSFC的故障转移是以资源组为单位的,集群的每个

时间:2019-10-07 14:53来源:操作系统
资源组是由一个或多个资源组成的组,WSFC的故障转移是以资源组为单位的,资源组中的资源是相互依赖的。一个资源所依赖的其他资源必须和该资源处于同一个资源组,跨资源组的依赖

资源组是由一个或多个资源组成的组,WSFC的故障转移是以资源组为单位的,资源组中的资源是相互依赖的。一个资源所依赖的其他资源必须和该资源处于同一个资源组,跨资源组的依赖关系是不存在的。在任何时刻,每个资源组都仅属于集群中的一个结点,该结点就是资源组的活跃结点(Active Node),由活跃结点为应用程序提供服务。AlwaysOn建立在WSFC的健康检测和故障转移的特性之上,和故障转移集群有了不可分割的关系,因此,从底层的集群资源来理解可用性组,知其然知,其所以然,有助于更好地维护AlwaysOn。

资源组是由一个或多个资源组成的组,WSFC的故障转移是以资源组为单位的,资源组中的资源是相互依赖的,相互关联。一个资源所依赖的其他资源必须和该资源处于同一个资源组,跨资源组的依赖关系是不存在的。在任何时候,每个资源组都仅属于集群中的一个结点,该结点就是资源组的活跃结点,由活跃结点为应用程序提供服务。AlwaysOn的故障转移特性建立在WSFC的健康检测和故障转移的特性之上,因此,AlwaysOn和故障转移集群有了不可分割的关系,理解他们的关系,有助于维护更好的维护AlwaysOn。

AlwaysOn是在SQL Server 2012中新引入的一种高可用技术,从名称中可以看出,AlwaysOn的设计目标是保持数据库系统永远可用。AlwaysOn利用了Windows服务器故障转移集群(Windows Server Failover Clustering,简称WSFC)的健康检测和自动故障转移的特性,因此,必须建立在WSFC之上,搭建WSFC的过程,请参考《部署AlwaysOn第一步:搭建Windows服务器故障转移集群》。

一,AlwaysOn的可用性组是集群的资源组

一,可用性组是集群的资源组

AlwaysOn支持的高可用单位是可用性组(Availability Group,简称AG),AG是包含了一个或多个用户数据库(User Database)的容器,AG里不能包含系统数据库;AG以用户数据库的集合为单位进行健康检测和故障转移,就是说,AG中的所有数据库作为一个整体发生故障转移。

AlwaysOn的可用性组(Availability Group)是集群的资源组,其资源类型是“SQL Server Availability Group”,由于,WSFC的故障转移是以资源组为单位的,因此,AlwaysOn的每次故障转移都会将整个可用性组里的数据库一起转移。

AlwaysOn的可用性组(Availability Group)是集群的资源组,其资源类型是“SQL Server Availability Group”,由于,WSFC的故障转移是以资源组为单位的,因此,AlwaysOn的每次故障转移都会将整个可用性组里的数据库一起转移。

一,AlwaysOn的基本架构

1,查看集群的资源组

1,查看集群的资源组

1,了解AlwaysOn的关键特性

打开故障转移集群管理器(Failover Cluster Manager),选中集群结点,点开Roles,集群的每个角色就是一个资源组,在右边的资源组监控器面板中,能够看到创建成功的可用性组 TestAG,角色类型(Type)是Other;

打开故障转移集群管理器(Failover Cluster Manager),选中集群结点,点开Roles,集群的每个角色就是一个资源组,在右边的资源组监控器面板中,能够看到创建成功的可用性组 TestAG,角色类型(Type)是Other;

  • AlwaysOn支持的故障转移,不是以整个SQL Server实例为单位,而是以AG为单位,AG中的多个用户数据库一起进行故障转移;
  • AG提供虚拟的服务器网络名,也就是AG Listener,无论哪台服务器是当前的Primary Server,客户端都可以使用统一的AG Listener进行连接;
  • AlwaysOn在辅助服务器(Secondary Server)上维护用户数据库组的副本,同步提交方式能够使Primary Server和Secondary Server上的数据保持完全同步;
  • 在特定的配置情况下,客户端的只读请求可以被自动定向到辅助服务器,减少了Primary Server的IO压力;
  • 一台主服务器最多对应4台辅助服务器,总共5台服务器,发生故障转移时,可以切换到任意一台辅助服务器上;

图片 1

图片 2

2,推荐安装SQL Server单机实例(stand-alone)

2,资源组的故障转移属性

2,资源组的故障转移属性

部署AlwaysOn之前,必须搭建WSFC环境;在Windows集群的结点上,推荐安装SQL Server单机实例,AlwaysOn仅要求所有的SQL Server实例都运行在同一个Windows集群环境中,但SQL Server实例本身不需要是集群模式的,推荐安装SQL Server单机实例。在SQL Server安装中心中,选择“全新SQL Server独立安装或向现有安装添加功能(New SQL Server stand-alone installation or add features to an existing installation)”。

右击角色的属性,在Failover Tab中,查看集群的故障转移属性的设置,默认设置如下图:

右击角色的属性,在Failover Tab中,查看集群的故障转移属性的设置,默认设置如下图:

图片 3

  • 故障转移(Failover)属性:设置集群在指定的时间区间内执行故障转移的次数;
  • 故障恢复(Failback)属性:设置集群在发生故障转移之后,把资源组移回到最优先节点;
  • 故障转移(Failover)属性:设置集群在指定的时间区间内执行故障转移的次数;
  • 故障恢复(Failback)属性:设置集群在发生故障转移之后,把资源组移回到最优先节点;

3,可用性数据库(Availability Database)

两者的区别是:

两者的区别是:

AlwaysOn可用性组里包含一个或多个用户数据库,称作可用性数据库(Availability Database),每个可用性副本上都存储可用性数据库的副本,这些数据库副本彼此之间互相同步,如果可用性副本是SQL Server单机实例,那么数据库副本就存储在实例的本地磁盘(Local Disk)中。可用性组不能包括系统数据库,就是说,系统数据库不能通过AlwaysOn实现高可用性。

  • 故障转移(Failover)是指:出现故障后转移,集群把故障结点拥有的资源组转移到另一个可用的结点上;
  • 故障恢复(Failback)是指:出现故障后恢复,在发生故障转移之后,如果最优先结点恢复正常,把资源组移回到最优先节点;
  • 故障转移(Failover)是指:出现故障后转移,集群把故障结点拥有的资源组转移到另一个可用的结点上;
  • 故障恢复(Failback)是指:出现故障后恢复,在发生故障转移之后,如果最优先结点恢复正常,把资源组移回到最优先节点;

在多个可用性副本上,只有一个可用性副本上运行的数据库处于可读写状态,这个可读写的数据库称作Primary Database,这个可用性副本称作Primary Replica,其余的副本都称作辅助副本(Secondary Replica),辅助副本上的数据库可能是不可访问的,或者是只读的,这些数据库称作辅助数据库。一旦发生故障转移,任何一个辅助副本都可以成为新的Primary Replica,主副本会不断地将Primary database上的数据更新发送到辅助副本,实现副本间的数据同步。

图片 4

图片 5

4,AG是集群的资源组

3,切换到General Tab

3,切换到General Tab

从WSFC的角度来看,AG是集群的资源组,因此,AG中包含的所有用户数据库是作为一个整体在集群的结点之间进行故障转移的,这使得AlwaysOn非常适合那些需要用到多个数据库的应用程序。

首选结点(Preferred Owners)选项的默认设置是勾选集群中的所有结点,优先顺序是从上到下,第一个勾选的结点是最优先结点(Most Preferred Owners)。

首选结点(Preferred Owners)选项的默认设置是勾选集群中的所有结点,优先顺序是从上到下,第一个勾选的结点是最优先结点(Most Preferred Owners)。

5,侦听器(Listener)

在发生故障转移之后,如果最优先结点恢复健康,那么故障恢复(Failback)将资源组移回到最优先选结点;

在发生故障转移之后,如果最优先结点恢复健康,那么故障恢复(Failback)将资源组移回到最优先选结点;

在故障转移集群管理器(Failover Cluster Manager)中,WSFC只能看到一个资源组,就是AlwaysOn的可用性组(AG),但是应用程序不能使用资源组的名字登录SQL Server实例,必须知道当前主副本(Primary Replica)的名字,使用这个服务器名称连接SQL Server实例。一旦发生可用性组(AG)的故障转移,应用程序必须通过修改连接字符串(Connection String)重新连接到新的Primary Replica上,这很麻烦。通过可用性组侦听器(Availability Group Listener,简称Listener),能够解决该问题。Listener是一个虚拟的服务器,用于让应用程序透明的连接到主副本而不会受到故障转移的影响,一个Listener包含虚拟的网络名(DNS Name),虚拟IP地址和端口号。创建了Listener之后,WSFC就会为可用性组资源添加虚拟IP地址和虚拟网络名资源,应用程序通过连接虚拟网络名,连接主副本(Primary Replica)上的SQL Server实例。

图片 6

图片 7

应用程序使用Listener的虚拟网络名连接SQL Server实例,是以一个默认实例的形式访问的,只有服务器名,没有SQL Server实例名,因此应用程序不会尝试使用SQL Brower 服务。推荐AlwaysOn的各个副本都使用默认实例,默认端口。如果Listener使用的端口号是默认端口1433,那么应用程序能够直接使用虚拟网络名连接到SQL Server实例。

二,从集群资源的角度来看待SQL Server 可用性组**

二,集群资源的属性

二,AlwaysOn的数据同步原理

由于AlwaysOn 可用性组建立在故障转移集群之上,可用性组就是Windows 集群的资源组,在故障转移集群管理器中,通过配置集群资源的属性,控制AlwaysOn 可用性组的健康检测和故障转移特性的底层特性。

由于AlwaysOn 可用性组建立在故障转移集群之上,Windows 集群负责监控AlwaysOn 可用性组的健康状况。点击角色TestAG下方面板Resource选项卡,能够看到该资源组拥有两个资源:可用性组TestAG和Listener。每个资源,都有Status标识该资源的健康状态。

AlwaysOn会在各个副本上维护数据库的副本,主副本上发生的数据更新,都会同步到辅助副本上,为了实现数据同步,AlwaysOn需要完成三个任务:

点击角色TestAG下方面板Resource选项卡,能够看到该资源组拥有两个资源:可用性组TestAG和侦听器TestListener。这两个资源在创建AlwaysOn时,由系统自动创建。每个资源,都有Status标识该资源的健康状态。

图片 8

  • 把主副本上发生的数据更新的事务日志记录下来;
  • 把事务日志记录传输到各个辅助副本;
  • 在各个辅助副本上重做数据更新;

在Server Name 选项卡中,列出AlwaysOn可用性组中包含的Listener,该Listener 的集群资源类型是Network Name,这就是说,AlwaysOn不使用Windows集群的虚拟网络名和虚拟IP地址,而是使用Listener来作为访问可用性组的网络接口。无论Windows 集群的虚拟网络名,还是AlwaysOn的侦听器Listener,其资源类型都是相同的(Network Name),都有虚拟网络名(DNS Name)和虚拟IP地址,只是一个服务于Windows集群,一个服务于AlwaysOn,其行为是相同的:

1,SQL Server 可用性组资源的属性

在主副本和辅助副本上,SQL Server都会启动相应的线程来完成相应的任务。

  • 使用Windows集群的虚拟网络名,用户看不到集群背后的一堆Windows Server,当资源发生故障时,WSFC自动将资源转移到健康的结点上;
  • 使用Listener,用户看不到AlwaysOn集群背后的一堆可用性副本,当一个副本发生故障时,AlwaysOn自动转移到健康的副本上;
  • 根本差异在于:集群使用共享资源,没有数据的冗余,而AlwaysOn的各个可用性副本(Availability Replica)上都存储数据的一个副本;

TestAG资源的类型是SQL Server Availability Group,状态是Online

1,日志持久化

图片 9

图片 10

任何一个SQL Server都有个Log Writer线程,当事务提交一个数据更新时,Log Writer把数据更新的日志写入到物理事务日志文件。

1,集群资源(可用性组)的属性**

2,切换到Dependencies Tab,查看资源的依赖关系

2,主副本的日志传输

TestAG资源的类型是SQL Server Availability Group,状态是Online

资源组中的资源是相互依赖的,一个资源所依赖的其他资源必须和该资源处于同一个资源组,跨资源组的依赖关系是不存在的。资源TestAG 和 资源Server Name之间是“and”的关系,这就是说,只有这两个资源都处于Online状态之后,整个资源组才处于可用的Online状态。 

对于配置AlwaysOn 主副本的数据库,SQL Server创建一个Log Scanner线程,负责将日志记录从日志缓冲区或者事务日志文件读出,打包成日志块,发送到各个辅助副本,由于Log Scanner线程的不间断工作,使得主副本上的数据变化,不断地向辅助副本上传播。

图片 11

3,切换到Policies Tab,查看资源出现故障时,集群监控器的响应策略

3,辅助副本上的固化(Harden)和重做(Redo)

2,切换到Dependencies Tab,查看资源的依赖关系

该选项卡的选项决定了资源发生故障转移时的行为,建议保留其默认设置,默认设置是当资源出现故障时,会在15分钟内尝试在当前结点重启(一般是立即尝试重启,不需要等待15分钟),第一次尝试重启失败,就会将整个资源组转移到其他的结点上。

在辅助副本上,同样有两个线程固化线程和重做线程完成相应的数据更新操作。固化线程将主副本上Log Scanner传入的日志块写入辅助副本的硬盘上的事务日志文件里,而重做线程,负责从硬盘上读取事务日志,将日志记录翻译成数据更新操作,在辅助副本的数据库上重做主副本的数据更新操作。

资源组中的资源是相互依赖的,一个资源所依赖的其他资源必须和该资源处于同一个资源组,跨资源组的依赖关系是不存在的。资源TestAG 和 资源Server Name之间是“and”的关系,这就是说,只有这两个资源都处于Online状态之后,整个资源组才处于可用的Online状态。 

图片 12

当重做线程完成工作之后,辅助副本上的数据库和主副本保持同步,重做线程每隔固定的时间间隔,就会向主副本报告自己的工作进度,主副本根据各个辅助副本的工作进度,就能计算数据的差异。

3,切换到Policies Tab,查看资源出现故障时,集群监控器的响应策略

4,切换到Advanced Policies Tab

在AlwaysOn中,在固化线程和重做线程是完全独立工作的,固化线程负责将主数据库传递的日志写入到硬盘上的日志文件中,将日志持久化存储;而重做线程负责读取和翻译已被固化线程存储的日志,将主数据库上的数据更新操作在辅助数据库上重新执行。

该选项卡的选项决定了资源发生故障转移时的行为,建议保留其默认设置,默认设置是当资源出现故障时,会在15分钟内尝试在当前结点重启(一般是立即尝试重启,不需要等待15分钟),第一次尝试重启失败,就会将整个资源组转移到其他的结点上,默认的关键选项:

配置持有资源的集群结点,配置资源监控器(Resource Monitor)检测资源健康的时间间隔,WSFC为了检测每个资源是否工作正常,会使用不同的时间间隔来做两种不同程度的检查,对于SQL Server可用组资源类型:

三,AlwaysOn的可用性模式

选项“If resource fails, attempt restart on current node”:选择该选项,WSFC在检测到当前资源出现故障后,尝试在当前结点重启;

  • “Basic resource health check interval” 称作“Looksalive check”,默认的时间间隔是5s;
  • “Thorough resource health check interval”称作“Isalive check”,默认的时间间隔是30s;

可用性模式决定了主副本在提交事务之前,是否需要等待某个辅助副本将事务日志记录固化到硬盘,AlwaysOn可用性组支持两种可用性模式:异步提交模式和同步提交模式。

选项 “If restart is unsuccessufll, fail over all resources in this service or application” :勾选该选项,WSFC在第一次重启失败后,将整个资源组转移到集群中的其他结点上;如果不勾选该选项,该资源出现故障,并不会导致整个资源组的故障转移。

图片 13

1,异步提交模式

图片 14

5,切换到Properties Tab

当辅助副本处于异步提交模式时,主副本无需等待辅助副本完成日志固化,就可以提交事务,因此,主副本事务提交不会受到辅助数据库的影响而产生等待,但是,辅助数据库的更新会滞后于主数据库,如果发生故障转移,可能会导致某些数据更新丢失。

4,切换到Advanced Policies Tab

查看和配置资源的私有属性,可用性组HealthCheckTimeout属性默认设置:30000ms,这就是说,每30s,资源监控器都会对资源进行一次健康检测;

在异步提交模式下,辅助副本会尽量和主副本的日志记录保持一致,不过,即使辅助数据库和主数据库上的数据是同步的,可用性组始终认为辅助数据库处于“在同步”(SYNCHRONIZING)状态,因为,理论上在异步模式下,辅助数据库在任何时间点都可能滞后于主数据库。

配置持有资源的集群结点:在Possible Owners 选项卡中,罗列出当前资源能够转移到的结点,也就是指定哪些结点会是当前资源的拥有者;如果一个结点没有被勾选,就意味着当前资源不会在该结点上运行。

图片 15

2,同步提交模式

配置检测资源健康的时间间隔:WSFC为了检测每个资源是否工作正常,会使用不同的时间间隔来做两种不同程度的检查,对于SQL Server可用组资源类型:

三,集群资源的健康检测

在同步提交模式下,主数据库在提交事务之前,主副本必须等待辅助副本将日志固化到硬盘上,主副本只有收到来自辅助副本的日志固化成功的确认信息之后,才能提交事务;只要辅助副本没有向主副本报告日志固化完成,主副本上的事务就不能提交。这样能够保持主副本和辅助副本的数据始终是同步的,只要一直进行数据同步,辅助数据库就会保持”已同步“(SYNCHRONIZED)状态。

  • “Basic resource health check interval” 称作“Looksalive check”,默认的时间间隔是5s;
  • “Thorough resource health check interval”称作“Isalive check”,默认的时间间隔是30s;

集群中的每个资源都有一个资源类型,WSFC根据不同类型的资源,使用不同的方式进行Isalive和Looksalive检查,一般会把SQL Server Availability Group资源类型配置成“If resource fails, attempt restart on current node” 和 “If restart is unsuccessufll, fail over all resources in this service or application”模式,即在资源的Policies 选项卡中勾选相应的选项:

同步提交模式能够实现辅助数据库和主数据库上的数据的完全同步,但是,代价是主数据库上的事务提交延迟增加,可以说,同步提交模式相对于性能来说,更强调高可用性。

第三章节会详细描述集群资源的检查检测。

Looksalive检查:WSFC检查活跃结点的SQL Server服务(Service Name 是 MSSQLServer)是否处于“启动状态”,根据SQL Server Availability Group资源的Advance Polices 选项卡中的设置,这个检查默认每5s做一次;

3,可用性副本之间的短线连接状态

图片 16

Isalive检查:WSFC连接活跃结点,并在活跃结点中执行TSQL查询语句(select @@ServerName),如果活跃结点返回查询的结果,那么Isalive检查成功;如果活跃结点的SQL Server实例连接不上,或没有返回查询结果,那么Isalive检查失败,根据SQL Server Availability Group资源的Advance Polices选项卡中的设置,这个检查默认每30s做一次。

”DISCONNECTED“连接状态:AlwaysOn可用性组之间有一个会话超时机制,默认值10s。主副本和辅助副本之间,按固定的时间间隔相互发送ping,在会话超时时间内,如果主副本收到辅助副本的ping命令,就说明副本之间的连接正常;一旦某个辅助副本因为故障而不能响应,产生会话超时,主副本将该辅助副本的连接设置为”DISCONNECTED“连接状态,即使使用同步提交模式,主副本的事务也不需要等待该副本的响应就可以提交。

5,切换到Properties Tab,查看和配置资源的私有属性

每执行6次Looksalive检查,就会执行一次Isalive检查,WSFC之所以需要对SQL Server 可用性组执行Isalive检查,是因为即使SQL Server 服务处于正在运行(Running)状态,也不能说明SQL Server 可以响应应用程序的请求,有时,可能整个SQL Server实例已经挂起,但是SQL Server服务的状态还是Running,所以需要Isalive 检查深入检查SQL Server的状态。此外,一旦looksalive检查失败,WSFC就会立即执行Isalive检查。

4,辅助数据库的”NOT SYNCHRONIZING“状态

HealthCheckTimeout属性:健康检测的超时时间,默认设置是30000ms,这就是说,WSFC在认定SQL Server 可用性组资源出现故障之前,需要等待诊断存储过程(sp_server_diagnostics)返回诊断信息的最长时间间隔 ;

如果Isalive检查失败,WSFC会根据设置,重试3~5次Isalive检查。如果这些检查都失败了,WSFC就根据Polices选项卡中的设置进行故障转移,由集群仲裁选举出新的主副本(Primary Replica),Listener将SQL Server实例名和IP地址指向集群中新的主副本,由其该结点为应用程序继续提供服务,切换的过程是透明的。根据故障转移模式的不同,分为自动故障转移,手动故障转移和强制故障转移,详细信息请阅读《部署AlwaysOn第二步:配置AlwaysOn,创建可用性组》。

无论使用什么可用性模式,如果一个事务在辅助数据库上重做失败,就会导致辅助副本进入”NOT SYNCHRONIZING“状态,即使处于同步提交模式,主副本的事务也不需要等待该副本的响应就可以提交。

诊断存储过程对系统进行诊断的时间间隔的公式是diagnostics_internal=max(5s, HealthCheckTimeout/3),这就是说,sp_server_diagnostics的查询时间间隔是HealthCheckTimeout/3,但不会少于5秒。WSFC会持续收到诊断存储过程返回的结果,如果诊断存储过程在diagnostics_internal时间范围内没有返回结果,就会产生超时错误,WSFC开始0到2次等待,如果在HealthCheckTimeout属性规定的时间范围内,诊断存储过程都没有返回结果,那么WSFC判定健康检查失败,该资源出现故障。也就是说,WSFC最多等待3次诊断存储过程(sp_server_diagnostics)超时未返回,才会判定资源出现故障。

参考文档:

如果用户想中断数据库的数据同步,而不想影响可用性组中的其他数据库,可以通过在SSMS中选择Suspend Data Movement来手动挂机,挂起之后,该数据库在各个可用性副本上的状态都会变成”NOT SYNCHRONIZING“状态。

FailureConditionLevel属性:设置资源出现故障的级别,从0到5共6个级别,默认值是3。对于级别1~5,每个级别除了当前级别的条件外,还包括之前级别的所有条件,这意味着级别越高,发生故障转移或重新启动的概率就越大。级别0表示无论发生任何故障,WSFC都不会自动转移或重新启动。

《SQL Server 2012 实施与管理实战指南》第三章 PDF下载见 http://www.linuxidc.com/Linux/2016-01/127450.htm

四,AlwaysOn的故障转移

在默认的FailureConditionLevel=3设置下,WSFC连接到可用性主副本上的SQL Server实例,并执行存储过程 sp_server_diagnostics获得可用性组的诊断信息,藉此评估可用组的健康状况。WSFC将存储过程 sp_server_diagnostics的评估结果和FailureConditionLevel属性值相比较,如果满足条件,那么WSFC判定当前的主副本出现故障,并将可用性组切换到新的可用性副本上;

本文永久更新链接地址:http://www.linuxidc.com/Linux/2017-01/139842.htm

当WSFC触发故障转移之后,一个辅助副本被选择成为新的主副本角色,该副本上的SQL Server实例对可用性数据库执行恢复操作,使其成为新的主数据库;在故障转移完成之后,如果原先的主副本还可用,那么它就成为辅助副本,它上面的数据库就成为了辅助数据库。

图片 17

图片 18

但AlwaysOn发现故障之后,是否立即出发故障转移呢?这取决于可用性副本的可用性模式和故障转移模式,如图:

6,故障检测存储过程(sp_server_diagnostics)

图片 19

系统存储过程 sys.sp_server_diagnostics 用于诊断系统的健康状态,发现潜在的故障,该SP返回的诊断信息对于WSFC判断系统是否执行故障转移是至关重要的,该存储过程只有一个参数:重复间隔的秒数,返回两个重要的字段:

只有主副本和转移的目标副本都配置为”同步提交模式 自动故障转移“模式时,才能实现两个可用性副本之间的自动故障转移。在三种故障转移模式中,只有强制故障转移可能丢失数据。自动故障转移和手动故障转移,都必须配置在同步提交模式下,必须数据库都处于SYNCHRONIZED状态。对于异步提交模式的辅助副本,无论数据是否已经达到同步,都只会处于SYNCHRONIZING状态,只能支持强制故障转移。

  • 字段State:表示组件的健康状态,可能值是:0(Unknown),1(clean),2(warning),3(error)
  • 字段component_name:表示组件的类型,可能类型是system,resource,query_processing,io_subsystem,events,availability group;

    sp_server_diagnostics [@repeat_interval =] 'repeat_interval_in_seconds'

五,创建可用性组

诊断信息和FailureConditionLevel的关系是:

1,在创建AG之前,配置SQL Server实例启用AlwaysOn

  • 当FailureConditionLevel属性值为3,如果诊断结果返回“系统错误”,表示需要进行故障转移或重新启动;
  • 当FailureConditionLevel属性值为4,如果诊断结果返回“资源错误”或“系统错误”,表示需要进行故障转移或重新启动;
  • 当FailureConditionLevel属性值为5,如果诊断结果返回“query_processing错误”,“资源错误”或“系统错误”,表示需要进行故障转移或重新启动;

在SQL Server配置管理器(SQL Server Configuration Manager)中打开SQL Server 实例的属性,输入Windows 故障转移集群的名称,并勾选“Enable AlwaysOn Availabilitty Groups”选项启用AlwaysOn 可用性组,在所有可用性副本上都启用SQL Server实例的AlwaysOn 可用性组。

故障检测存储过程(sp_server_diagnostics)返回的组件和可能出现的状态之间的关系如下图:

图片 20

图片 21

2,使用SSMS连接任意主副本的SQL Server实例,打开新建AG向导(New Availability Group Wizard)

可以看到,只有system,resource和query_processing这三个组件会出现“Error”的运行状态,用于和FailureConditionLevel属性值比较,用作故障转移的条件;而 io_subsystem 的状态只能是Clean或Warning,Events 的状态只能是Unknowns。用户可以手动执行该存储过程,查看服务器诊断的结果:

连接到主副本,是因为该副本上拥有所有的可用性数据库,如果所有的可用性副本上都有相同的数据库副本,那么可以连接任意一个副本。

EXEC sys.sp_server_diagnostics

图片 22

三,集群资源的健康检测

3,指定AG的名字,勾选“Database Level Health Detection”选项

集群中的每个资源都有一个资源类型,WSFC根据不同类型的资源,使用不同的方式进行Isalive和Looksalive检查,一般会把SQL Server Availability Group资源类型配置成“If resource fails, attempt restart on current node” 和 “If restart is unsuccessufll, fail over all resources in this service or application”模式,即在资源的Policies 选项卡中勾选相应的选项:

图片 23

Looksalive检查:WSFC检查活跃结点的SQL Server服务(Service Name 是 MSSQLServer)是否处于“启动状态”,根据SQL Server Availability Group资源的Advance Polices 选项卡中的设置,这个检查默认每5s做一次;

4,选择可用性数据

Isalive检查:WSFC连接活跃结点,并在活跃结点中执行TSQL查询语句(select @@ServerName),如果活跃结点返回查询的结果,那么Isalive检查成功;如果活跃结点的SQL Server实例连接不上,或没有返回查询结果,那么Isalive检查失败,根据SQL Server Availability Group资源的Advance Polices选项卡中的设置,这个检查默认每30s做一次。

从数据库列表中需要添加到可用性组中的数据,这些数据库将成为一个整体一起发生故障转移,本例勾选Test_DW。

每执行6次Looksalive检查,就会执行一次Isalive检查,WSFC之所以需要对SQL Server 可用性组执行Isalive检查,是因为即使SQL Server 服务处于正在运行(Running)状态,也不能说明SQL Server 可以响应应用程序的请求,有时,可能整个SQL Server实例已经挂起,但是SQL Server服务的状态还是Running,所以需要Isalive 检查深入检查SQL Server的状态。此外,一旦looksalive检查失败,WSFC就会立即执行Isalive检查。

添加到可用性组中的数据库必须满足一定的要求:

如果Isalive检查失败,WSFC会根据设置,重试3~5次Isalive检查。如果这些检查都失败了,WSFC就根据Polices选项卡中的设置进行故障转移,由集群仲裁选举出新的主副本(Primary Replica),Listener将SQL Server实例名和IP地址指向集群中新的主副本,由其该结点为应用程序继续提供服务,切换的过程是透明的。根据故障转移模式的不同,分为自动故障转移,手动故障转移和强制故障转移,详细信息请阅读《部署AlwaysOn第二步:配置AlwaysOn,创建可用性组》。

  • 数据库可以读写;
  • 数据库的恢复模式是FULL;
  • 数据库已经做过完整备份;

四,资源组的故障转移

图片 24

故障转移完成之后,故障转移的目标辅助副本转换成为主副本,其数据库转换成主数据库,新的主副本重做已经固化的事务日志,回滚尚未提交的事务,使主数据库恢复到原主副本发生故障时的事务一致性的状态;如果原先的主副本从故障中恢复而重新运行,它会发现集群中已经存在新的主副本,于是它就把自己转换为辅助副本,其数据库转为辅助数据。当心的辅助数据库连接上主数据库之后,辅助数据库就开始进行同步操作,执行日志的固化和重做。

5,添加可用性副本

1,自动故障转移

使用“Add Replica”添加可用性副本,在Availability Replicas列表中,能够查看各个可用性副本的配置:

在主副本出现故障之后,AlwaysOn迅速将资源组转移到其他辅助副本,使数据库再次变为可用,要发生自动故障转移,必须满足:

  • Server Instance:副本的实例名称
  • Initial Role :是副本初始角色,Primary是主副本,Secondary是辅助副本;
  • 勾选“Automatic Failover” :副本的故障转移模式是自动故障转移;
  • 勾选“Synchronous Commit”:副本的可用性模式是同步提交模式;
  • “Readable Secondary”:可读的辅助副本,主数据库是可读写的,辅助数据库可以设置为可读的;
  • 当前主副本和一个辅助副本都设置为同步提交模式和自动故障转移模式;
  • 辅助副本必须和主副本同步,即辅助副本处于SYNCHRONIZED状态;
  • 主副本变得不可用,此时将发生自动故障转移;

图片 25

2,手动故障转移

6,创建Listener

当主副本和辅助副本可用,并且辅助数据库处于SYNCHRONIZED状态时,可以执行手动故障转移,但是,在手动转移的过程中,如果主副本停止运行,那么辅助副本将进入“RESOLVING”角色,此时,该副本既不是辅助副本,也不是主副本,但可以执行强制故障转移把辅助副本升级为主副本,但是,可能会丢失数据。

创建一个可用性组的侦听器,实际上是虚拟的服务器,

通过故障转移集群管理器(Failover Cluster Manager),能够手动执行资源组的转移操作,但是,建议始终通过SSMS执行任意模式的故障转移操作,能够避免操作错误和数据丢失。

  • Listener DNS Name:网络名,命名为TestAGListener;
  • Port:推荐使用默认端口1433;
  • Network Mode:IP地址的分配方式,建议使用Static IP,本例使用DHCP;
  • Subnet:子网,系统自动设置;

3,强制故障转移

图片 26

一旦执行强制故障转移,主副本尚未发送到原来的辅助副本上的事务日志都会丢失,这意味着,新的主数据库可能会缺少一些最近提交的数据更新,在强制故障转移之后,剩余的辅助副本上的辅助数据库都将处于挂起状态,要重新恢复辅助副本的配置,必须以某个副本上的数据为基础,重新配置可用性组。

7,选择如何在辅助副本上初始化AG中的数据

五,监控AlwaysOn的健康状态

FULL:向导自动对主数据库做完整备份和日志备份,并将备份文件存放在共享目录中,其他副本通过共享目录获得数据库的备份,并在各自的SQL Server实例上还原数据库。通过FULL初始化方式,必须确保主副本上的存储主数据库文件的路径在辅助副本上也存在,即数据库文件的存储路径一致。

AlwaysOn的健康状态可以从故障转移集群管理器(Failover Cluster Manager)和SSMS来监控,建议通过SSMS来手动故障转移和监控,配置故障转移集群控制器来对AlwaysOn的异常进行故障排除。

Join Only:如果已经手动在各个辅助副本上还原了数据库,使用该选项,将各个辅助副本直接加入到可用性组中。

打开SSMS,连接到主副本(Primary Replica)上,点击“AlwaysOn High Availability”能够看到与该SQL Server 实例相关联的可用性组(Availability Group),右击可用性组,打开Dashboard,能够查看可用性组的详细信息,并对可用性组执行手动故障转移操作。

Skip Initial data sync:跳过该步骤,用户需要手动在主副本上对数据库做完整备份,并还原到所有的辅助副本,然后通过SSMS将数据库添加到可用性组中。

图片 27

推荐将主数据库和辅助数据库的文件路径保持一致。

 

 图片 28

参考文档:

8,成功创建可用性组

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

执行后续的Validation和Summary之后,向导开始创建可用性组,在创建完成之后,使用SSMS打开“AlwaysOn High Availability”,能够看到创建成功的可用性组:“TestAG”,括号中的Primary表示当前的可用性副本是主副本(Primary Replica)。 

sp_server_diagnostics (Transact-SQL).aspx)

图片 29

到此,AlwaysOn部署完成,可以通过SSMS连接Listener,登录Primary Replica上的 SQL Server 实例。

 

参考文档:

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

虚拟化IDC的高可用和高可靠性解决方案 

从0开始搭建SQL Server AlwaysOn 第三篇(配置AlwaysOn)

AlwaysOn Failover Cluster Instances (SQL Server).aspx)

编辑:操作系统 本文来源:WSFC的故障转移是以资源组为单位的,集群的每个

关键词: 澳门新濠3559