SQL Server 2012 AlwaysOn集群配置指南

1. AlwaysOn介绍

AlwaysOn是SQL Server 2012提供的全新综合、灵活、高效经济的高可用性和灾难恢复解决方案。它整合了镜像和群集的功能，基于OS 故障转移群集(Windows Server FailOver Cluster)，通过在同一个WSFC的不同Node上，安装独立的SQL Server实例，定义AlwaysOn Group，一个数据库最多可以部署4个镜像。当热备机出现故障时，可以手工或自动实现故障转移，交换主、辅数据库的角色。

AlwaysOn的亮点在于镜像可读。对于OLTP应用，可以将读操作集中的报表等操作转移到Read-Only的辅助库上，极大地减少Primary DB的IO、CPU等资源占用。由于辅助库是独立的SQL实例，因此创建临时表等TempDB操作不受影响。

1.1. 可用性模式

同步提交

同步提交模式下，主数据库事务提交前，通知辅数据库，直到辅数据库提交成功后，主数据库成功提交。

优点：数据受到完整保护，不会存在数据不一致。

缺点：事务执行时间延长，效率降低。

异步提交

异步提交模式下，主数据库独立提交事务，不必等待辅数据库同步，同时将数据写入日志，辅数据库通过事务日志同步数据。

优点：事务执行时间不受辅数据库影响，效率高。

缺点：数据同步存在延时。

*注：我们曾经测试过SQL 2008镜像异步提交和同步提交的效率，异步模式下，延时的时间基本可以忽略，在大事务情况下，延时也仅在秒级。而同步模式下，一旦辅数据库出现异常，如网络连接等错误，那么主数据库将挂起，对于系统的影响巨大。

考虑到报表对于数据实时性的要求在秒级以内完全可以接受，我们建议使用异步提交模式。

1.2. 故障转移模式

手动转移(不存在数据丢失)

主、辅库都是同步提交模式，且故障转移为手动，由SSMS发起FailOver命令。

自动转移(不存在数据丢失)

主、辅库都是同步提交模式，且故障转移为自动，不受人为控制，由WSFC自动仲裁。

强制转移(存在数据丢失)

主库是异步提交模式，且故障转移为手动，由SSMS发起FailOver命令。由于某种原因，主、辅库数据不同步，必须使用强制模式实现故障转移，此时可能存在数据丢失的情况，通常应用于突发的灾难恢复。当主、辅库SQL实例均从灾难中恢复正常后，可以通过数据移动功能确保数据同步。

可用性模式和故障转移模式兼容表：

1.3. 主、辅数据库连接方式

DotNetFramework 4. 0以后版本，为了兼容新的灾难恢复AlwaysOn Cluster数据库，连接串中增加了一个属性ApplicationIntent，用于标识应用程序连接到数据库的方式，ApplicationIntent有三种选项：

1) Null。不设置ApplicationIntent，默认为ReadWrite，兼容.NET 4.0以前的连接串。

2) ReadWrite。

3) ReadOnly

应用程序通过AlwaysOn群集的DNS访问数据库群集时，首先路由到主数据库，然后根据应用程序连接的模式(Null、ReadWrite、ReadOnly)选择是否路由到Read-Only辅助库。

? 主数据库连接方式

a) 允许所有连接。当我们设置主数据库允许所有连接时，应用程序任何时候都可以连接到数据库群集。

b) 允许读/写连接。当我们设置主数据库只允许读/写连接时，ApplicationIntent= ReadOnly的应用程序连接将被阻止，并抛出异常“数据库不允许只读连接”。

? 辅数据库是否允许只读

a) NO。辅数据库不允许读操作。

b) Read-Intent Only。辅数据库只读，且只允许ReadOnly连接。此选项意味着只能通过SqlCmd –K ReadOnly、PowerShell、或者ApplicationIntent=ReadOnly的应用程序连接数据库。我们通常使用SSMS连接到该数据库是被禁止的。

c) Yes。辅数据库只读，且兼容以前的连接方式。此选项意味着可以通过任何连接方式连接到辅数据库，且辅数据库只读。

