SQLServerAlwaysOn架构及原理
sqlserver数据库高可用的原理
SQL Server数据库高可用（High Availability，HA）是指在数据库系统出现故障时，能够保证系统能够继续提供服务，不会影响到用户的正常使用。
SQL Server提供了多种实现高可用的方式，其中最常用的是以下两种：1. 数据库镜像（Database Mirroring）：数据库镜像是SQL Server提供的一种高可用性解决方案。
它通过将一个数据库的更改实时复制到另一个数据库中，从而保证了数据的同步性和可用性。
在数据库镜像中，有一个主数据库和一个或多个副本数据库，主数据库负责接受写入请求，副本数据库负责接受读取请求。
当主数据库发生故障时，副本数据库会自动接管主数据库的工作，从而保证了系统的可用性。
2. Always On 可用性组（Always On Availability Groups）：Always On 可用性组是SQL Server 2012及以上版本提供的一种高可用性解决方案。
它通过将一个或多个数据库实例组成一个可用性组，并使用异步或同步数据复制来保证数据的同步性和可用性。
在Always On 可用性组中，有一个主数据库和多个副本数据库，主数据库负责接受写入请求，副本数据库负责接受读取请求。
当主数据库发生故障时，副本数据库会自动接管主数据库的工作，从而保证了系统的可用性。
无论是数据库镜像还是Always On可用性组，都需要使用一些技术和组件来实现高可用性。
其中包括：1. 数据库镜像：数据库镜像需要使用数据库镜像技术和数据库镜像组件来实现数据同步和故障切换。
2. Always On可用性组：Always On可用性组需要使用异步或同步数据复制技术和Always On 可用性组组件来实现数据同步和故障切换。
3. 数据库日志：无论是数据库镜像还是Always On可用性组，都需要使用数据库日志来记录数据库的操作，以便在发生故障时进行数据恢复。
4. 故障转移：无论是数据库镜像还是Always On可用性组，都需要使用故障转移技术来实现故障切换。
sqlserver allwayson 原理
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会自动进行故障转移。
故障转移的过程包括以下几个步骤：首先，自动故障检测会检测到主数据库的故障，并将主数据库标记为不可用；然后，系统会启动一个辅助数据库来接管访问请求；最后，其他辅助数据库会重新选举一个新的主数据库，并继续提供服务。
SQLServer2016AlwaysOn总结整理
SQLServer2016AlwaysOn总结整理⼀、Always On简介从SQL Server 2012开始，SQLServer引⼊了⼀种新的⾼可⽤技术，它的名字叫做AlwaysOn。
AlwaysOn在开发初期代号叫做HADRon。
但是AlwaysOn相对于故障转移群集、数据库镜像和⽇志传送⽽⾔，的确是拥有许多优势。
甚⾄可以说，AlwaysOn是这三种技术的集⼤成者。
想要了解更全⾯的介绍和技术内容，可参考《SQL Server 2012 实践与管理实战指南》和官⽅⽂档。
⼆、Always On 构建SQL Server 2016 Always On 可以在域环境、⾮域环境构建，从构建⾓度来看，最⼤的不同之处是AG间主要副本和辅助副本间数据同步时，数据库实例间认证⽅式存在差异。
域环境可以使⽤Windows认证、证书认证，⾮域环境可使⽤证书认证。
此处只讨论域环境下两个节点的Always On构建及维护。
1、环境准备(1)域账号AD\Administrator --域管理账户，⽤于创建WSFC集群AD\sqladmin --普通域账户，⽤于SQL Server 服务运⾏(2)软件SQL Server 2016 SP2 --直接使⽤SP2版本，打补丁只需打⼀次SQL Server补丁（CU14） --从官⽹下载最新的补丁(3)服务器主机名NA1NA2业务⽹段IP192.168.10.131192.168.10.132⼼跳⽹段IP192.168.20.131192.168.20.132存储⽹段IP192.168.30.131192.168.30.132操作系统Windows Server 2016Windows Server 2016备注:· 两台服务硬件配置、系统环境⼀致· 实际⽣产中，存储可能不是通过这种⽅式连接主机的· 业务⽹段⽹卡，需要“禁⽤TCP/IP上的NetBIOS",否正在创建可⽤性组侦听时会报错（具体原因待深究）。
SQL2012 AlwaysON配置说明
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可用性及故障转移
SQL Server AlwaysOn可用性及故障转移2014-03-27 01:55:04标签：高可用数据库日志记录原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明。
否则将追究法律责任。
/382644/1384835SQL Server AlwaysOn可用性及故障转移杜飞在AlwaysOn 可用性组中，“可用性模式”是一个副本属性，该属性确定某一给定可用性副本是否可在同步提交模式下运行。
AlwaysOn的可用性模式决定了各副本之间是否允许存在数据差异，SQL Server2012的可用性组使用异步提交模式和同步提交模式来决定主副本在提交事务之前是否等待辅助副本将事务日志记录固化到磁盘。
如果主副本配置为“异步提交模式”，则它不会等待任何辅助副本将传入的事务日志记录写入磁盘（以便“强制写入日志”）。
如果某一给定的辅助副本配置为异步提交模式，则主副本不会等待该辅助副本强制写入日志。
如果主副本和某一给定辅助副本都配置为“同步提交模式”，则主副本将等待辅助副本，以便确认它已强制写入日志（除非辅助副本在主副本的“会话超时期限”内未能使用ping 命令联系上主副本）。
同步提交模式在同步提交模式下，主数据库在提交事务之前，主副本要等待同步提交辅助副本确认它已将日志固化到磁盘上。
只要辅助副本还没有告诉主副本日志固化完成，主副本上的事务就不能提交。
这样就保证两边的数据始终是同步的。
只要一直在进行数据同步，辅助数据库就会保持“已同步”(SYNCHRONIZED)的状态。
同步提交模式能够保证给定的辅助数据库与主数据库上的数据保持完全的同步。
但是代价是主数据库上的事务提交会有滞后时间。
可以说，同步提交模式相对于性能而言更强调高可用性。
辅助副本的同步工作原理：在同步提交模式下，在辅助副本联接可用性组并与主副本建立会话之后，辅助副本会将传入日志记录写入到磁盘（“固化日志”）并向主副本发送确认消息。
sqlserver2019 alwayson方案
sqlserver2019 alwayson方案SQL Server 2019 Always On方案简介•SQL Server 2019 Always On是一种高可用性和灾备解决方案，可确保数据库始终可用并具备故障恢复能力。
•本方案将介绍SQL Server 2019 Always On的一些关键概念和步骤，以及如何实施和管理这一方案。
概念1.Always On可用性组–由一个主数据库和多个辅助数据库组成的集合，用于提供故障转移和自动故障恢复。
2.同步复制–主数据库的改变会立即传输到辅助数据库，确保数据的一致性。
3.异步复制–主数据库的改变会按一定的延迟传输到辅助数据库，适用于需要高可用性但能够容忍一定数据丢失的场景。
4.可读辅助–辅助数据库允许读取操作，提高系统的性能和可扩展性。
5.自动故障转移–当主数据库不可用时，Always On自动将辅助数据库提升为主数据库，以保证系统的连续可用性。
实施步骤1.确保满足系统要求–确保服务器硬件要求、操作系统、SQL Server版本和数据库设置符合SQL Server 2019 Always On的要求。
2.配置Windows故障转移群集–在服务器中启用和配置Windows故障转移群集，以便在主从切换时提供服务的连续性。
3.创建可用性组–在SQL Server Management Studio中创建可用性组，并选择主数据库和辅助数据库。
4.配置数据库复制–配置可用性组中的数据库复制设置，选择同步或异步复制模式，并配置辅助数据库的可读性。
5.测试故障转移–在故障维护期间测试自动故障转移功能，确保主从切换时系统能够按预期工作。
6.监控和管理–使用SQL Server Management Studio或其他监控工具来定期监控和管理可用性组的状态和性能。
注意事项•SQL Server 2019 Always On部署需要额外的硬件和资源，确保服务器足够强大以支持复制和故障转移操作。
SQL Server关于AlwaysOn的理解-读写分离的误区(一)
SQL Server关于AlwaysOn的理解-读写分离误区(一)很多人认为AlwaysOn在同步提交模式下数据是实时同步的，也就是说在主副本写入数据后可以在辅助副本立即查询到。
因此期望实现一个彻底的读写分离策略，即所有的写语句在主副本上，所有的只读语句分离到辅助副本上。
这是一个认知误区，本文通过原理和测试进行解释。
实现原理从下图可以看到，在同步提交模式下，主副本产生的日志被同步并固化到辅助副本的日志文件后，主副本的事务就会提交。
辅助副本再通过异步的REDO线程把日志转换为数据，因此数据在辅助节点是有滞后的。
要强调的是，这种实现原理是为了对主副本上的写入操作的性能影响最小化，并不会导致数据丢失。
当主副本出现故障后，辅助副本切换成主副本时有一个数据库恢复阶段，用来把异步REDO线程没有处理完的日志转换成数据，完成后数据和原主副本是一致的。
因此不会丢失数据，只是稍微增加了一点故障转移的时间。
测试创建一个AlwaysOn可用性组，2个同步提交的副本，Node1为主副本，Node2为辅助副本。
在数据库db1中创建一张表。
写一个测试工具，首先建立到主副本数据库的连接，插入一行数据并获取新插入行的自增列的值，然后根据配置的等待时间进行线程等待，最后建立到辅助副本数据库的连接，查找新插入的这条数据是否已经存在，如存在成功数加1，不存在失败数加1。
配置等待时间为0，也就是在主副本插入完数据后立即到辅助副本去查询，可以看到成功的非常少，绝大多数都是查不到的。
把等待时间增加到500毫秒，还有一半失败的。
直到增加到1000毫秒，才会全部成功。
总结通过原理和测试，我们理解到数据在辅助副本是有滞后的，而且滞后时间是不确定的，和硬件环境、日志大小、并发数等都有关系。
同一个查询语句在主副本和辅助副本的查询结果可能是不同的，导致对数据实时性非常敏感的业务逻辑出现问题。
因此很多人所期望的彻底的读写分离策略（写操作在主副本上，只读查询全部分离到辅助副本上）是不能实现的。
SQL Server AlwaysOn架构及原理
SQL Server AlwaysOn架构及原理SQL Server2012所支持的AlwaysOn技术集中了故障转移群集、数据库镜像和日志传送三者的优点，但又不相同。
故障转移群集的单位是SQL实例，数据库镜像和日志传送的单位是单个用户数据库，而AlwaysOn支持的单位是可用性组，每个组中可以包括一个或者是多个用户数据库。
也就是说，一旦发生切换，则可用性组中的所有数据组会作为一个整体进行切换。
AlwaysOn底层依然采用Windows 故障转移群集的机制进行监测和转移，因此也需要先建立Windows Cluster，只不过可用性组中的数据库不一定非要再存放在共享存储上了。
可以是存储在本地磁盘上。
AlwaysOn的关键特性：1. 同故障转移群集一样，也需要一个虚拟网络名称用于客户端的统一连接。
2.一个主服务器可以最多对应四个辅助服务器，总数达到五个，而且辅助服务器支持只读功能。
3.辅助服务器可以独立执行备份和DBCC维护命令。
通过配置，可以实现客户端的只读请求可以被自动定向到辅助服务器。
4.主服务器和辅助服务器之间的数据会被加密和压缩，以提高安全性和网络传输效率。
5..支持自动、手动和强制三种故障转移方式。
6.有仪表盘用于监控AlwaysOn的运行状态。
7.可以实现多站点的部署，即主站点和辅助站点可以跨物理网络。
AlwaysOn的基本架构在Windows MSCS故障转移群集的基础上部署AlwaysOn高可用组，用户可以在群集节点上安装SQL Server单机实例，也可以安装SQL Server群集实例，AlwaysOn仅要求所有SQL Server实例都运行在同一个MSCS中，但SQL Server 实例本身是不需要群集模式的，这与SQL Server2008 群集的实例完全不同。
在此推荐使用单机模式的SQL Server，好处是：可用性副本是个单机实例，那么数据库副本就存放在该运行该实例节点的本地磁盘上；如果可用性副本是个群集实例，那么数据库副本就存放在共享磁盘上。
sqlserver alwayson无域的原理
sqlserver alwayson无域的原理SQL Server Always On是一种高可用性和灾备解决方案，可以确保数据库系统的持续可用性和数据完整性。
而Alwayson无域则是在构建Always On解决方案时不要求必须加入Windows域的一种配置方式。
本文将详细介绍SQL Server Always On和Always On无域的原理。
I. SQL Server Always OnSQL Server Always On是一个高可用性和灾备解决方案，能够确保数据库系统在面临硬件、软件或网络故障时依然可用。
它采用了故障切换、数据冗余和可容错的设计思想，使得数据库能够无缝切换到备用服务器并继续提供服务。
1. 部署环境：- 主服务器：担任数据库的主要角色，并处理用户的请求。
- 辅助服务器：作为备用服务器，通过与主服务器同步数据，以便在主服务器发生故障时接管服务。
2. 数据同步：在Always On中，主服务器和辅助服务器之间通过日志重放技术来保持数据的同步。
主服务器将每个事务都记录到一个事务日志中，并将这些日志记录传输给辅助服务器。
辅助服务器将事务日志逐个应用到数据库上，确保数据的一致性。
3. 心跳机制：Always On还通过心跳机制来确认主服务器和辅助服务器之间的连接状态。
通过定期发送心跳消息，服务器可以及时检测到对方的状态，并做出相应的处理。
4. 自动故障切换：当主服务器发生故障时，Always On能够自动进行故障切换，将辅助服务器提升为主服务器，并启动一个新的辅助服务器作为备用。
这个过程是透明的，并且不会影响用户的服务。
5. 数据完整性：Always On通过使用多个复制策略和检测机制来确保数据的完整性。
它采用了同步复制和异步复制两种方式，以满足不同的数据冗余需求。
此外，还可以配置监控和报警机制，用于检测数据不一致或服务器故障等现象。
II. Always On无域Always On无域是指在构建Always On解决方案时不要求必须加入Windows 域的一种配置方式。
SQLServerAlwaysOn读写分离配置图文教程
SQLServerAlwaysOn读写分离配置图⽂教程概述Alwayson相对于数据库镜像最⼤的优势就是可读副本，带来可读副本的同时还添加了⼀个新的功能就是配置只读路由实现读写分离；当然这⾥的读写分离稍微夸张了⼀点，只能称之为半读写分离吧！看接下来的⽂章就知道为什么称之为半读写分离。
数据库：SQLServer2014db01:192.168.1.22db02:192.168.1.23db03:192.168.1.24监听ip:192.168.1.25配置可⽤性组可⽤性副本概念辅助⾓⾊⽀持的连接访问类型1.⽆连接不允许任何⽤户连接。
辅助数据库不可⽤于读访问。
这是辅助⾓⾊中的默认⾏为。
2.仅读意向连接辅助数据库仅接受ApplicationIntent=ReadOnly的连接,其它的连接⽅式⽆法连接。
3.允许任何只读连接辅助数据库全部可⽤于读访问连接。
此选项允许较低版本的客户端进⾏连接。
主⾓⾊⽀持的连接访问类型1.允许所有连接主数据库同时允许读写连接和只读连接。
这是主⾓⾊的默认⾏为。
2.仅允许读/写连接允许ApplicationIntent=ReadWrite或未设置连接条件的连接。
不允许ApplicationIntent=ReadOnly的连接。
仅允许读写连接可帮助防⽌客户错误地将读意向⼯作负荷连接到主副本。
配置语句---查询可⽤性副本信息SELECT * FROM master.sys.availability_replicas---建⽴read指针 - 在当前的primary上为每个副本建⽴副本对于的tcp连接ALTER AVAILABILITY GROUP [Alwayson22]MODIFY REPLICA ONN'db01' WITH(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://:1433'))ALTER AVAILABILITY GROUP [Alwayson22]MODIFY REPLICA ONN'db02' WITH(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://:1433'))ALTER AVAILABILITY GROUP [Alwayson22]MODIFY REPLICA ONN'db03' WITH(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://:1433'))----为每个可能的primary role配置对应的只读路由副本--list列表有优先级关系，排在前⾯的具有更⾼的优先级,当db02正常时只读路由只能到db02，如果db02故障了只读路由才能路由到DB03ALTER AVAILABILITY GROUP [Alwayson22]MODIFY REPLICA ONN'db01' WITH(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('db02','db03')));ALTER AVAILABILITY GROUP [Alwayson22]MODIFY REPLICA ONN'db02' WITH(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('db01','db03')));--查询优先级关系SELECT ar.replica_server_name ,rl.routing_priority ,( SELECT ar2.replica_server_nameFROM sys.availability_read_only_routing_lists rl2JOIN sys.availability_replicas AS ar2 ON rl2.read_only_replica_id = ar2.replica_idWHERE rl.replica_id = rl2.replica_idAND rl.routing_priority = rl2.routing_priorityAND rl.read_only_replica_id = rl2.read_only_replica_id) AS 'read_only_replica_server_name'FROM sys.availability_read_only_routing_lists rlJOIN sys.availability_replicas AS ar ON rl.replica_id = ar.replica_id注意：这⾥只是针对可能成为主副本的⾓⾊进⾏配置，这⾥没有给db03配置只读路由列表，原因是不想将主副本切换到DB03上⾯来，配置越多的主副本意味着你后⾯要做越多的事情包括备份、作业等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SQL Server Always On 架构及原理
SQLServer2012所支持的AlwaysOn技术集中了故障转移群集、数据库镜像和日志传送三者的优点，但又不相同。
故障转移群集的单位是SQL实例，数据库镜像和日志传送的单位是单个用户数据库，而AlwaysOn支持的单位是可用性组，每个组中可以包括一个或者是多个用户数据库。
也就是说，一旦发生切换，则可用性组中的所有数据组会作为一个整体进行切换。
Always On底层依然采用Win dows故障转移群集的机制进行监测和转移，因此也需要先建立Windows Cluster，只不过可用性组中的数据库不一定非要再存放在共享存储上了。
可以是存储在本地磁盘上。
Always On的关键特性：
1. 同故障转移群集一样，也需要一个虚拟网络名称用于客户端的统一连接。
2. 一个主服务器可以最多对应四个辅助服务器，总数达到五个，而且辅助服务器支持只读功能。
3. 辅助服务器可以独立执行备份和DBCC隹护命令。
通过配置，可以实现客户端的只读请求可以被自动定向到辅助服务器。
4. 主服务器和辅助服务器之间的数据会被加密和压缩，以提高安全性和网络传输效率。
5..支持自动、手动和强制三种故障转移方式。
6. 有仪表盘用于监控Always On的运行状态。
7. 可以实现多站点的部署，即主站点和辅助站点可以跨物理网络。
Always On的基本架构
在Windows MSC故障转移群集的基础上部署AlwaysOn高可用组，用户可以在群集节点上安装SQL Server单机实例，也可以安装SQL Server群集实例，Always On仅要求所有SQL Server实例都运行在同一个MSC中，但SQL Server 实例本身是不需要群集模式的，这与SQLServer2008群集的实例完全不同。
在此推荐使用单机模式的SQL Server，好处是：可用性副本是个单机实例，那么
数据库副本就存放在该运行该实例节点的本地磁盘上；如果可用性副本是个群集
实例，那么数据库副本就存放在共享磁盘上。
可用性组从Windows群集角度来看，就是一个群集资源，其中的所有数据库作为一个整体在节点间进行故障转移，当然这不包括系统数据库，系统数据库
是不能加入高可用性组中的。
因为需要借助Windos群集实现监控和转移，所以AlwaysOn会受到一些限制：
一个可用性组中的所有可用性副本必须运行在单一的Win dows群集上，跨不同Windows群集的SQL Server实例不能配置成一个AlwaysOn可用性组。
一个可用性组的所有可用性副本必须运行在Win dows群集的不同节点上。
运行在同一个节点上的两个不同实例不能用作同一个可用性组的副本。
如果某个可用性副本实例是一个SQL群集实例，那同一个SQL群集的其他非活跃节点上安装的任何其他SQL实例都不能作为它的辅助副本。
一个数据库只能属于一个可用性组。
Always On最多可以支持五个副本，但只有一个可用性副本上运行的数据库是处于可读写状态。
这个可读写的数据库被称为主数据库(PrimaryDatabase)，同时这个可用性副本被称为主副本 (primaryreplica )。
其余的副本都被称为辅助副本(secondaryreplica )，辅助副本上的数据库可能是不可访问的，或者是只能接受只读操作(取决于可用性组的配置)，这些数据库被称为辅助数据库。
一但发生故障转移，任何一个辅助副本都可以成为新的主副本实例。
主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。
下图就显示了一个可用性组中各副本之间的关系。
windows Server戎■誓怖轩尊(WSK)带璋
T4 04
列L server SQL Mnrer 冥氈
主粗MUM*
刁
下图展示了Always。
n可用性组与Win dows故障转移群集之间的关系，在这个图中，Windows的故障转移群集使用到了两个子网，在左边的子网里，有两个节点；右边的子网里有三个节点，其中最右边两个节点上创建了一个SQLServer 的群集实例，存放于共享存储；其他三个节点安装的是单机实例，存放于本地存储；一共四个实例组成了一个AlwaysOn可用性组，其中一个主副本，其他的都是辅助副本。
WindowsSener 二屮韧：(WSFC)::
侦听器
AlwaysOn 创建后，客户端就需要进行连接，为了让应用程序能够透明地连 接到主副本而不受故障故障转移的影响，我们需要创建一个侦听器，侦听器就是 一个虚拟的网络名称，可以通过这个虚拟网络名称访问可用性组， 而不用关心连 接的是哪一个节点，它会自动将请求转发到主节点，当主节点发生故障后，辅助 节点会变为主节点，侦听器也会自动去侦听主节点。
一个侦听器包括虚拟IP 地址、虚拟网络名称、端口号三个元素，一旦创建成功， 虚拟网络名称会注册到DNS 中，同时为可用性组资源添加IP 地址资源和网络名 称资源。
用户就可以使用此名称来连接到可用性组中。
与故障转移群集不同，除 了使用虚拟网络名称之外，主副本的真实实例名还可以被用来连接。
SQL Server2012早期版本的SQL Server 只有在实例启动的时候地会尝试 绑定IP 和端口，但是SQLServer2012却允许在副本实例处于运行状况的时候随
W9F
C
Iti
■山蓟€ tu
SQL S*nr«r 4M
tn
Alw^ytOn '；.
*朋I
ft
AlwfiylOn SQL Senrer
fil 坤职((4辕空啊 SQL StrTfr
时绑定新的IP地址、网络名称和端口号。
因此可以为随时为为可用性组添加侦听器，而且这个操作会立即生效。
当添加了侦听器之后，在SQL Server的错误日志中可以看到类似：在虚拟网络名称上停止和启动侦听器的消息。
要注意的是，SQLBrowse服务是不支持Listener的。
这是因为应用程序在使用Listener的虚拟网络名连接SQLServer时，是以一个默认实例的形式进行访问的（只有主机名，没有实例名），因此客户端根本就不会去尝试使用SQLBrowser月服务。
各副本间的数据同步
AlwaysOn必须要维护各副本间的数据一致性，当主副本上的数据发生变化，
会同步到辅助副本上。
这里AlwaysOn通过三个步骤来完成：步骤1:主副本记录发生变化的数据；步骤2：将记录传输到各个辅助副本；步骤3:把数据变化操作在辅助副本上执行一遍。
具体实现如下：
在主副本和辅助副本上，SQLServer都会启动相应的线程来完成相应的任
务。
对于一般的SQL Server服务器，即没有配置高可用性，会运行Log Writer 的线程，当发生数据修改事务时，此线程负责将本次操对应的日志信息记录到日志缓冲区中，然后再写入到物理日志文件。
但如果配置了AlwaysOny主副本的数据库，SQL Server会为它建立一个叫Log Scanner的线程，不间断的工作，负责将日志从日志缓冲区或日志文件里读出，打包成日志块，发送到辅助副本。
因
此可以保证发生的数据变化，不断送给各辅助副本。
辅助副本上存在固化和重做两个线程完成数据更新操作，固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本磁盘上的日志文件里，因此称为固化，然后重做线程负责从磁盘上读取日志块，将日志记录对应的操作重演一遍，
此时主副本和辅助副本上的数据就一致了。
重做线程每隔固定的时间点，会跟主
副本通信，告知自己的工作进度。
主副本由此知道两边数据的差距。
Log Scanner 负责传送日志块，不需要等待Log Writer完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据传输完成，而不需要等待重做完成，这样各自独立的设计，是尽可能减少AlwaysOn所带来的操作对数据库性能的影响。