SQL 数据库集群及负载均衡部署

Windows Server故障转移集群&SQL Server数据库结合使用

一、故障转移群集原理

故障转移集群为整个SQL Server实例提供⾼可⽤性⽀持，这意味着在集群上某个节点的SQL Server实

例发⽣了硬件错误、操作系统错误等会故障转移到该集群上的其它节点。通过多个服务器（节点）共享

⼀个或多个磁盘来实现⾼可⽤性，故障转移集群在⽹络中出现的⽅式就像单台计算机⼀样，但是具有⾼

可⽤特性。

 

集群服务器设计的⽬的就是提⾼服务器性能，同时在出现故障时能及时进⾏故障迁移（将应⽤程序或服

务安装在发⽣故障时彼此能接管对⽅⼯作的多台服务器上，⼀台服务器接管发⽣故障服务器⼯作的过程

就称为“故障转移”），提⾼服务器的可⽤性。所以在集服务器设计之初，必须充分考虑故障迁移⽅案。

1.1、原理

1. 检测故障

要让备⽤服务器变成活动服务器，必须设法确定活动服务器是否不再正常⼯作。系统使⽤下列某个常规类型的⼼跳机制来做到这⼀点。◎发送信号。活动服务器以定义好的时间间隔将指定信号发送到备⽤服务器。如果备⽤服务器在某个时间间隔内未收到信号，则确定活动服务器发⽣故障并担任活动⻆⾊。◎接收信号。备⽤服务器向活动服务器发送请求。如果活动服务器没有响应，则备⽤服务器按特定次数重复发送此请求。如果活动服务器仍然没有响应，则备份服务器接管活动服务器的⼯作。以上发送和接收信号是通过专⽤通信通道发送的，以使⽹络拥塞和⼀般⽹络问题不会导致假的故障转移，这个专⽤通信通道通常被称为“⼼跳线”。

1. 同步状态

在集群服务器系统中，在正式接管活动服务器的⼯件前，⾸先要将备⽤服务器的状态与发⽣故障的服务器的状态进⾏同步，然后才能开始处理事务。主要有三种不同的同步⽅法。◎事务⽇志。在事务⽇志⽅法中，活动服务器将对其状态的所有更改记录到⽇志中。同步实⽤⼯具定期处理此⽇志，以更新备⽤服务器的状态，使其与活动服务器的⼀致。当活动服务器发⽣故障时，备⽤服务器必须使⽤此同步实⽤⼯具处理⾃上次更新以来事务⽇志中的任何添加内容。◎热备⽤。在热备⽤法中，将把活动服务器内部状态的更新⽴即复制到备⽤服务器。因为备⽤服务器的状态是活动服务器状态的克隆，所以备份服务器可以⽴即成为活动服务器，并开始处理事务。◎共享存储。在共享存储⽅法中，两台服务器都在共享存储设备（如存储区域⽹络或磁盘阵列）上记录其状态。这样，因为不需要进⾏状态同步，故障转移可以⽴即发⽣。这种同步⽅式所需的切换时间也较短，可⽤性也较⾼。

1. 确定活动服务器

对于指定一组应用程序，只存在一台活动服务器，这是极其重要的。

注意：由于故障转移集群是基于共享磁盘，因此会存在磁盘单点故障，因此需要在磁盘层⾯部署SAN复制等额外的保护措施。最常⻅的故障转移集群是双节点的故障转移集群，包括主主节点和主从节点。

缺点：辅助节点不可⽤，数据单点。

二、故障转移群集分类及特点

⽆论群集还是⾮群集SQL Server服务器，都是需要有以下基本组成部分才能提供数据服务：

1. SQL Server实例，也可以认为是SQL Server⼆进制可执⾏⽂件，它组成数据库管理系统运⾏的各个

服务，管理数据库数据和客户端的需求，执⾏操作等。不管是群集还是⾮群集这些实例都是安装在本地磁盘上，以提供服务，因此在安装SQL Server群集不仅在活动节点安装主SQL Server群集，还要在不同节点添加群集服务。

