创建可用性组,Alwayson概念总结

一、alwayson概念

“可用性组” 针对一组离散的用户数据库(称为“可用性数据库”
,它们共同实现故障转移)支持故障转移环境。
一个可用性组支持一组主数据库以及一至八组对应的辅助数据库(包括一个主副本和两个同步提交辅助副本)。
辅助数据库不是备份,应继续定期备份您的数据库及其事务日志。

每组可用性数据库都由一个“可用性副本” 承载。
有两种类型的可用性副本:一个“主副本” 和一到四个“辅助副本”。
它承载主数据库和一至八个“辅助副本”
,其中每个副本承载一组辅助数据库,并用作可用性组的潜在故障转移目标。
可用性组在可用性副本级别进行故障转移。
可用性副本仅在数据库级别提供冗余 - 针对一个可用性组中的该组数据库。
故障转移不是由诸如因数据文件丢失或事务日志损坏而使数据库成为可疑数据库等数据库问题导致的。

主副本使主数据库可用于客户端的读写连接。 此外,它在称为“数据同步”
的过程中使用,在数据库级别进行同步。
主副本将每个主数据库的事务日志记录发送到每个辅助数据库。
每个次要副本缓存事务日志记录(“硬化”日志),然后将它们应用到相应的辅助数据库。
主数据库与每个连接的辅助数据库独立进行数据同步。
因此,一个辅助数据库可以挂起或失败而不会影响其他辅助数据库,一个主数据库可以挂起或失败而不会影响其他主数据库。

或者,您可以配置一个或多个辅助副本以支持对辅助数据库进行只读访问,并且可以将任何辅助副本配置为允许对辅助数据库进行备份。

部署 Always On 可用性组 需要一个 Windows Server 故障转移群集 (WSFC)
群集。 给定可用性组的每个可用性副本必须位于相同 WSFC 群集的不同节点上。
唯一的例外是在迁移到另一个 WSFC
群集时,此时一个可用性组可能会暂时跨两个群集。

为您创建的每个可用性组创建一个 WSFC 资源组。 WSFC
群集将监视此资源组,以便评估主副本的运行状况。 针对 Always On 可用性组
的仲裁基于 WSFC
群集中的所有节点,而与某一给定群集节点是否承载任何可用性副本无关。
与数据库镜像相反,在 Always On 可用性组中没有见证服务器角色。

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

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

二、可用性模式

可用性模式是每个可用性副本的一个属性;可用性模式确定主副本是否需要等待辅助副本将事务日志写入到磁盘。

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

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

1.异步提交模式

异步提交模式是一种灾难恢复解决方案,适合于可用性副本的分布距离较远的情况。
如果每个辅助副本都在异步提交模式下运行,则主副本不会等待任何辅助副本强制写入日志,
而会在将日志记录写入本地日志文件后,立即将事务确认发送到客户端。
主副本使用与针对异步提交模式配置的辅助副本相关的最小事务滞后运行。

在“异步提交模式”下,辅助副本永远不会与主副本同步。
虽然给定的辅助数据库可能会赶上对应的主数据库,但任何辅助数据库在任何时点都可能会落后。
对于主副本和辅助副本相隔很远而且您不希望小错误影响主副本的灾难恢复方案的情况,或性能比同步数据保护更重要的情况,异步提交模式将会很有用。
而且,由于主副本不会等待来自辅助副本的确认,因而辅助副本上的问题从不会影响主副本。

异步提交辅助副本会尝试与接收自主副本的日志记录保持一致。
但异步提交辅助数据库往往会保持未同步状态,并且可能稍微滞后于相应的主数据库。通常,异步提交辅助数据库和相应的主数据库之间的这个时间差会很小。但是,如果承载辅助副本的服务器的工作负荷过高或网络速度很慢,则这个时间差会变得较大。

