SQL Server 高可用方案

方案一：Asynchronous Mirror + Alias

方案介绍

数据库服务器配置异步镜像关系，程序客户端连接串配置别名连接。

1. 在SQL Server客户端配置中创建别名，在客户端的连接串设置中用别名代替服务器名或IP地址。

2. 写一个实用程序，在镜像角色切换的时候，更新别名。

3. 更新别名可通过修改相应的注册表字符串来完成，位于HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo

方案优缺点

优点：对于实现计划中的数据库迁移安全、快捷、简单。仅需修改别名对应IP地址。

缺点：对于少量业务应用管理较实用。

方案二：Asynchronous Mirror + Hosts

方案介绍

数据库服务器配置异步镜像关系，程序客户端配置域名连接，Hosts文件配置IP和域名的对应关系。

1. 在客户端机器中修改Hosts文件，创建域名和主数据库服务器IP的对应关系。

2. 写一个实用程序，在镜像角色切换的时候，更新Hosts文件中的IP地址。Hosts文件位于Hosts文件位于C:\Windows\System32\drivers\etc\Hosts

3. 清空客户端机器的DNS缓存。

方案优缺点

优点：仅需修改客户端Hosts文件中的IP和域名对应关系后，清空DNS缓存，重新获取新的主服务器信息。

缺点：相较方案一，有一定延时。

方案三：Asynchronous Mirror + DNS

方案介绍

数据库服务器配置异步镜像关系，程序客户端配置域名连接，DNS服务器配置IP和域名的对应关系。

1. 创建DNS CNAME / A 记录指向活动的数据库服务器。

2. 在客户端连接串设置中，使用一个虚拟的名称。

3. 写一个实用程序完成以下工作：

a) 更新DNS记录

b) 在镜像角色切换的时候，清空客户端机器的DNS缓存

方案优缺点

优点：对于实现大批量业务应用平台化管理较实用。

缺点：需要修改DNS服务器端记录配置信息，再清理客户端DNS缓存，重新获取新的主服务器信息。过程相对繁琐；需要考虑DNS服务器的高可用；相较方案一、二，有一定延时。

方案四：AlwaysOn

方案介绍

AlwaysOn是一项集合了故障转移群集、数据库镜像和日志传送的优点于一身的、功能强大的“高可用性+灾难恢复”技术。

AlwaysOn利用了Windows故障转移群集的健康监测和自动故障转移的特性，因此它必须建立在Windows故障转移群集之上。但是和SQLServer群集不同的是，可用性组里的数据库并不是一定要求存放在共享存储（SharedDisk）上的，它们也可以存储在本地磁盘上。另外，可用性组是以用户数据库的集合为单位进行健康检测和故障转移的，而不像SQLServer群集那样是以整个实例为单位。

方案优缺点

优点：AlwaysOn可用性组，每个可用性组是一个包含了一个或数个用户数据库的容器，可用性组里的所有数据库作为一个整体发生故障转移；辅助服务器可用于只读的访问请求；辅助服务器可以执行备份和DBCC命令。

缺点：AlwaysOn的SQLServer实例，最好使用同样的固定端口；基于Windows群集。

方案五：Synchronous Mirror

方案介绍

当事务安全设置为 FULL 时，数据库镜像会话便会在初始同步阶段后以高安全性模式同步运行。又细分为：

1. 不带自动故障转移功能的高安全性模式

当伙伴连接在一起并且数据库已同步时，支持手动故障转移。如果镜像服务器实例出现故障，则主体服务器实例不会受到影响并且公开运行（即，未镜像数据）。如果主体服务器丢失，则镜像会挂起，但可以将服务强制到镜像服务器（可能造成数据丢失）。

2. 带自动鼓掌转移功能的高安全性模式

自动故障转移通过确保在丢失一个服务器之后仍向数据库提供服务来提供高可用性。自动故障转移要求会话具有第三个服务器实例（“见证服务器”），理想情况是见证服务器驻留在第三台计算机上。

方案优缺点

优点：无数据损失。

缺点：对业务性能要求较高的业务一定影响；需要部署一台见证服务器。

方案六：SQL Server Cluster

方案介绍

SQL Server 故障转移群集构建于 Windows Server 故障转移群集之上。Windows服务器故障转移集群旨在提供高可用性服务或应用程序集群内运行故障转移。它包含一组独立运行的服务器来提高应用程序和服务的可用性。故障转移集群可以防止硬件和软件故障， 将故障资源从一个服务器 (或集群节点) 转移到另一个的节点。故障转移是一个过程， 以一个集群服务或应用程序在一个节点上离线，并将它重新联机在另一个节点。整个过程对用户是透明的。

方案优缺点

优点：有性能的影响小。

缺点：基于Windows群集；停机时间约等于SQL Server服务重启的时间+数据库恢复时间；无法抵御共享存储磁盘故障。

方案七：Hyper-V + SQL Server Cluster

方案介绍

很多用户在Hyper-V虚拟机中用到了MS SQL Server。但是单独（standalone）的SQL Server 不能提供高可用性和灾难恢复的功能。在对可用性有较高要求的Hyper-V用户面前，故障转移群集（Failover cluster）是必然用到的功能。当虚拟的生产服务器宕机时，热备份中的虚拟的服务器可以很快投入工作中。

方案优缺点

优点：减少计划中的业务停机时间，可利用Hpyer-V的动态迁移功能。

缺点：需要虚拟化，应用于压力小的业务。

方案八：Log Shipping

方案介绍

可以使用日志传送将事务日志不间断地从一个数据库（主数据库）发送到另一个数据库（辅助数据库）。不间断地备份主数据库中的事务日志，然后将它们复制并还原到辅助数据库，这将使辅助数据库与主数据库基本保持同步。目标服务器充当备份服务器，并可以将查询处理从主服务器重新分配到一个或多个只读的辅助服务器。日志传送可与使用完整或大容量日志恢复模式的数据库一起使用。

方案优缺点

优点：支持多副本。

缺点：故障转移后不可逆；对客户端不透明；停机时间较长。

方案九：Transactional Replication

方案介绍

事务复制通常从发布数据库对象和数据的快照开始。 创建了初始快照后，接着在发布服务器上所做的数据更改和架构修改通常在修改发生时（几乎实时）便传递给订阅服务器。 数据更改将按照其在发布服务器上发生的顺序和事务边界应用于订阅服务器，因此，在发布内部可以保证事务的一致性。

方案优缺点

优点：数据库对象级别。

缺点：对性能的影响较高。

方案十：以上方案的混合使用

方案介绍

如镜像结合日志传送等。

方案优缺点

优点：叠加多种方案的优点。

缺点：增加对性能的影响和管理的复杂度。

方案十一:NLB集群

方案介绍

NLB集群

方案优缺点

优点：透明

缺点：系统层技术复杂。

附表1：SQL Server高可用方案对比

本文转自UltraSQL51CTO博客，原文链接： http://blog.51cto.com/ultrasql/1579613，如需转载请自行联系原作者