2. 系统和⽤户数据库，包含实实在在的数据，以及各个数据库单独的设置等；⾮群集下，数据存储在本地，被本地实例访问；群集情况下，数据库放在共享存储上，每个节点都有能⼒访问到（但任何时候只允许活动节点访问）；SQL Server实例通过挂载数据库来完成数据库管理。

3. 访问数据库还需要服务器⽹络名，或者IP地址。本地采⽤本地IP或者别名，群集访问虚拟名称或虚拟IP。

 

通过以上群集服务器的改变，SQL Server服务故障转移到另外⼀个节点前⾸先停⽌失败节点的SQL

Server服务，共享存储挂载到备节点，虚拟IP重新绑定到备节点的公共⽹卡接⼝，再启动备节点的SQLServer服务，备节点的服务读取共享存储数据，从⽽业务恢复。客户端只是通过虚拟名称或虚拟IP访问SQL Server服务，从⽽访问数据库资源。

三、数据库镜像基本原理

数据库镜像实际上是个软件解决⽅案，同样提供了数据库级别的保护，可提供⼏乎是瞬时的故障转

移，以提⾼数据库的可⽤性。数据库镜像可以⽤来维护相应⽣产数据库（称为“主体数据库”）的单个备

⽤数据库（或“镜像数据库”）。

因为镜像数据库⼀直处于还原状态，但并不会恢复数据库，因此⽆法直接访问镜像数据库。但是，

为了⽤于报表等只读的负载，可创建镜像数据库的数据库快照来间接地使⽤镜像数据库。数据库快照为

客户端提供了快照创建时对数据库中数据的只读访问。每个数据库镜像配置都涉及包含主体数据库

的“主体服务器”，并且还涉及包含镜像数据库的镜像服务器。镜像服务器不断地使镜像数据库随主体数

据库⼀起更新。

数据库镜像在⾼安全性模式下以同步操作运⾏，或在⾼性能模式下以异步操作运⾏。在⾼性能模式

下，事务不需要等待镜像服务器将⽇志写⼊磁盘便可提交，这样可最⼤程度地提⾼性能。在⾼安全性模

式下，已提交的事务将由伙伴双⽅提交，但会延⻓事务滞后时间。数据库镜像的最简单配置仅涉及主体

服务器和镜像服务器。在该配置中，如果主体服务器丢失，则该镜像服务器可以⽤作备⽤服务器，但可

能会造成数据丢失。⾼安全性模式⽀持具有⾃动故障转移功能的备⽤配置⾼安全性模式。这种配置涉及

到称为“⻅证服务器”的第三⽅服务器实例，它能够使镜像服务器⽤作热备份服务器。从主体数据库⾄镜

像数据库的故障转移通常要⽤⼏秒钟的时间。注意：只有在与主体服务器断开连接之后，镜像服务器仍

和⻅证服务器保持相互连接时，镜像服务器才启动⾃动故障转移。

 

总结：

主体数据库：接受客户端连接；允许更新数据库。

镜像数据库：客户端不能连接；将主体的更新反映在⾃⼰的数据库上；可和主体转换⻆⾊成为新的主体。

⻅证（可选）：监视主体和镜像；⾃动故障转移，⽆⻅证只能⼿动转移。

数据库镜像可⽤于做暖备份和热备份。

3.1、数据库镜像管理及特点

特点：

1. 带⻅证时⾃动故障转移、⽆数据损失，宕机时间短；
2. 数据库级可⽤性技术；
3. 有⼀个副本，且副本不能被读写；
4. 可⽤于异地容灾；
5. 数据库恢复模式必须是完整模式；
6. 不需要特殊硬件；
7. 有性能损失；⾼性能时⽆性能损失，异步；
8. 对应⽤不完全透明，切换时应该程序需要做对应切换。

四、日志传送基本原理

⽇志传送是⼀种事务⽇志备份传送技术。⽇志传送允许从⼀个数据库（即主服务器上的主数据库）向多

个在另外的服务器（即辅助服务器）上的数据库（即辅助数据库）⾃动发送事务⽇志备份。在辅助服务

