深度解析数据库高可用性AlwaysOn技术.docx

深度解析数据库高可用性AlwaysOn技术.docx

《深度解析数据库高可用性AlwaysOn技术.docx》由会员分享，可在线阅读，更多相关《深度解析数据库高可用性AlwaysOn技术.docx（16页珍藏版）》请在冰点文库上搜索。

深度解析数据库高可用性AlwaysOn技术

深度解析数据库高可用性：

AlwaysOn技术

为了实现企业核心业务系统的连续运行，保护关键数据免受计划内以及计划外停机的影

响，在SQLServer早期版本中就已经提供了一系列的高可用性解决技术，比如大家耳熟能详的故障转移群集、数据库镜像、日志传递、复制，此四种可高用性技术也有各自的优缺点。

正因为现有高可用性技术的不足，SQLServer2012中提出一种新的高可用性技术AlwaysOn,

它集现有高可用性技术的优点于一身，在介绍此技术之前，先对现有高可用性技术简单介绍。

SQLServer高可用技术简述

故障转移群集

故障转移群集又称为FailoverCluster。

此技术使用的共享存储技术，不涉及到底层

数据的同步问题，因此可以认为群集的最大好处就是性能较高。

正因为如此，存储将成为整

个群集技术中的单点故障。

在短短的半年内，笔者遇到因为存储单点故障而进行的群集故障操作已有四个，平均一个多月就要处理一个。

群集技术的另一个弊端就是某一个时间点只有

一个节点处于活动状态，其他节点处于闲置不可用状态，造成了硬件资源的浪费。

数据库镜像

数据库镜像又称为DatabaseMirror。

此技术可提供几乎是瞬时的故障转移，以提高数据库的可用性。

镜像基于单个数据库实现，数据库镜像会及时将主数据库的数据同步到镜像

数据库。

此技术的最大弊端在于镜像数据库处于不可读状态，无形中也造成了硬件资料的浪

费。

日志传送

日志传送又称为LogShipping。

同数据库镜像技术一样，日志传送是数据库级操作。

可以使用日志传送来维护单个生产数据库（称为“主数据库”）的一个或多个热备用数据库（称

为“辅助数据库”）。

此技术支持对辅助数据库在还原作业之间的间隔时间内的只读访问权限，可用做报表查询，以提高资源的利用率。

此技术一般用于远程的异步容灾，存在部分数

据丢失的可能性。

复制

复制又称为Replication。

此技术基于数据库对象级别，灵活性较高，可以很方便地将数据和数据库对象从一个数据库复制和分发到另一个数据库，然后在数据库之间进行同步以

保持一致性。

使用复制，可以在局域网和广域网、拨号连接、无线连接和Internet上将

数据分发到不同位置以及分发给远程或移动用户。

此技术的弊端在于，它不支持DDL命令。

如在源服务器中新建一个表对象，此对象是无法自动复制到目标服务器的。

AlwaysOn高可用性技术

AlwaysOn是SQLServer2012中提供的一种全新的高可用性技术，其集中了上述高可用性技术的优点，以确保企业无需增加成本和提高复杂度，即可实现最高级别的可用性和数

据保护。

可在数据中心内部以及跨数据中心实现数据冗余，快速地实现应用程序故障转移，保护现有硬件资源。

同时简化了其配置过程。

AlwaysOn可以实现服务器实例级和数据库级

配置高可用性，所对应的技术就是AlwaysOn故障转移群集实例和AlwaysOn可用性组。

AlwaysOn故障转移群集实例

一般来说，在单服务器情况下，当服务器上出现硬件或软件故障时，连接到该服务器的

应用程序或客户端将会停机。

在AlwaysOn故障转移群集实例环境中，SQLServer实例的高

可用性受到冗余节点的保护。

在群集环境中，一次只能有一个节点拥有群集的资源组。

在

出现故障（硬件故障、操作系统故障、应用程序或服务故障）或进行计划的升级时，该资源组的所有权就会转移至另一个群集节点。

此过程对于连接到SQLServer的客户端或应用程

序是透明的，可以最大限度地缩短出现故障时应用程序或客户端的停机时间。

因此AlwaysOn

故障转移群集实例必须由一组物理服务器节点构成，这些服务器节点推荐使用类似的硬件配

置以及相同的软件配置，如操作系统的版本、SQLServer版本、修补程序级别、组件以及