异步提交模式所支持的唯一故障转移形式为强制故障转移(可能造成数据丢失)。
强制故障转移是一种最后手段,仅可用于当前主要副本长时间保持不可用状态并且主数据库的即时可用性比可能丢失数据的风险更为重要的情况。故障转移目标必须是其角色处于
SECONDARY 或 RESOLVING 状态的副本。
故障转移目标将转换为主角色,并且其数据库副本将成为主数据库。
任何剩余的辅助数据库以及变得可用后的以前的主数据库都将被挂起,直到您手动单独恢复它们。
在异步提交模式下,原始主副本尚未发送到以前的辅助副本的任何事务日志都将丢失。
这意味着,某些或全部新的主数据库可能会缺少最近提交的事务

一,AlwaysOn的基本架构

一,AlwaysOn的基本架构

2.同步提交模式

同步提交模式相对于性能而言更强调高可用性,为此付出的代价是事务滞后时间增加。
在同步提交模式下,事务将一直等到辅助副本已将日志强制写入到磁盘中才会向客户端发送事务确认。

在同步提交可用性模式下,副本联接到某个可用性组后,辅助数据库就会与对应的主数据库求得一致并进入
SYNCHRONIZED(已同步)状态。 只要一直在进行数据同步,辅助数据库就会保持
SYNCHRONIZED 状态。
这可确保对主数据库提交的每个事务也应用到对应的辅助数据库。在同步辅助副本上的每个辅助数据库之后,辅助副本的同步运行状态总体上将为
HEALTHY。

注意:

1.
如果为当前主副本配置了异步提交可用性模式,那么对所有的辅助副本都采集异步方式提交事务,不管这些副本各自的可用性模式,所以要保证同步提交模式那么主副本和辅助副本都需要配置同步提交模式。

2.如果主副本与某一同步辅助会话超时,暂时将该辅助副本切换到异步提交模式。在该辅助副本重新与主副本连接后,它们将恢复同步提交模式。

1,了解AlwaysOn的关键特性

1,了解AlwaysOn的关键特性

三、故障转移模式

可用性副本的主角色和辅助角色在称为“故障转移” 的过程中通常是可互换的。
存在三种故障转移形式:自动故障转移(无数据丢失)、计划的手动故障转移(无数据丢失)和强制手动故障转移(可能丢失数据)。最后一种形式通常称为“强制故障转移”

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

仅在以下条件下才发生自动故障转移:

  • 存在自动故障转移集。
    此自动故障转移集由主要副本和次要副本(自动故障转移目标)构成,主要副本和次要副本都配置为同步提交模式并且设置为自动故障转移。如果主要副本设置为手动故障转移,即使次要副本设置为自动故障转移,也无法发生自动故障转移
  • 自动故障转移目标具有正常运行的同步状态(这指示故障转移目标上的每个辅助数据库都与其相应的主数据库同步)。
  • Windows Server 故障转移群集 (WSFC) 群集具有仲裁。
  • 主副本已变得不可用,并且由灵活的故障转移策略定义的故障转移条件级别已得到满足。

注意:

1.在数据库级别,诸如因数据文件丢失而使数据库成为可疑数据库、删除数据库或事务日志损坏之类的数据库问题不会导致可用性组进行故障转移

  1. AlwaysOn
    可用性组监视自动故障转移集中两个副本的运行状况。
    如果任一副本失败,则该可用性组的运行状况状态将设置为“严重”。
    如果辅助副本失败,则自动故障转移将不可行,因为自动故障转移目标不可用。
    如果主副本失败,则可用性组将故障转移到辅助副本。
    在之前的主副本进入联机状态之前,将不存在任何自动故障转移目标。
    在任一情况下,为了在连续出现失败这种近乎不可能发生的情况下确保可用性,我们建议您将其他辅助副本配置为自动故障转移目标。

3.要设置故障转移模式为“自动”的前提是可用性模式是“同步提交”。

4.如果主要副本设置为手动故障转移,即使次要副本设置为自动故障转移,也无法发生自动故障转移。

5.只能设置一个自动故障转移辅助副本

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

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

四、可读辅助副本

部署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)”。

部署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)”。

1.辅助角色支持的连接访问类型

1.无连接
不允许任何用户连接。 辅助数据库不可用于读访问。
这是辅助角色中的默认行为。