器上，这些事务⽇志备份被恢复到辅助数据库中，并和主数据库保持同步。⼀个可选的三级服务器（即

监视服务器），记录事务⽇志备份、复制和恢复操作的历史和状态，以及这些操作依照计划不能发⽣时

报警。

在⽇志传送中可配置⼀个主服务器实例向多台辅助服务器实例传送事务⽇志，在⽇志传送应⽤场景中可

配置带监视服务器实例，或不带监视服务器实例。下图显示了具有主服务器实例、三个辅助服务器实例

和⼀个监视服务器实例的⽇志传送配置。此图阐释了备份作业、复制作业以及还原作业所执⾏步骤：

 

⽇志传送由四项操作组成：

1.在主服务器实例中备份事务⽇志。

2.将事务⽇志备份⽂件复制到辅助服务器实例。

3.在辅助服务器实例中还原⽇志备份。

4.主服务器实例和辅助服务器实例将⽇志传送状态和历史记录发送给监视服务器。（可选）

⽇志传送到多个辅助服务器实例，在这种情况下，将针对每个辅助服务器实例重复执⾏操作 2 和操作3。

⽇志传送配置不会⾃动从主服务器故障转移到辅助服务器。如果主数据库变为不可⽤，可⼿动使任

意辅助数据库联机。

4.1、主服务器和主数据库

⽇志传送配置中的主服务器是作为⽣产服务器的 SQL Server 数据库引擎实例。主数据库是主服务器上

希望备份到其他服务器的数据库。所有⽇志传送配置管理都是可以在主数据库中通过 SQL Server

Management Studio 进⾏的执⾏的。

提示：

主数据库必须使⽤完整恢复模式或⼤容量⽇志恢复模式，将数据库切换为简单恢复模式会导致⽇志传送

停⽌⼯作。

4.2、辅助服务器和辅助数据库

⽇志传送配置中的辅助服务器是您想要在其中保留主数据库备⽤副本的服务器。⼀台辅助服务器可以包

含多台不同主服务器中数据库的备份副本。例如，某个部⻔可能有五台服务器，每台服务器都运⾏关键

数据库系统。在这种情况下，可以只使⽤⼀台辅助服务器，⽽不必使⽤五台单独的辅助服务器。五个主

系统上的备份都可以加载到这个备份系统中，从⽽减少所需的资源数量并节省开⽀。不太可能出现多个

主系统同时发⽣故障的情况。另外，为了应对多个主系统同时不可⽤的罕⻅情况，辅助服务器的规格可

以⽐各主服务器⾼。

辅助数据库必须通过还原主数据库的完整备份的⽅法进⾏初始化。还原时可以使⽤ NORECOVERY 或

STANDBY 选项，或者通过 SQL Server Management Studio 实现。

4.3、监视服务器

监视服务器是可选的，它可以跟踪⽇志传送的所有细节，包括：

1.主数据库中事务⽇志最近⼀次备份的时间。

2.辅助服务器最近⼀次复制和还原备份⽂件的时间。

3.有关任何备份失败警报的信息。

监视服务器应独⽴于主服务器和辅助服务器，以避免由于主服务器或辅助服务器的丢失⽽丢失关键信息

和中断监视。⼀台监视服务器可以监视多个⽇志传送配置。在这种情况下，使⽤该监视服务器的所有⽇

志传送配置将共享⼀个警报作业。

总结：

1. 属于温备⾼可⽤技术，不带⾃动故障转移；
2. 可能有少量数据丢失；
3. 可以有多个副本，且副本可只读。可应用于读写分离（⾮实时只读应⽤），分担主服务器压⼒；
4. 可⽤于异地容灾；
5. 不需要特殊硬件；
6. 对应⽤不完全透明，切换时应用程序需要做对应切换。

五、数据库复制基本原理

5.1、SQL Server复制的概念

复制是将⼀组数据从⼀个数据源拷⻉到多个数据源的技术，是将⼀份数据发布到多个存储站点上的

有效⽅式。使⽤复制技术，⽤户可以将⼀份数据发布到多台服务器上，从⽽使不同的服务器⽤户都可以