实例名称。

相同的配置是确保群集在节点间进行故障转移时能够正常运行的前提条件。

SQLServer2012在原有SQLServer故障转移群集的基础上功能得到了进一步的增强，支持跨越子网实现多站点群集，此技术一般用于两个或两个以上的数据中心，以同时提供本

地高可用性和远程的灾难恢复。

其中，每个故障转移群集节点都连接到其他子网或其他子网组。

这些子网可以处于同一位置中，也可以位于地理上分散的站点。

跨地理上分散的站点

进行群集有时又被称为扩展群集。

因为没有供所有节点都可以访问的共享存储，所以在多

个子网上的数据存储之间应该复制数据。

因此，多子网故障转移群集除了具备高可用性之外，

还提供了灾难恢复解决方案。

下面以图例说明：

在上图中共有两个数据中心并且处于不同子网，本地数据中心subnetl使用的IP地址

是10.168.0.10，当本地数据中心发生故障时，SQLServer服务会转移到远程数据中心，远

程数据中心subnet2所使用的是不同IP地址，为192.168.0.10来继续提供数据库服务，这

两个IP地址之间是OR的关系，也就是说这两个IP地址任意一个在线的话，虚拟网络名称

SQLCIus都可以正常的向客户端提供服务。

在此需要使用到存储级别的复制技术，将本地数据中心数据库中的数据文件及日志文件

复制到远程数据中心，当本地数据中心发生故障时，Windows群集检测到故障，远程数据中

心存储软件可以检测到复制失效，会将存储转换为读写状态，接下来Windows群集会将远程

站点可读写的存储设备挂接到远程的Cluster节点上，此时存储复制的方向就从远程数据中

心向本地数据中心复制。

也就是说，故障转移群集实例成功启动后，Windows群集服务将监

视基础群集的运行状况和SQLServer实例的运行状况。

SQLServer2012中允许群集服务

使用专用连接来轮询活动SQLServer实例，以便通过系统存储过程获取详细的组件诊断信息。

好处是，利用与SQLServer实例的专用连接，能够对组件诊断信息进行可靠轮询，即使在故障转移群集实例负荷较重时也是如此。

利用详细的组件诊断信息，可以配置更灵活的

故障转移策略，由此用户能选择哪些故障条件将触发故障转移以及哪些故障条件将不触发故障转移。

用户利用产生的诊断信息，还可以通过追溯方式更好地对自动故障转移进行故障排

除。

此诊断信息将存储到与SQLServer错误日志并置的日志文件中。

可以将这些日志文

件加载到日志文件查看器中以检查导致出现故障转移的组件状态，从而确定导致该故障转移

的原因。

AlwaysOn可用性组

AlwaysOn可用性组

AlwaysOn可用性组是SQLServer2012中提供的全新功能，确保了应用程序数据的可用性，实现零数据丢失。

AlwaysOn可用性组技术融合了数据库群集和数据库镜像的优点，此技术的一大好处是提供非共享存储，可以避免因为存储的单点故障而造成的整个可用性方

案失效。

AlwaysOn可用性组基于数据库（组）级别，是将一组用户数据库（可以是一个或多个）划到一个组中。

每组可用性数据库都由一个可用性副本承载。

可用性副本包括一个主副本和一

到四个辅助副本。

主副本用于承载主数据库，辅助副本则承载一组辅助数据库并作为可用性组的潜在故障转移目标。

主副本使主数据库可用于客户端的读写连接，实现对数据库的更

改操作。

同时在数据库级别进行同步。

主副本将每个主数据库的事务日志记录发送到每个

辅助数据库。

每个辅助副本缓存事务日志记录，然后将它们还原到相应的辅助数据库。

主

数据库与每个连接的辅助数据库独立进行数据同步。

因此，一个辅助数据库可以挂起或失

败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。

此外，用户可以借助辅助数据库来实现近实时的报表查询，将查询的负载分担到只读副

本。

相对于数据库群集及镜像来说，可以更好的利用硬件资源，从而提高IT效率并降低成

本。

下面看一下AlwaysOn可用性组架构，如下图所示：

WindowsServerfailoverClusterlr»g（WSFC）Cluster

部署AlwaysOn可用性组需要一个WindowsServer故障转移群集（WSFC）群集。