2.仅读意向连接
辅助数据库仅适用于其 Application
Intent
 连接属性设置为 ReadOnly 的连接(读意向连接)。

3.允许任何只读连接
辅助数据库全部可用于读访问连接。 此选项允许较低版本的客户端进行连接。

图片 1

图片 1

2.主角色支持的连接访问类型

1.允许所有连接
主数据库同时允许读写连接和只读连接。 这是主角色的默认行为。

2.仅允许读/写连接
当 Application
Intent
 连接属性设置为 ReadWrite 或未设置时,允许此连接。
不允许其 Application
Intent
 连接字符串关键字设置为 ReadOnly的连接。
仅允许读写连接可帮助防止您的客户错误地将读意向工作负荷连接到主副本。

注意:所有的限制只针对配置了可用性数据库,非可用性数据库不受这些连接的限制,配置读写分离至少得保证有两个可读副本,如果只有一个可读副本当可读副本变成了主副本之后会导致只读意向无副本可连接。

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

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

五、alwayson同步原理

1.任何一个SQL Server里都有个叫Log
Writer的线程,当任何一个SQL用户提交一个数据修改事务时,它会负责把记录本次修改的日志信息先记入一段内存中的日志缓冲区,然后再写入物理日志文件(日志固化),所以对于任何一个数据库,日志文件里都会有所有数据变化的记录。

2.对于配置为AlwaysOn主副本的数据库,SQL Server会为它建立一个叫Log
Scanner的工作线程,这个线程专门负责将日志记录从日志缓冲区或者日志文件里中读出,打包成日志块,发送给各个辅助副本。由于它的不间断工作,才使主副本上的数据变化,可以不断地向辅助副本上传播。

3.在辅助副本上,同样会有两个线程,完成相应的数据更新动作,它们是固化(Harden)和重做(Redo)。固化线程会将主副本Log
Scanner所发过来的日志块写入辅助副本的磁盘上的日志文件里(这个过程被称为”固化”)。

而重做线程,则负责从磁盘上读取日志块,将日志记录翻译成数据修改操作,在辅助副本的数据库上完成。当重做线程完成其工作以后,辅助副本上的数据库就会跟主副本一致了。AlwaysOn就是通过这种机制,保持副本之间的同步。重做线程每隔固定的时间点,会跟主副本通信,告知它自己的工作进度。主副本就能够知道两边数据的差距有多远。

这些线程在工作上各自独立,以达到更高的效率。Log
Scanner负责传送日志块,而无须等待Log
Writer完成日志固化;辅助副本完成日志固化以后就会发送消息到主副本,告知数据已经传递完毕,而无须等待重做完成。其设计目标,是尽可能地减少AlwaysOn所带来的额外操作对正常数据库操作的性能影响。

同步操作按下列方式维护:

  1. 从客户端收到事务后,主副本会将事务的日志写入事务日志,同时将该日志记录发送到辅助副本。
  2. 日志记录写入主数据库的事务日志后,事务将不能撤消,除非在此时故障转移到尚未收到该日志的辅助副本。主副本将等待来自同步提交辅助副本的确认。
  3. 辅助副本将强制写入日志(固化),并将确认消息返回给主副本。
  4. 收到来自辅助副本的确认后,主副本将完成提交处理并向客户端发送一条确认消息。

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

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

六、会话超时机制

由于软错误不能由服务器实例直接检测到,因此,软错误可能导致一个可用性副本无限期等待会话中另一个可用性副本的响应。
为了防止发生这种情况, Always On
可用性组实施了会话超时机制,此机制基于以下条件:所连接的可用性副本会在每个打开的连接上按固定间隔发送
ping。 在超时期限内收到 ping
指示连接仍是开放的且服务器实例正在通过此连接进行通信。 收到
ping后副本将重置此连接上的超时计数器。主副本和辅助副本相互 ping
以指示它们仍处于活动状态, 会话超时限制是用户可配置的副本属性,默认值为
10 秒。