在权限的许可的范围内共享这份数据。SQL Server复制技术可以确保分布在不同地点的数据⾃动同步更

新，从⽽保证数据的⼀致性。

SQL复制的基本元素包括：出版服务器、订阅服务器、分发服务器、出版物、⽂章。

SQL复制的工作原理：

SQL Server 主要采⽤出版物、订阅的⽅式来处理复制。源数据所在的服务器是出版服务器，负责

发表数据。出版服务器把要发表的数据的所有改变情况的拷⻉复制到分发服务器，分发服务器包含有⼀

个分发数据库，可接收数据的所有改变，并保存这些改变，再把这些改变分发给订阅服务器。

 

发布服务器：

⽤于发表数据（出版社）

出版物：⼀个或多个⽂章的集合，是订阅的最⼩单元；

⽂章：⼀张表或表的⼀部分。

分发服务器：

⽤于传递数据；

分发数据库Distribution（分发时⾃动⽣成）：存储所有类型复制的元数据和历史记录，存储事务复

制的事务。

快照⽂件夹：存放⽂章的初始化数据，存放快照复制的数据。

订阅服务器：

⽤于接收数据（读者）；

两种⼯作⽅式：推， 被动订阅，由分发服务器发起同步；拉， 请求订阅 由订阅服务器发起同步。

总结：⾮⾼可⽤功能，常⽤于读写分离，维护成本较⾼。

六、Always on基本概述

AlwaysOn可⽤性组是SQL Server 2012之后推出的新功能。同样提供了数据库级别的保护。它取数据库

镜像和故障转移集群之⻓，使得业务上有关联的数据库作为⼀个可⽤性组共同故障转移，该功能还拓展

了数据库镜像只能1对1的限制，可以作为暖备份。此外，辅助副本还可以被配置为只读，并可⽤于承担备份的负载。

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

创建的每个可⽤性组创建⼀个 WSFC 资源组。 WSFC 群集将监视此资源组，以便评估主副本的运⾏状况。 针对 Always On 可⽤性组 的仲裁基于 WSFC 群集中的所有节点，⽽与某⼀群集节点是否承载任何可⽤性副本⽆关。 与数据库镜像相反，在 Always On 可⽤性组中没有⻅证服务器⻆⾊，侦听器可⽤于本地或异地容灾和⾼可⽤；可⽤于负载均衡。

Always On数据同步原理图：

 

微软较综合的⽅案，可回避故障转移群集、镜像、复制、⽇志传送⼏种技术的缺点。 因此，数据库镜

像在SQL Server 2012以后被标记为“过时”。

七、Always on系统架构

7.1、基础架构

AlwaysOn最多可以⽀持五个副本，但只有⼀个可⽤性副本上运⾏的数据库是处于可读写状态。这个可

读写的数据库被称为主数据库（PrimaryDatabase），同时这个可⽤性副本被称为主副本

（primaryreplica）。其余的副本都被称为辅助副本（secondaryreplica），辅助副本上的数据库可能

是不可访问的，或者是只能接受只读操作（取决于可⽤性组的配置），这些数据库被称为辅助数据库。

⼀但发⽣故障转移，任何⼀个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数

据变化发送到辅助副本，来实现副本间的数据库同步。

AlwaysOn可⽤性组与Windows故障转移群集之间的关系，在这个图中，Windows的故障转移群集使⽤

到了两个⼦⽹，在左边的⼦⽹⾥，有两个节点 ；右边的⼦⽹⾥有三个节点，其中最右边两个节点上创建

了⼀个SQL Server的群集实例，存放于共享存储；其他三个节点安装的是单机实例，存放于本地存储；

⼀共四个实例组成了⼀个AlwaysOn可⽤性组，其中⼀个主副本，其他的都是辅助副本。

 

侦听器就是⼀个虚拟的⽹络名称，可以通过这个虚拟⽹络名称访问可⽤性组，⽽不⽤关⼼连接的是哪⼀个节点，它会⾃动将请求转发到主节点，当主节点发⽣故障后，辅助节点会变为主节点，侦听器也会⾃动去侦听主节点。