给定可用性组的每个可用性副本必须位于相同WSFC群集的不同节点上。

部署AlwaysOn可用

性组时，系统会为每个可用性组创建一个WSFC资源组。

WSFC群集将监视此资源组，判断

可用性组的仲裁基于WSFC群集中的所有节点，而与某一给定群集节点是否承载任何可用性副本无关。

用户可以通过创建一个可用性组侦听器来提供到给定可用性组的主副本的客户端连接。

“可用性组侦听器”采用DNS名称的方式连接给定可用性组的资源，以便将客户端连接定向

到相应的可用性副本。

对于每个可用性副本，AlwaysOn所支持的事务提交模式分为同步提交模式或异步提交模式。

在异步提交模式下，主副本无需等待确认异步提交辅助副本已强制写入日志，便可提

交事务。

异步提交模式可最大限度地减少辅助数据库上的事务滞后时间，但允许它们滞后于主数据库，因此可能会导致某些数据丢失。

此可用性模式是一种灾难恢复解决方案，适合

于可用性副本的分布距离较远的情况；所谓同步提交模式是指在提交事务之前，同步提交主副本要等待同步提交辅助副本确认它已完成强制写入日志。

同步提交模式可确保在给定的

辅助数据库与主数据库同步时，充分保护已提交的事务。

这种保护的代价是延长事务滞后

时间。

此可用性模式相对于性能而言更强调高可用性和数据保护，当主副本和辅助副本距离

较近时可以使用此方法，解决时时同步的问题。

正因为AlwaysOn可用性组集现有高可用性技术的优点于一身，不得不说，它是SQL

Server2012新特性中最为璀璨的一个。

下面我们就结合实例看一下AlwaysOn可用性组的

配置。

实例操作：

AlwaysOn可用性组配置

因查询压力较大，现需要搭建

createtable、droptable

故障转移群集和数据库镜像的

实例：

北京某知名医院的医院信息化平台解决方案系统,近实时的报表服务器，但因早期规划不周，经常需要执行类似于之类的DDL命令。

分析：

基于此要求采用早期的高可用解决方案都不可行,

辅助节点或者辅助数据库不可用，日志传送技术支持对辅助数据库在还原作业之间的间隔时

间内的只读访问权限一般用于远程的异步容灾，存在部分数据丢失的可能性。

复制的实时性

较强，但针对的是数据库中对象，针对DDL命令无能为力。

综合分析下来，AlwaysOn可用

性组最为合适。

拓扑图:

16S.肚

hibiicEio.io.io.too

Public：

W-10.io.o

Heart:

国2168.1.0（

Public:

10.10,10.11

i,I

Ir**.'i:

H点hS^rvprIi釦、

前提：

整个AlwaysOn的配置过程非常简洁，但前提是需要搭建Windows故障转移群集，为了避免存储造成单点故障，在此可以使用多节点和共享文件的配置模式。

下面我们看一下

AlwaysOn的配置步骤。

步骤一：

启用AlwaysOn可用性组

启用AlwaysOn可用性组是服务器实例使用可用性组的先决条件。

在创建和配置任何

可用性组之前，必须在每个SQLServer实例上启用AlwaysOn可用性组功能。

操作方法

是：

打开SQLServer配置管理器，右键单击该SQLServer实例名称，选择“属性”，然后

打开“SQLServer属性”对话框，点击“AlwaysOn高可用性”选项卡，勾选“启用AlwaysOn可用性组”，如下图所示：

依次点击“应用”、“确定”，然后需要重新启动

SQLServer服务。

查看配置是否正

常，可以在在对象资源管理器中，右键单击服务器实例，再单击“属性”。

打开“常规”，

可以看到HADR已经启用，如下图所示:

Hll库蹴存窿.丄搞iH轩陌

2-上_r.r:

HADJiTz

口當，..z奋I?

目平'«逼内側ft

另外一台服务器Server2上需要进行同样的操作。

步骤二：

创建可用性组

A.相应数据库做完全备份

只有进行完全备份之后,

在此需要将准备添加到可用性组中的数据库进行完全备份,据库才会进行日志备份。

如下图所示:

sql・ini工X

-backupdat^asedbItoc:

"\b&ckup\dbLrithcrapresFion.ctif

backupdb2todifkciAback^db?

・bok，^ithcon^resrion.rhrck.--un

B.创建可用性组