如果在会话超时期限内没有收到来自另一个副本的ping,该连接将超时、连接将关闭;超时的副本进入
DISCONNECTED 状态。
即使为同步提交模式的副本,事务也将不等待该副本重新连接暂时将该辅助副本切换到异步提交模式。在该辅助副本重新与主副本连接后,它们将恢复同步提交模式。

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

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

总结

理解掌握这些概念对部署维护AlwaysOn集群非常的有帮助,可以结合测试对概念更深入的理解。

 

注意:
域服务器宕机了也不影响使用SQLServer身份验证连接副本或者监听器,Windows身份验证会受影响。所以只要不故障切换AD宕机了也不影响AlwaysOn群集的连接。这个功能减少了AlwaysON对AD的依赖,同时也减少建双域控的成本。

 

针对AlwaysON可用性组的先决条件和限制:

搭建和加入域参考:http://www.cnblogs.com/chenmh/p/4444168.html

搭建故障转移群集参考:http://www.cnblogs.com/chenmh/p/4479304.html

Alwayson搭建参考:http://www.cnblogs.com/chenmh/p/4484176.html

Alwayson配置两个节点加共享文件夹仲裁见证:http://www.cnblogs.com/chenmh/p/7156719.html

Alwayson读写分离参考:http://www.cnblogs.com/chenmh/p/7000236.html

 

备注:

    作者:pursuer.chen

    博客:http://www.cnblogs.com/chenmh

本站点所有随笔都是原创,欢迎大家转载;但转载时必须注明文章来源,且在文章开头明显处给明链接,否则保留追究责任的权利。

《欢迎交流讨论》

 

4,AG是集群的资源组

4,AG是集群的资源组

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

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

5,侦听器(Listener)

5,侦听器(Listener)

在故障转移集群管理器(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实例。

在故障转移集群管理器(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实例。

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

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

二,AlwaysOn的数据同步原理

二,AlwaysOn的数据同步原理

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

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

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

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

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

1,日志持久化

1,日志持久化

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

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

2,主副本的日志传输

2,主副本的日志传输

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

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

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

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

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

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

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

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

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

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

三,AlwaysOn的可用性模式

三,AlwaysOn的可用性模式

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

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

1,异步提交模式

1,异步提交模式

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

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

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

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

2,同步提交模式

2,同步提交模式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四,AlwaysOn的故障转移

四,AlwaysOn的故障转移

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

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

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

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

图片 3

图片 3

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

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

五,创建可用性组

五,创建可用性组

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

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

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

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

图片 5

图片 5

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

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

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

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

图片 7

图片 7

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

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

图片 9

图片 9

4,选择可用性数据

4,选择可用性数据

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

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

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

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

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

图片 11

图片 11

5,添加可用性副本

5,添加可用性副本

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

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

  • Server
    Instance
    :副本的实例名称
  • Initial
    Role
     :是副本初始角色,Primary是主副本,Secondary是辅助副本;
  • 勾选“Automatic Failover”
    :副本的故障转移模式是自动故障转移;
  • 勾选“Synchronous
    Commit”
    :副本的可用性模式是同步提交模式;
  • “Readable
    Secondary”
    :可读的辅助副本,主数据库是可读写的,辅助数据库可以设置为可读的;
  • Server
    Instance
    :副本的实例名称
  • Initial
    Role
     :是副本初始角色,Primary是主副本,Secondary是辅助副本;
  • 勾选“Automatic Failover”
    :副本的故障转移模式是自动故障转移;
  • 勾选“Synchronous
    Commit”
    :副本的可用性模式是同步提交模式;
  • “Readable
    Secondary”
    :可读的辅助副本,主数据库是可读写的,辅助数据库可以设置为可读的;

图片 13

图片 13

6,创建Listener

6,创建Listener

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

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

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

图片 15

图片 15

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

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

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

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

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

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

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

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

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

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

 图片 17

 图片 17

8,成功创建可用性组

8,成功创建可用性组

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

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

图片 19

图片 19

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

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

 

 

参考文档:

参考文档:

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

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

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

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

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

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

AlwaysOn Failover Cluster Instances (SQL
Server).aspx)

AlwaysOn Failover Cluster Instances (SQL
Server).aspx)