7.2、基本对象

1. AlwaysOn可⽤性组

定义⾼可⽤性需求：数据库可⽤性副本，可⽤性模式，转移模式等。

1. 可⽤性副本

可⽤性组的⼀部分，运⾏数据库副本的实例。

1. 可⽤性数据库

可⽤性组的⼀部分，可以是⼀个常规数据库。

7.3、可用性模式

可⽤性模式是每个可⽤性副本的⼀个属性；可⽤性模式确定主副本是否需要等待辅助副本将事务⽇

志写⼊到磁盘。

1.同步提交模式

同步提交模式相对于性能⽽⾔更强调⾼可⽤性，为此付出的代价是事务滞后时间增加。 在同步提交模

式下，事务将⼀直等到辅助副本已将⽇志强制写⼊到磁盘中才会向客户端发送事务确认。

2.异步提交模式

异步提交模式是⼀种灾难恢复解决⽅案，适合于可⽤性副本的分布距离较远的情况。 如果每个辅助副

本都在异步提交模式下运⾏，则主副本不会等待任何辅助副本强制写⼊⽇志， ⽽会在将⽇志记录写⼊本

地⽇志⽂件后，⽴即将事务确认发送到客户端。 异步提交模式所⽀持的唯⼀故障转移形式为强制故障

转移（可能造成数据丢失）。

注意：

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

2.如果主副本与某⼀同步辅助会话超时，暂时将该辅助副本切换到异步提交模式。在该辅助副本重新与

主副本连接后，它们将恢复同步提交模式。

7.4、故障转移模式

可⽤性副本的主⻆⾊和辅助⻆⾊在称为“故障转移” 的过程中通常是可互换的。 存在三种故障转移形

式：⾃动故障转移（⽆数据丢失）、计划的⼿动故障转移（⽆数据丢失）和强制⼿动故障转移（可能丢

失数据）。最后⼀种形式通常称为“强制故障转移”。

1. 自动故障转移
2. 存在⾃动故障转移集， Windows Server 故障转移群集 (WSFC) 群集具有仲裁；
3. 辅助副本必须与主副本同步；
4. 当辅助副本故障主副本不受影响；
5. 当主副本故障，客户端连接被断开；
6. 辅助副本继续完成⽇志重做，完成后转为主副本；
7. 其它辅助副本连接新主副本继续同步数据；
8. 原主副本修改后⾃动变为辅助副本，从当前主副本同步。
9. 手动故障转移
10. 辅助副本必须与主副本同步；
11. 当辅助副本故障主副本不受影响；
12. 当主副本故障，辅助副本继续完成⽇志重做；
13. 故障转移时，选择同步模式的辅助副本作为主副本，数据⽆损失；
14. 故障转移后，其它辅助副本连接新主副本继续同步数据；
15. 原主副本修改后⾃动变为辅助副本，从当前主副本同步。
16. 强制故障转移
17. 辅助副本设置为异步提交模式；
18. 当辅助副本故障主副本不受影响；
19. 当主副本故障，辅助副本继续完成⽇志重做；
20. 故障转移时，需要确认，可能导致数据损失；
21. 故障转移后，其它辅助副本处于挂起状态，需要⼿动恢复，甚⾄可能需要重新配置可⽤性组。

注意：因为需要借助Windos群集实现监控和转移，所以AlwaysOn会受到⼀些限制：

⼀个可⽤性组中的所有可⽤性副本必须运⾏在单⼀的Windows群集上，跨不同Windows群集的SQL

Server实例不能配置成⼀个AlwaysOn可⽤性组。

⼀个可⽤性组的所有可⽤性副本必须运⾏在Windows群集的不同节点上。运⾏在同⼀个节点上的两个不

同实例不能⽤作同⼀个可⽤性组的副本。

如果某个可⽤性副本实例是⼀个SQL群集实例，那同⼀个SQL群集的其他⾮活跃节点上安装的任何其他

SQL实例都不能作为它的辅助副本。

⼀个数据库只能属于⼀个可⽤性组。