典型应用场景：

2. 安装准备工作

安装操作系统群集和MSDTC，见《SQL2008群集配置指南（windows 2008）》。

3. 配置AlwaysOn

3.1. 启动服务

SQL服务->启用AlwaysOn可用性组，重启SQL服务。各群集节点相同。

3.2. 设置数据库完整恢复模式

在主数据库上，将数据库设置为完整恢复模式

3.3. 完整备份数据库

完整备份数据库，可放在任意目录下。

3.4. 设置共享目录

在主数据库上，设置网络共享目录，设置everyOne可写权限。主数据库会将Transaction Log自动备份到共享目录，辅助库通过Transaction Log同步数据。

3.5. 创建AlwaysOn Group

任意指定可用性组名，如U9AvailableGroup。

选中已经备份的数据库，这里会校验是否满足要求，只有满足要求的DB才能选择。

DB1为主数据库，一旦发生故障转移作为辅数据库时，我们同样希望它可读，设置Readable Secondary为Yes。

端点页签，默认值，勿修改。

备份策略，辅数据库优先。

创建侦听器，侦听1433端口，设置AlwaysOn群集IP。

回到副本页签，点击“添加副本”。

连接到辅数据库。

设置辅数据库可读，Readable Secondary=yes。下一步。

指定3.4节中设置的共享目录。由于我们要做集群的库只在DB1上存在，我们希望自动在DB2上还原一个相同的库，选择Full。可以根据不同情况选择其它两项。

验证可用性组，如果出现异常，必须按提示修复异常信息，直到成功。

点击完成即可。

全部成功即完成。

3.6. 设置连接方式

在主数据库上，AlwaysOn High Availability->可用性组->上一部创建的可用性组->鼠标右键->属性。

设置如下，Connections In Primary Role全部为允许所有连接，Readable Secondary全部为Yes。

3.7. 检查Read-Only Routing List

步骤1：在主数据库->Master数据库上，执行如下SQL:

Select * from sys.availability_read_only_routing_lists，查看返回结果，如下：

因为我们的AlwaysOn 群集有两个Node，因此Routing List中应有两条记录。OK，检查通过。否则执行步骤2：

步骤2：在主数据库上执行以下SQL：

ALTER AVAILABILITY GROUP U9AvailableGroup

MODIFY REPLICA ON

N'DB1' WITH