当准备工作完成后，就可以创建可用性组了，用户可以使用向导、

T-SQL命令、

当准备工作完成后，就可以创建可用性组了，用户可以使用向导、

PowerShell命令来创建可用性组，在此使用向导，在Serverl上点击可用组向导，弹出创

建新的可用性组的简介信息，直接下一步，出现如下图所示的界面：

PowerShell命令来创建可用性组，在此使用向导，在

Serverl上点击可用组向导，弹出创

建新的可用性组的简介信息，直接下一步，出现如下图所示的界面:

X

權MU

送豁計佩回占

^ff-iPHttrnm户世总卑・比StL計「祝：

臺他上曲阴FIJMISSQJ

然后选择我们刚进行过完整备份的DB1、DB2数据库。

生产环境中，用户根据需要选

择满足条件的数据库。

播定副本

捣1喪策期AlhiiU的SWLS.r«r真朴

和|«^iMtiHs唤|戸听isi可耐Uk事w

V上一步囂）I

在此界面中可以选择自动故障转移，同步提交的意思是说辅助节点收到主节点传给它的

日志后，主节点才进行事务的提交，从而保证数据的一致性。

可读辅助副本选择是，辅助副

本是允许只读的。

迭择惣的独摻同寧首选顷“

冷完整©

員醤脅鑼翳II齬脣嶠誉嘗份稻曰討濮謀蛇脑"舷酗鲸则指定斯有副本可访辰的其專网貉位番目

|\\SEK¥IEDnbiffkup

厂仅联播

（1）

羁聽齋鵜誌幣泾隼①嚅助鮭器的地方启貓播鮮朋迭薮18库联辭惮

「鎂迫勒阳歎罄同歩（£）

豹果異时韻个主數摭肾岚行自己的數擴障和日志番強，谱逸幅业适硬。

以使得辅助节点可以从此处进行

结果

成玫I

弊告

在此我们选择一个存放数据库备份文件的共享文件夹,数据库的还原操作。

名称

正在强S否僮用镰答的箪法加密剎点正在检査承奏Ml助捌本SWVEMZ的鲫詞来洌上的可魔牆空间

盘正在桧萱费魏攜助劃本SIE7ZM2的曙背異实洌上是否已存在所选纱据哇

国疋在磨耘聊wa本娅料磁的僵箝吉买洌上总据库文剜MtsiijT正舌检董重载辅助副本髯眈磁的溜咅器丽上矗据金文件是晋—

露正在检鲫fi■器削署

在此进行网络、磁盘空间、数据库文件以及兼容性的验证。

在此侦听器配置显示的警告信息，是因为我们没有为可用性组配置侦听器，我们将在完成后再进行配置，在此直接下-步。

然后系统会自动完成在辅助节点上还原数据库的操作。

步骤三：

创建侦听器

在创建可用性组向导中默认是不创建侦听器的，所以我们在此需要创建侦听嘎嘎。

每个

可用性组侦听器都需要一个DNS主机名，该名称在域和NetBIOS中是唯一的。

口孵▼13帮助

偵時DIE卧：

阿

崭口：

阿

阿络俱式：

疇悉“3

［插

IIP地址

[lO.lDjafl/24|

jW1010200

K

侦听器就是一个虚拟的网络名称，可以通过这个虚拟网络名称访问可用性组，而不用关

心连接的是哪一个节点，它会自动将请求转发到主节点，当主节点发生故障后，辅助节点会变为主节点，侦听器也会自动去侦听主节点。

指定侦听器的名称该侦听器所使用的端口号、IP地址（在此也可以使用DHCP服务器分

配）。

一旦创建成功，会注册到DNS中。

用户就可以使用此名称来连接到可用性组中。

通过以上的介绍和实例配置，可以明显感觉到AlwaysOn可用性组的配置相当简洁，简

单几步即可完成，丝毫不像日志传送、数据库镜像那么繁琐。

就其功能而言，如用户需要实

现基于共享存储服务器实例级别的高可用和故障恢复可以使用AlwaysOn多站点故障转移群

集技术；如果用户需要实现非共享存储基于数据库级别的高可用和故障恢复则可以使用AlwaysOn可用性组技术；甚至还可以AlwaysOn故障转移群集和可用性组的组合使用实现实例级别的高可用和数据库级别的故障恢复。

功能如此之强，让人叹服！