下载文档原格式
1.1 数据库镜像支持有关对SQL Server 2012 中的数据库镜像的支持的信息，请参考：https:///zh-cn/previous-versions/sql/sql-server-2012 /cc645993%28v%3dsql.110%291.2 其他前置条件∙需要安装.NET 补丁，详见：https:///zh-cn/help/2654347/an-update-introduc es-support-for-the-alwayson-features-in-sql-server-2。
∙确保参与参与一个或多个可用性组的计算机不是域控，域控制器节点不支持可用性组。
∙确保每台计算机都是Windows Server 故障转移群集(WSFC) 群集中的节点，详见：https:///zh-cn/previous-versions/sql/sql-server-2012 /hh270278%28v%3dsql.110%29。
∙确保有足够的WSFC节点，详见：https:///zh-cn/previous-versions/sql/sql-server-2012 /ff877884%28v%3dsql.110%29。
∙若要管理WSFC 群集，用户必须是每个群集节点上的系统管理员。
注意：建议预留足够的空间，在主数据库增长时，其相应的辅助数据库也增长相同量。
建议：建议您为WSFC 群集成员之间的通信和可用性副本之间的通信使用相同的网络链接。
1.3 其他限制∙可用性副本必须由一个WSFC 群集的不同节点承载：对于某个给定可用性组，可用性副本必须由在同一WSFC 群集的不同节点上运行的服务器实例承载。
唯一的例外是在迁移到另一个WSFC 群集时，此时一个可用性组可能会暂时跨两个群集。
∙唯一的可用性组名称：每个可用性组名称在WSFC 故障转移群集上必须唯一。
可用性组名称的最大长度为128 个字符。
∙可用性副本：每个可用性组支持一个主副本和最多四个辅助副本。
sqlserver allwayson 原理SQL Server Always On是一种高可用性和灾难恢复解决方案，是SQL Server在企业级环境中的一项关键技术。
它通过使用数据库镜像、故障转移和自动故障恢复功能来确保数据库的持续运行，提供了数据库级别的冗余和容错能力。
接下来，我们将详细介绍SQL Server Always On的原理。
SQL Server Always On的原理主要包括以下几个方面：高可用性组、自动故障检测、数据复制和故障转移。
1.高可用性组：高可用性组是SQL Server Always On的核心概念，它由一个主数据库和一个或多个辅助数据库组成。
主数据库是应用程序的主要访问点，而辅助数据库负责实时复制主数据库的数据，并在主数据库发生故障时接管访问请求。
每个数据库都位于不同的SQL Server实例上，这些实例可以部署在不同的物理服务器上，实现数据库级别的冗余和容错。
2.自动故障检测：SQL Server Always On使用心跳检测来检测数据库实例的故障。
每个数据库实例都会定期向其他实例发送心跳信号，以确保它们的可用性。
如果某个实例不再发送心跳信号或心跳信号超时，其他实例将会检测到该实例的故障，并触发自动故障转移过程。
3.数据复制：SQL Server Always On使用了一种称为“Always On复制”的技术来实现数据的实时复制。
Always On复制使用了SQL Server日志传送服务（Log Shipping）和数据库镜像（Database Mirroring）的功能。
主数据库会将其写入的事务日志传送到辅助数据库，辅助数据库会实时应用这些事务日志以保持与主数据库的数据同步。
这种数据复制机制确保了数据库的冗余性和一致性。
4.故障转移：在主数据库发生故障时，SQL Server Always On会自动进行故障转移。
故障转移的过程包括以下几个步骤：首先，自动故障检测会检测到主数据库的故障，并将主数据库标记为不可用；然后，系统会启动一个辅助数据库来接管访问请求；最后，其他辅助数据库会重新选举一个新的主数据库，并继续提供服务。
Sqlserver2012 alwayson部署攻略一、环境。
1、服务器：准备4台虚拟机。
2、操作系统：windows2008 R2 SP2或者以上版本。
3、数据库：Sqlserver 2012。
二、操作系统安装及设置。
4、在4台虚拟机上均装上操作系统windows 2008 R2,并分别设置计算机名为:DomainServer、DB1、DB2、DB3，分别设置IP为192.168.100.20、192.168.100.21、192.168.100.22、192.168.100.23。
5、在DB1、DB2、DB3上开启功能.NET3.5 SP1。
6、在DB1、DB2、DB3上安装Sqlserver2012。
7、在DomainServer服务器上建立域服务、并将DB1、DB2、DB3的DNS设置为192.168.100.20，然后加如域。
三、windows2008故障转移群集部署。
8、以\administrator域帐户登录DB1、DB2、DB3，并添加故障转移集群功能。
9、在DB1、DB2、DB3中任一台机上创建群集，并将DB1、DB2、DB3台服务器添加进去、群集名称为alwaysoncluster,群集IP为192.168.100.25,仲裁配置为“多数节点”。
四、alwayson部署。
10、关闭DB1、DB2、DB3的防火墙或者在防火墙规则中添加例外端口1433、5022。
11、分别打开DB1、DB2、DB3的“SQL Server 配置管理器”，在左侧的“SQL Server 服务”列表中找到默认的实例。
12、将Sqlserver服务的登录帐户更改为域帐户\administrator，并重启sqlserver 服务。
13、分别使用数据库管理工具连接DB1、DB2、DB3的数据库，并创建sqlserver的域登录帐户\administrator，并赋予sysadmin角色。
14、在DB1、DB2、DB3的分别建立目录D:\SQLDATA用于存放sql数据库文件，在局域网内建立一个可读写共享目录，该共享目录用于存放快照文件。
SQL 2012 AlwaysON 配置说明AlwaysON 功能是SQL SERVER 2012引入的新功能，是对原有的数据镜像功能的增强，是针对高可用性和灾难恢复的新解决方案。
使用AlwaysON可以为主库配置一个或多个辅助副本以支持对辅助数据库进行只读访问，并且可以将任何辅助副本配置为允许对辅助数据库进行备份，从而提高硬件利用率。
AlwaysON功能是通过SQL 2012的 Availability Groups (可用性组，以下简称AG)来实现的。
AG针对一组离散的用户数据库（称为“可用性数据库”，它们共同实现故障转移）支持故障转移环境。
一个可用性组支持一组主数据库以及一至四组对应的辅助数据库。
可用性组在可用性副本级别进行故障转移。
故障转移不是由诸如因数据文件丢失或事务日志损坏而使数据库成为可疑数据库等数据库问题导致的。
每组可用性数据库都由一个“可用性副本”承载。
有两种类型的可用性副本：一个“主副本”和一到四个“辅助副本”。
前者用于承载主数据库，后者则承载一组辅助数据库并作为可用性组的潜在故障转移目标。
主副本使主数据库可用于客户端的读写连接。
此外，它在称为“数据同步”的过程中使用，在数据库级别进行同步。
主副本将每个主数据库的事务日志记录发送到每个辅助数据库。
每个辅助副本缓存事务日志记录（“硬化”日志），然后将它们应用到相应的辅助数据库。
主数据库与每个连接的辅助数据库独立进行数据同步。
因此，一个辅助数据库可以挂起或失败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。
AlwaysON是基于WINDOWS SERVER的故障转移功能(WSFC)的，但是AG功能并不需要共享存储，配置AlwasON之前，需要先配置好WSFC。
第一部分 系统环境准备(硬件及软件环境)A、准备WSFC环境1、宿主物理服务器 DELL R710配置信息：2颗4核 Xeon E5405处理器，16G内存windows server 2012 datacenter(x64)系统，Hyper-V 3.0虚拟机管理2、客户端虚拟服务器 域控sql2012a，2颗逻辑C PU，4G内存，windows 2008 r2 sp1(x64)系统I P地址10.1.15.85，子网掩码255.255.255.0，默认网关10.1.15.1，DNS为10.1.15.85 主节点sql2012b：4颗逻辑C PU，4G内存，windows 2008 r2 sp1(x64)系统I P地址10.1.15.86，子网掩码255.255.255.0，默认网关10.1.15.1，DNS为10.1.15.85 辅助节点sql2012c：4颗逻辑C PU，4G内存，windows 2008 r2 sp1(x64)系统I P地址10.1.15.87，子网掩码255.255.255.0，默认网关10.1.15.1，DNS为10.1.15.85B、准备域环境 sql2012a上安装配置sql2012.co m域，并将sql2012b、sql2012c加入sql2012.co m 域。
SQL Server AlwaysOn可用性及故障转移2014-03-27 01:55:04标签：高可用数据库日志记录原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明。
否则将追究法律责任。
/382644/1384835SQL Server AlwaysOn可用性及故障转移杜飞在AlwaysOn 可用性组中，“可用性模式”是一个副本属性，该属性确定某一给定可用性副本是否可在同步提交模式下运行。
AlwaysOn的可用性模式决定了各副本之间是否允许存在数据差异，SQL Server2012的可用性组使用异步提交模式和同步提交模式来决定主副本在提交事务之前是否等待辅助副本将事务日志记录固化到磁盘。
如果主副本配置为“异步提交模式”，则它不会等待任何辅助副本将传入的事务日志记录写入磁盘（以便“强制写入日志”）。
如果某一给定的辅助副本配置为异步提交模式，则主副本不会等待该辅助副本强制写入日志。
如果主副本和某一给定辅助副本都配置为“同步提交模式”，则主副本将等待辅助副本，以便确认它已强制写入日志（除非辅助副本在主副本的“会话超时期限”内未能使用ping 命令联系上主副本）。
同步提交模式在同步提交模式下，主数据库在提交事务之前，主副本要等待同步提交辅助副本确认它已将日志固化到磁盘上。
只要辅助副本还没有告诉主副本日志固化完成，主副本上的事务就不能提交。
这样就保证两边的数据始终是同步的。
只要一直在进行数据同步，辅助数据库就会保持“已同步”(SYNCHRONIZED)的状态。
同步提交模式能够保证给定的辅助数据库与主数据库上的数据保持完全的同步。
但是代价是主数据库上的事务提交会有滞后时间。
可以说，同步提交模式相对于性能而言更强调高可用性。
辅助副本的同步工作原理：在同步提交模式下，在辅助副本联接可用性组并与主副本建立会话之后，辅助副本会将传入日志记录写入到磁盘（“固化日志”）并向主副本发送确认消息。
SQLserver⾼可⽤⽅案SQL server⾼可⽤⽅案⼀、⾼可⽤的类型●Always On ⾼可⽤性解决⽅案，需要sql server 版本在2012以上SQL Server Always On 即“全⾯的⾼可⽤性和灾难恢复解决⽅案”。
客户通过使⽤Always On 技术，可以提⾼应⽤程序可⽤性，并且通过简化⾼可⽤性的部署和管理⽅⾯的⼯作。
SQL Server Always On 在以下2个级别提供了可⽤性。
*数据库级可⽤性是⼀种“热备份”技术。
在同步提交模式下，主副本的数据被同步更新到其他辅助副本，主副本与辅助副本之间可以保持实时同步。
当系统监测到主副本发⽣故障时，辅助副本可以⽴即成为新的主副本。
*实例级可⽤性Always On 故障转移群集实例（Failover Cluster Instance，简称FCI）可以在多个16个节点之间实现故障转移（Failover）。
企业版最多⽀持16个节点，标准版只⽀持2个节点。
当主节点发⽣故障时，辅助节点提升为主节点并获取共享存储中的数据，然后才在这个新的主节点服务器中启动SQL Server 服务。
FCI 是⼀种“冷备份”技术。
辅助节点并不从主节点同步数据，唯⼀的⼀份数据被保存在共享存储（群集共享磁盘）中。
●⽇志传送⽇志传送依赖于传统的Windows ⽂件复制技术与SQL Server 代理。
主数据库所做出的任何数据变化都会被⽣成事务⽇志，这些事务⽇志将定期备份。
然后备份⽂件被辅助数据库所属的实例复制到它的本地⽂件夹，最后事务⽇志备份在辅助数据库中进⾏恢复，从⾯实现在两个数据库之间异步更新数据。
当主数据库发⽣故障时，可以使辅助数据库变成联机状态。
可以把每⼀个辅助数据库都当作“冷备⽤”数据库●其它辅助技术对数据库进⾏备份，当出现故障时，⼿动将数据还原到服务器，使得数据库重新联机，这也可以算作实现⾼可⽤性的⼀种技术⼿段。
复制（Replication）并不算是⼀个⾼可⽤性解决⽅案，只是它的功能可以实现⾼可⽤性。
Sqlserver2012Alwayson高可用性方案Sqlserver2012Alwayson高可用性方案变更记录*修订类型分为A - ADDED M - MODIFIED D– DELETED注：对该文件内容增加、删除或修改均需填写此记录，详细记载变更信息，以保证其可追溯性目录1 需求分析1.1 背景说明 (3)1.2 系统目标与系统边界 (4)2 AlwaysOn高可用性配置2.1环境........................................................................................................................... ...... .5 2.2操作系统安装及配置 ..................................................................................................... .5 2.32008故障转移群集部署 ............................................................................................ .(6)2.4 AlwaysOn部署 (7)3数据库备份3.1AlwaysOn在主服务器上面进行数据库完全备份和差异备份................................. .10 3.2查看主服务器备份文件 ............................................................................................... .10 4模拟故障转移切换节点4.1在主节点实施故障转移策略 (11)4.2将节点sql03部署在异地机房，选择异步提交，允许>10ms 延时 (12)4.3读写分离的故障转移模式 (12)5灾备系统测试5.1模拟上海数据中心的客户数据库发生故障 (12)5.2模拟上海数据中心的硬件发生故障 (12)5.3模拟上海数据中心的数据丢失 (12)5.4模拟上海数据中心存储设备有故障 (13)5.5灾备检测工具DBCC (13)1 1 需求分析1.1背景说明AlwaysOn利用了Windows故障转移群集的健康监测和自动故障转移的特性，因此它必须建立在Windows故障转移群集之上。
SQL Server 2012 AlwaysOn Failover Cluster安装部署文档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.可用性模式➢同步提交同步提交模式下，主数据库事务提交前，通知辅数据库，直到辅数据库提交成功后，主数据库成功提交。
优点：数据受到完整保护，不会存在数据不一致。
缺点：事务执行时间延长，效率降低。
➢异步提交异步提交模式下，主数据库独立提交事务，不必等待辅数据库同步，同时将数据写入日志，辅数据库通过事务日志同步数据。
优点：事务执行时间不受辅数据库影响，效率高。
缺点：数据同步存在延时。
1.2.故障转移模式➢手动转移(不存在数据丢失)主、辅库都是同步提交模式，且故障转移为手动，由SSMS发起FailOver命令。
➢自动转移(不存在数据丢失)主、辅库都是同步提交模式，且故障转移为自动，不受人为控制，由WSFC 自动仲裁。
➢强制转移(存在数据丢失)主库是异步提交模式，且故障转移为手动，由SSMS发起FailOver命令。
由于某种原因，主、辅库数据不同步，必须使用强制模式实现故障转移，此时可能存在数据丢失的情况，通常应用于突发的灾难恢复。
当主、辅库SQL实例均从灾难中恢复正常后，可以通过数据移动功能确保数据同步。
高可用性重要内容∙利用 SQL Server AlwaysOn 及其他高可用性功能，最大程度地实现应用程序可用性并提供数据保护∙在Windows Server Core 模式上安装SQL Server，从而大幅缩短计划停机时间∙利用活动副本提高 IT 效率和性能∙利用集成工具简化高可用性和灾难恢复部署及管理最大程度地实现应用程序可用性并提供数据保护实现所需的业务连续性服务水平，包括确保关键应用程序的连续运行时间，以及保护关键数据使其免受计划内和计划外停机的影响。
Microsoft® SQL Server® 2012可提供一系列特性和功能，确保企业无需增加成本和提高复杂度，即可实现最高级别的可用性和数据保护。
SQL Server AlwaysOn全新、灵活、经济高效的高可用性和灾难恢复解决方案，可在数据中心内部以及跨数据中心实现数据冗余，并实现快速应用程序故障转移，从而为业务关键应用程序提供最大限度的可用性和数据保护。
AlwaysOn 可实现配置灵活性，重复利用现有的硬件资源（包括共享存储）。
AlwaysOn 可以在数据库级和实例级配置高可用性。
✓AlwaysOn 可用性组是一项全新功能，它极大地增强了数据库镜像功能，同时确保了应用程序数据可用性，并防止数据丢失。
可用性组提供一系列集成选项，包括对数据库组进行手动故障转移、支持多达四个副本（其中两个同步副本）、快速应用程序故障转移及自动页面修复。
✓AlwaysOn 故障转移群集实例增强了 SQL Server 故障转移群集功能，并可跨越子网支持多站点群集，实现跨数据中心SQL Server 实例故障转移。
快速的可预见实例故障转移是实现快速应用程序恢复的另一关键优势。
✓Database Recovery Advisory可简化数据库还原，从而使管理员利用备份链的可视时间表，快速、轻松、及时地将数据库从现有备份集还原到指定时间点。
对等复制一种帮助提高扩展性、可用性和处理能力的通用功能，其方法是配置应用程序使用不同的对等方，并在出现故障时将故障转移至其他对等方。
SQL Server 2012 Always on Availability Groups(AG)部署一，几种故障转移比较1，SQL Server 2012 高可用性组相对于以前版本的SQL Server故障转移群集来讲，不依赖特别提供共享存储磁盘阵列，每个节点独立存储一份数据库副本。
2，SQL Server 2012 高可用性组相对于以前版本的SQL Server镜像数据库，提供多节点高可用，且数据库辅助节点副本可读；当可读节点出现故障，能够通过高可用性组自身保证数据库正常访问，不再像镜像数据库一样，通过访问端切换。
3，SQL Server 2012 高可用性组相对于以前版本的log Shipping 设置copy日志、创建管理存储过程、建立计划任务；同时也不需要访问端切换。
主服务停掉后，根据故障转移策略，辅助服务就会变更为主服务。
原主服务起来后，自动变更为辅助服务。
4，Always On 可用性组不支持跨数据库事务和分布式事务。
二，搭建环境部署SQL Server 2012需要在Windows域环境内，搭建Windows Server的群集服务支持。
所以需要成员服务器上实现WSFC。
WSFC仲裁配置有1多数（奇数）节点；2（偶数）节点和磁盘多数；3多数（偶数）节点和文件共享；4非多数，仅磁盘四种方式。
三，本次搭建AG满足的需求描述本次部署WSFC内由3台成员服务器组成。
1，VPN之间由于局限性，暂时在一个内网内搭建。
RTO、RPO取决于网络带宽。
2，主要服务器宕机后，服务会自动访问保存辅助副本服务器的DB。
3，辅助服务器DB可设置为只读模式。
4，主要服务器能够实现备份（全备，增量备份），不影响数据同步。
服务器操作系统为Windows Server 2008 R2，选择多数节点（3个）仲裁配置，虽然仲裁配置并不推荐，但不影响AG的实现和使用。
本次搭建分为3个部分做讲解。
Part1:搭建Windows群集（WSFC）第一步，3台机器KF005041，KF005042，KF005043每台要有2个网卡，分别做Public（连接外部服务），IP如下：192.168.5.41 , 192.168.5.42 , 192.168.5.43Private（作为心跳线使用）。
AlwaysOn 体系结构指南：使用 AlwaysOn 可用性组构建高可用性和灾难恢复解决方案SQL Server 技术文章作者：Joseph Sack ()、Sanjay Mishra (Microsoft)技术审校：Lindsey Allen (MS)、Juergen Thomas (MS)、Mike Weiner (MS)、Prem Mehra (MS)、Yorihito Tada (MS)、Curt Matthews (MS)、Amitabh Tamhane (MS)、Aditya Samant (MS)、Daniel Janik (MS)、Jimmy May (MS)、David P Smith (ServiceU)、Richard Waymire (SolidQ)、Brent Ozar (Brent Ozar PLF)、Wolfgang Kutschera ()、Paul S. Randal ()、Gianluca Hotz (SolidQ)、Ayad Shammout (Caregroup)内容项目经理：Glenn Minch (Microsoft)发布时间：2012 年 6 月适用范围：SQL Server2012摘要：SQL Server 2012 AlwaysOn 可用性组提供了一种统一的高可用性和灾难恢复 (HADR) 解决方案，将以前需要通过不同功能才能实现的机制融合起来并加以改进。
在 SQL Server 2012 之前，一些客户使用数据库镜像在数据中心内提供本地高可用性，并且使用日志传送与远程数据中心建立灾难恢复机制。
对于 SQL Server2012 而言，可以使用一种全新的体系结构来替代这种常见的设计模式：这种全新的体系结构使用可用性组来实现高可用性和灾难恢复。
本白皮书详细介绍这种特定设计模式的关键拓扑要求，包括仲裁配置注意事项、构建环境所需的步骤，以及展现如何在新拓扑中处理灾难恢复事件的工作流。
SQL Server高可用性MIS年度研究课题（2013）SQL Server高可用性工号：A0100488姓名：陈亚飞研究方向：SQL Server高可用性组别：SDS系统课日期：20130523SQL Server高可用性SQL Server高可用性摘要微软新一代数据库产品SQL Server 2012已经面世一段时间了，无论是从功能的扩展上讲还是性能的体现上来看，较之其早期产品都有了很大提升。
特别是其引入高可用性组（AlwaysOn Group, AG）这一概念和功能，大大增强和提高了SQL Server的可用性，在之前的镜像数据库的基础上有了质的变化。
SQL Server 2012高可用性组在实现过程中较之早起的SQL Server故障转移群集来讲，不依赖特别提供共享存储磁盘阵列，每个节点独立存储一份数据库的副本。
其较之早期的镜像数据库来讲，提供多节点高可用，并且针对数据库辅助节点副本可读；此外，在当前可读节点出现故障时，能通过AG自身的机制保证数据库正常访问，而不需要像镜像数据库一样，需要通过访问端来进行切换，且可以保证对外的IP服务地址不变。
本文的研究工作主要有以下几个方面：1. SQL Server Always On 基础2. Windows 集群。
3. SQL Server Always On与Windows Cluster 结合。
4. SQL Server高可用性的成效。
关键词：SQL高可用性、Windows 集群、AlwaysOn、SQL2012新特性SQL Server高可用性目录SQL Server高可用性 (I)第一章绪论 (2)1.1研究背景和意义 (2)1.2SQL Server Always On发展现状 (2)1.3论文研究的目标及主要内容 (2)第二章SQL Server Always On基础 (3)2.1何为SQL Server Always On (3)2.2SQL Server Always On 的优点 (3)2.2.1永不宕机 (4)2.2.2高安全性 (4)2.2.3高稳定性 (4)2.3为什么选择使用SQL Server Always On (4)第三章Windows 集群 (6)3.1为什么要建立Windows 集群 (6)3.2如何建立Windows 集群 (6)3.3Windows 集群的应用 (10)第四章SQL Server Always On与Windows集群 (11)4.1SQL Server Always On如何与Windows 集群相结合 (11)4.2SQL Server Always On 与Windows 集群测试 (25)第五章SQL Server Always On的成效评估 (29)参考文献 (30)致谢31SQL Server高可用性第一章绪论1.1 研究背景和意义随着生产环境的发展，数据量的迅猛增加，且用户对系统在线时间的要求越来越高。
SQL Server 2012 AlwaysOn Failover Cluster安装部署文档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. 可用性模式➢同步提交同步提交模式下，主数据库事务提交前，通知辅数据库，直到辅数据库提交成功后，主数据库成功提交。
优点：数据受到完整保护，不会存在数据不一致。
缺点：事务执行时间延长，效率降低。
➢异步提交异步提交模式下，主数据库独立提交事务，不必等待辅数据库同步，同时将数据写入日志，辅数据库通过事务日志同步数据。
优点：事务执行时间不受辅数据库影响，效率高。
缺点：数据同步存在延时。
1.2. 故障转移模式➢手动转移(不存在数据丢失)主、辅库都是同步提交模式，且故障转移为手动，由SSMS发起FailOver命令。
➢自动转移(不存在数据丢失)主、辅库都是同步提交模式，且故障转移为自动，不受人为控制，由WSFC自动仲裁。
➢强制转移(存在数据丢失)主库是异步提交模式，且故障转移为手动，由SSMS发起FailOver命令。
由于某种原因，主、辅库数据不同步，必须使用强制模式实现故障转移，此时可能存在数据丢失的情况，通常应用于突发的灾难恢复。
当主、辅库SQL实例均从灾难中恢复正常后，可以通过数据移动功能确保数据同步。
配置sqlserver2012的alwayson虚机准备：windows2012r21.分配两块⽹卡，关闭防⽕墙，配置私⽹和公⽹，添加⾓⾊：iis(asp,aspx)，故障转移,net framework,telnet客户端，注册表修改⽇期格式，激活重启。
2.安装sqlserver2012sp1版3.克隆虚机，修改主机名，加⼊域，域⽤户加⼊本地管理组4.创建故障转移集群，启⽤sqlserver的alwayson，修改启动⽤户为域⽤户，新建登录名为域⽤户赋予sysadmin⾓⾊，确保可windows⾝份登录sqlserver5.创建测试库，完整模式，创建共享⽬录赋予域⽤户，备份全库到该⽬录。
创建可⽤性组。
脚本：--- YOU MUST EXECUTE THE FOLLOWING SCRIPT IN SQLCMD MODE.运⾏cmd打开两个dos窗⼝：sqlcmd -S SQL2012-01 -U "sa" -P "xxxx"sqlcmd -S SQL2012-02 -U "sa" -P "xxxx"---------------------:Connect SQL2012-01IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0BEGINALTER ENDPOINT [Hadr_endpoint] STATE = STARTEDENDGOuse [master]GOGRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [JYC\sqlcluster]GO:Connect SQL2012-02IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0BEGINALTER ENDPOINT [Hadr_endpoint] STATE = STARTEDENDGOuse [master]GOGRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [JYC\sqlcluster]GO:Connect SQL2012-01IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')BEGINALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);ENDIF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')BEGINALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;ENDGO:Connect SQL2012-02IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')BEGINALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);ENDIF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')BEGINALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;ENDGO:Connect SQL2012-01USE [master]GOCREATE AVAILABILITY GROUP [dg]WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)FOR DATABASE [test]REPLICA ON N'SQL2012-01' WITH (ENDPOINT_URL = N'TCP://sql2012-01.jyc.local:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50,SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),N'SQL2012-02' WITH (ENDPOINT_URL = N'TCP://sql2012-02.jyc.local:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50,SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));GO:Connect SQL2012-02ALTER AVAILABILITY GROUP [dg] JOIN;GO:Connect SQL2012-01BACKUP DATABASE [test] TO DISK = N'\\SQL2012-01\data\test.bak' WITH COPY_ONLY, FORMAT, INIT, SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5GO:Connect SQL2012-02RESTORE DATABASE [test] FROM DISK = N'\\SQL2012-01\data\test.bak' WITH NORECOVERY, NOUNLOAD, STATS = 5GO:Connect SQL2012-01BACKUP LOG [test] TO DISK = N'\\SQL2012-01\data\test_20160726053541.trn' WITH NOFORMAT, NOINIT, NOSKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5GO:Connect SQL2012-02RESTORE LOG [test] FROM DISK = N'\\SQL2012-01\data\test_20160726053541.trn' WITH NORECOVERY, NOUNLOAD, STATS = 5GO:Connect SQL2012-02-- Wait for the replica to start communicatingbegin trydeclare @conn bitdeclare @count intdeclare @replica_id uniqueidentifierdeclare @group_id uniqueidentifierset @conn = 0set @count = 30 -- wait for 5 minutesif (serverproperty('IsHadrEnabled') = 1)and (isnull((select member_state from master.sys.dm_hadr_cluster_members where upper(member_name COLLATE Latin1_General_CI_AS) = upper(cast(serverproperty('ComputerNamePhysicalNetBIOS') as nvarchar(256)) COLLATE Latin1_General_CI_AS)), 0) <> 0)and (isnull((select state from master.sys.database_mirroring_endpoints), 1) = 0)beginselect @group_id = ags.group_id from master.sys.availability_groups as ags where name = N'dg'select @replica_id = replicas.replica_id from master.sys.availability_replicas as replicas whereupper(replicas.replica_server_name COLLATE Latin1_General_CI_AS) = upper(@@SERVERNAME COLLATE Latin1_General_CI_AS) and group_id = @group_idwhile @conn <> 1 and @count > 0beginset @conn = isnull((select connected_state from master.sys.dm_hadr_availability_replica_states as states where states.replica_id = @replica_id), 1)if @conn = 1begin-- exit loop when the replica is connected, or if the query cannot find the replica statusbreakendwaitfor delay '00:00:10'set @count = @count - 1endendend trybegin catch-- If the wait loop fails, do not stop execution of the alter database statementend catchALTER DATABASE [test] SET HADR AVAILABILITY GROUP = [dg];GOGO。
可用性组在可用性副本级别进行故障转移。
故障转移不是由诸如因数据文件丢失而使数据库成为可疑数据库、删除数据库或事务日志损坏等此类数据库问题导致的。
1.2 AlwaysOn 可用性组的优点优点：AlwaysOn 可用性组提供了一组丰富的选项来提高数据库的可用性并改进资源使用情况。
主要组件如下：•支持最多五个可用性副本“可用性副本”是可用性组的实例化，此可用性组由特定的SQL Server 实例承载，该实例维护属于此可用性组的每个可用性数据库的本地副本。
每个可用性组支持一个主副本和最多四个辅助副本。
说明：每个可用性副本都必须驻留在单个Windows Server 故障转移群集(WSFC) 群集的不同节点中。
•支持替代可用性模式，如下所示：o异步提交模式。
此可用性模式是一种灾难恢复解决方案，适合于可用性副本的分布距离较远的情况。
o同步提交模式。
此可用性模式相对于性能而言更强调高可用性和数据保护，为此付出的代价是事务延迟时间增加。
一个给定的可用性组可支持最多三个同步提交可用性副本（包括当前主副本）。
•支持几种形式的可用性组故障转移自动故障转移、计划的手动故障转移（通常简称为“手动故障转移”）和强制的手动故障转移（通常简称为“强制故障转移”）。
•将特定的可用性副本配置为支持以下一种或两种活动辅助功能：o利用只读连接访问，与副本的只读连接可以在此副本作为辅助副本运行时访问和读取其数据库。
o当副本作为辅助副本运行时，对副本的数据库执行备份操作。
提示：通过使用活动辅助功能，可更好地利用辅助硬件资源，从而提高IT 效率并降低成本。
此外，通过将读意向应用程序和备份作业转移到辅助副本，有助于提高针对主副本的性能。
•支持每个可用性组的可用性组侦听器“可用性组侦听器”是一个服务器名称，客户端可连接到此服务器以访问AlwaysOn 可用性组的主副本或辅助副本中的数据库。
可用性组侦听器将传入连接定向到主副本或只读辅助副本。
侦听器在可用性组故障转移后提供快速应用程序故障转移。
Microsoft SQL Server 2012 AlwaysOn高可用性解决方案1.术语定义1)高可用性：HA（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性2)灾难恢复：DR（Disaster Recovery）指自然或人为灾害后，重新启用信息系统的数据、硬件及软件设备，恢复正常商业运作的过程3)故障转移群集：WSFC（Windows Server Failover Cluster）微软操作系统针对服务器提供的一种服务，该服务用于防止单台服务器故障导致服务失效。
2.公司数据库使用现状及问题瓶颈其他部门对应用开发部负责的融资管理系统性能提出以下问题：1)数据部：a)服务器不稳定b)数据库性能配置低2)市场部：a)查询效率太低3)产品部：a)报表、BI支撑难这些性能问题无不涉及到后台数据库的性能及可靠性问题。
还有一个安全问题也值得重视。
目前，公司产品数据库和融资管系统都部署在10.44.1.3一台服务器上。
理论上，产品数据库不应与Web应用部署在同一台机器而暴露给用户，产品数据库最好只交由专职DBA 来管理。
因为，万一Web应用遭受黑客攻击，产品数据将会面临巨大威胁，甚至有可能被永久性物理删除。
前不久，就有报道携程数据遭受有预谋的内部攻击被物理删除（/20150528/n413987338.shtml）。
如果分开部署，那么即使Web应用遭受攻击，只要产品数据在，我们仍然可以在短时间内部署新的Web应用。
3.SQL Server 高可用技术简介1)故障转移群集(Failover Cluster)共享存储，效率高，但某一个时间点只有一个节点处于活动状态，造成硬件资源浪费。
2)数据库镜像(Database Mirror)提供几乎是瞬时的故障转移，以提高数据库的可用性。
但其最大弊端在于镜像数据库处于不可读状态，同样造成硬件资源浪费。
3)日志传送(Log Shipping)还原作业之间的间隔时间内的只读访问权限，可用做报表查询。
一般用于远程的异步容灾，存在部分数据丢失的可能性。
4)复制(Replication)基于数据库对象级别，灵活性较高，但弊端在于，它不支持DDL命令，不便维护。
5)AlwaysOnAlwaysOn是SQL Server 2012中提供的一种全新的高可用性技术，其集中了上述4种高可用性技术的优点，以确保企业无需增加成本和提高复杂度，即可实现最高级别的可用性和数据保护。
可在数据中心内部以及跨数据中心实现数据冗余，快速地实现应用程序故障转移，保护现有硬件资源，同时简化了其配置过程。
AlwaysOn可以实现服务器实例级和数据库级配置高可用性，所对应的技术就是AlwaysOn故障转移群集实例和AlwaysOn可用性组。
下图1展示了使用Alwayson可用性组的HA 和DR 解决方案图14.AlwaysOn高可用性技术介绍1)AlwaysOn 故障转移群集实例一般来说，在单服务器情况下，当服务器上出现硬件或软件故障时，连接到该服务器的应用程序或客户端将会停机。
在AlwaysOn故障转移群集实例环境中，SQL Server 实例的高可用性受到冗余节点的保护。
在群集环境中，一次只能有一个节点拥有群集的资源组。
在出现故障(硬件故障、操作系统故障、应用程序或服务故障)或进行计划的升级时，该资源组的所有权就会转移至另一个群集节点。
此过程对于连接到SQL Server 的客户端或应用程序是透明的，可以最大限度地缩短出现故障时应用程序或客户端的停机时间。
因此AlwaysOn故障转移群集实例必须由一组物理服务器节点构成，这些服务器节点推荐使用类似的硬件配置以及相同的软件配置，如操作系统的版本、SQL Server 版本、修补程序级别、组件以及实例名称。
相同的配置是确保群集在节点间进行故障转移时能够正常运行的前提条件。
SQL Server 2012在原有SQL Server故障转移群集的基础上功能得到了进一步的增强，支持跨越子网实现多站点群集，此技术一般用于两个或两个以上的数据中心，以同时提供本地高可用性和远程的灾难恢复。
其中，每个故障转移群集节点都连接到其他子网或其他子网组。
这些子网可以处于同一位置中，也可以位于地理上分散的站点。
跨地理上分散的站点进行群集有时又被称为扩展群集。
因为没有供所有节点都可以访问的共享存储，所以在多个子网上的数据存储之间应该复制数据。
因此，多子网故障转移群集除了具备高可用性之外，还提供了灾难恢复解决方案。
下面以图例说明：图2在上图中共有两个数据中心并且处于不同子网，本地数据中心subnet1使用的IP地址是10.168.0.10，当本地数据中心发生故障时，SQL Server服务会转移到远程数据中心，远程数据中心subnet2所使用的是不同IP地址，为192.168.0.10来继续提供数据库服务，这两个IP地址之间是OR的关系，也就是说这两个IP地址任意一个在线的话，虚拟网络名称SQLClus都可以正常的向客户端提供服务。
在此需要使用到存储级别的复制技术，将本地数据中心数据库中的数据文件及日志文件复制到远程数据中心，当本地数据中心发生故障时，Windows 群集检测到故障，远程数据中心存储软件可以检测到复制失效，会将存储转换为读写状态，接下来Windows群集会将远程站点可读写的存储设备挂接到远程的Cluster节点上，此时存储复制的方向就从远程数据中心向本地数据中心复制。
也就是说，故障转移群集实例成功启动后，Windows群集服务将监视基础群集的运行状况和SQL Server 实例的运行状况。
SQL Server 2012中允许群集服务使用专用连接来轮询活动SQL Server 实例，以便通过系统存储过程获取详细的组件诊断信息。
好处是，利用与SQL Server 实例的专用连接，能够对组件诊断信息进行可靠轮询，即使在故障转移群集实例负荷较重时也是如此。
利用详细的组件诊断信息，可以配置更灵活的故障转移策略，由此用户能选择哪些故障条件将触发故障转移以及哪些故障条件将不触发故障转移。
用户利用产生的诊断信息，还可以通过追溯方式更好地对自动故障转移进行故障排除。
此诊断信息将存储到与SQL Server 错误日志并置的日志文件中。
可以将这些日志文件加载到日志文件查看器中以检查导致出现故障转移的组件状态，从而确定导致该故障转移的原因。
2)AlwaysOn可用性组AlwaysOn可用性组是SQL Server 2012中提供的全新功能，确保了应用程序数据的可用性，实现零数据丢失。
AlwaysOn可用性组技术融合了数据库群集和数据库镜像的优点，此技术的一大好处是提供非共享存储，可以避免因为存储的单点故障而造成的整个可用性方案失效。
AlwaysOn可用性组基于数据库(组)级别，是将一组用户数据库(可以是一个或多个)划到一个组中。
每组可用性数据库都由一个可用性副本承载。
可用性副本包括一个主副本和一到四个辅助副本（2014最多支持8个）。
主副本用于承载主数据库，辅助副本则承载一组辅助数据库并作为可用性组的潜在故障转移目标。
主副本使主数据库可用于客户端的读写连接，实现对数据库的更改操作。
同时在数据库级别进行同步。
主副本将每个主数据库的事务日志记录发送到每个辅助数据库。
每个辅助副本缓存事务日志记录，然后将它们还原到相应的辅助数据库。
主数据库与每个连接的辅助数据库独立进行数据同步。
因此，一个辅助数据库可以挂起或失败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。
此外，用户可以借助辅助数据库来实现近实时的报表查询，将查询的负载分担到只读副本。
相对于数据库群集及镜像来说，可以更好的利用硬件资源，从而提高IT效率并降低成本。
下面看一下AlwaysOn可用性组架构，如下图3所示：图3部署AlwaysOn 可用性组需要一个Windows Server 故障转移群集(WSFC) 群集。
给定可用性组的每个可用性副本必须位于相同WSFC 群集的不同节点上。
部署AlwaysOn可用性组时，系统会为每个可用性组创建一个WSFC 资源组。
WSFC 群集将监视此资源组，判断节点间的状态，以便评估主副本的运行状况。
当发生失败时实现故障的转移，针对AlwaysOn 可用性组的仲裁基于WSFC 群集中的所有节点，而与某一给定群集节点是否承载任何可用性副本无关。
用户可以通过创建一个可用性组侦听器来提供到给定可用性组的主副本的客户端连接。
“可用性组侦听器”采用DNS名称的方式连接给定可用性组的资源，以便将客户端连接定向到相应的可用性副本。
对于每个可用性副本，AlwaysOn所支持的事务提交模式分为同步提交模式或异步提交模式。
在异步提交模式下，主副本无需等待确认异步提交辅助副本已强制写入日志，便可提交事务。
异步提交模式可最大限度地减少辅助数据库上的事务滞后时间，但允许它们滞后于主数据库，因此可能会导致某些数据丢失。
此可用性模式是一种灾难恢复解决方案，适合于可用性副本的分布距离较远的情况。
所谓同步提交模式是指在提交事务之前，同步提交主副本要等待同步提交辅助副本确认它已完成强制写入日志。
同步提交模式可确保在给定的辅助数据库与主数据库同步时，充分保护已提交的事务。
这种保护的代价是延长事务滞后时间。
此可用性模式相对于性能而言更强调高可用性和数据保护，当主副本和辅助副本距离较近时可以使用此方法，解决时时同步的问题。
正因为AlwaysOn可用性组集现有高可用性技术的优点于一身，不得不说，它是SQL Server 2012新特性中最为璀璨的一个。
5.东方融资网可实施的AlwaysOn测试部署方案1)宿主机宿主使用工作站（HYPR-V），其基本配置如下：b)处理器：Intel(R)Core(TM)*******************.20GHzc)内存(RAM)：8.00GBd)Windows版本：Windows Server 2012 R2 Standard2)虚拟机配置数据库服务器基本配置：4个逻辑cpu，1G内存，100G硬盘(C:70G;D:30G)3)AlwaysOn可用性组安装配置架构图如下图所示，一个windows群集clustest01中包含三个节点（server01，server02）节点01和节点02组成SQL Server群集，实现实例级别的自动故障转移和AlwaysOn可用性组，可用性组添加侦听IP[192.168.1.130]，用于客户端的连接，以实现可用组切换而不用修改客户端连接配置。
图44)Windows群集安装将三个服务器都加入域环境中；并安装.Net 3.5和故障转移群集功能后，开始创建新群集。