(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://DB1.u9erp.com:1433'));

ALTER AVAILABILITY GROUP U9AvailableGroup

MODIFY REPLICA ON

N'DB2' WITH

(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://DB2.u9erp.com:1433'));

ALTER AVAILABILITY GROUP U9AvailableGroup

MODIFY REPLICA ON

N'DB1' WITH

(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('DB2','DB1')));

*注：U9AvailableGroup为创建的可用性组名；DB1、DB2分别为主数据库、辅数据库名称。

再次检查Routing List，应已添加了两条记录。

3.8. 检查数据库同步情况

步骤1：检查主数据库，使用SSMS连接到主数据库。

主数据库状态应为已同步，可用性数据库应正常运行。见图中红色部分。

步骤2：检查辅助库，使用SSMS连接到辅助库。

由于我们选择的是异步提交模式，因此辅助库显示正在同步，正常。可用性数据库运行正常。

3.9. 测试Read-Only Routing

我们希望当已ReadOnly方式连接数据库群集时，默认情况下，将请求转发到Read-Only辅助库，可以通过Sqlcmd命令测试路由情况，在命令行中执行下列命令：

步骤1：Sqlcmd –S [群集DNS] –E –d [群集库名] –K ReadOnly

*注：注意-K大写。

步骤2：Select @@ServerName

步骤3：Go

DB2为ReadOnly辅助库，测试结果返回DB2，正常。

如果返回DB1，则说明辅助库路由没有起作用，请检查3.6节和3.7节设置是否正确。

4. SQL Server 2012 ReportService KB

SQL Server 2012 ReportService运行在.NET 2.0下，安装完SQL Server 2012后，再安装微软补丁KB2654347。

Windows 2008 R2 ，需要安装windows 6.1补丁；Windows 2008 SP2，需要安装windows 6.0补丁，见附件。

5. U9配置

和SQL Server 2008配置相同，在U9配置管理工具中添加SQL Server集群地址，连接数据库服务器。U9报表等查询负载自动转移到从节点。

SQLServer 2012 Always on是针对高可用性和灾难恢复的新解决方案。可以配置一个或多个辅助副本以支持对辅助数据库进行只读访问，并且可以将任何辅助副本配置为允许对辅助数据库进行备份。这样就提供了硬件的使用效率。

“可用性组”针对一组离散的用户数据库（称为“可用性数据库”，它们共同实现故障转移）支持故障转移环境。一个可用性组支持一组主数据库以及一至四组对应的辅助数据库。可用性组在可用性副本级别进行故障转移。故障转移不是由诸如因数据文件丢失或事务日志损坏而使数据库成为可疑数据库等数据库问题导致的。

每组可用性数据库都由一个“可用性副本”承载。有两种类型的可用性副本：一个“主副本”和一到四个“辅助副本”。前者用于承载主数据库，后者则承载一组辅助数据库并作为可用性组的潜在故障转移目标。主副本使主数据库可用于客户端的读写连接。此外，它在称为“数据同步”的过程中使用，在数据库级别进行同步。主副本将每个主数据库的事务日志记录发送到每个辅助数据库。每个辅助副本缓存事务日志记录（“硬化”日志），然后将它们应用到相应的辅助数据库。主数据库与每个连接的辅助数据库独立进行数据同步。因此，一个辅助数据库可以挂起或失败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。

或者，您可以配置一个或多个辅助副本以支持对辅助数据库进行只读访问，并且可以将任何辅助副本配置为允许对辅助数据库进行备份。部署 AlwaysOn可用性组需要一个Windows Server故障转移群集 (WSFC)群集。

图显示一个可用性组，该组包含最大数目的可用性副本，即一个主副本和四个辅助副本。

来自：http://msdn.microsoft.com/zh-cn/library/ff877884.aspx

虽然2012 Always on是基于WSFC的，但是并不需要共享存储，所以配置就非常简单。

下面是我的安装步骤：

至少需要三台机器（我创建了三台虚拟机，一台是作为DC,DNS服务器，两台Nod3）

机器名	角色	OS	IP Address
DC	Domain Controller	Windows 2008R2	192.168.1.10
Node1	Cluster Node 1	Windows 2008R2	192.168.1.11 Public 192.168.2.1 心跳线
Node2	Cluster Node 2	Windows 2008R2	192.168.1.12 Public 192.168.2.2 心跳线窗体底端

首先配置Windows集群：

1. 安装.NETFramework 3.5.1 Features和Failover Clustering

2. 安装Windows KB 2494036

3.新建集群

4.选择加入集群的服务器：

5.检测配置：

6.不需要选择检测共享磁盘（AlwaysOn不需要）

7.开始检测：

8.检测内容（检测完成后可以导出Report）：

9.之后输入Cluster名字和IP点击下一步创建成功，成功后打开Server Manager查看集群配置(可以看到并没有共享磁盘，跟传统的集群还是有区别的)

由于我们只使用了两台机器，所以当一台机器Ｄｏｗｎ掉之后就没有仲裁了，无法成功转移。当使用多节点做仲裁，可以使用三台Ｎｏｄｅ，这样一台Down掉之后另外两台可以做仲裁。如果两个Ｎode,不使用共享磁盘可以使用Ｓｈａｒｅ文件的方式，具体的配置可以参考：http://www.sqlskills.com/blogs/jonathan/failover-clustering-without-a-san-sql-server-2012-and-smb-for-shared-storage/（之前没有配置这一步，虽然ＡｌｗａｙｓＯｎ级别可以Ｆａｉｌｏｖｅｒ，但是真正一台ＮｏｄｅＤｏｗｎ掉之后就不行了，感谢@struggle1指出这个问题。）

现在我们集群已经配置后了，下一步是安装SQLServer并且配置Always On.