SQL Server Alwayson概念总结

1、alwayson概念

“可用性组” 针对一组离散的用户数据库（称为“可用性数据库” ，它们共同实现故障转移）支持故障转移环境。 一个可用性组支持一组主数据库以及一至八组对应的辅助数据库(包括一个主副本和两个同步提交辅助副本)。 辅助数据库不是备份，应继续按期备份您的数据库及其事务日志。

每组可用性数据库都由一个“可用性副本” 承载。 有两种类型的可用性副本：一个“主副本” 和一到四个“辅助副本”。 它承载主数据库和一至八个“辅助副本” ，其中每一个副本承载一组辅助数据库，并用做可用性组的潜在故障转移目标。 可用性组在可用性副本级别进行故障转移。 可用性副本仅在数据库级别提供冗余 － 针对一个可用性组中的该组数据库。 故障转移不是由诸如因数据文件丢失或事务日志损坏而使数据库成为可疑数据库等数据库问题致使的。

主副本使主数据库可用于客户端的读写链接。 此外，它在称为“数据同步” 的过程当中使用，在数据库级别进行同步。 主副本将每一个主数据库的事务日志记录发送到每一个辅助数据库。 每一个次要副本缓存事务日志记录（“硬化”日志），而后将它们应用到相应的辅助数据库。 主数据库与每一个链接的辅助数据库独立进行数据同步。 所以，一个辅助数据库能够挂起或失败而不会影响其余辅助数据库，一个主数据库能够挂起或失败而不会影响其余主数据库。

或者，您能够配置一个或多个辅助副本以支持对辅助数据库进行只读访问，而且能够将任何辅助副本配置为容许对辅助数据库进行备份。

部署 Always On 可用性组 须要一个 Windows Server 故障转移群集 (WSFC) 群集。 给定可用性组的每一个可用性副本必须位于相同 WSFC 群集的不一样节点上。 惟一的例外是在迁移到另外一个 WSFC 群集时，此时一个可用性组可能会暂时跨两个群集。

为您建立的每一个可用性组建立一个 WSFC 资源组。 WSFC 群集将监视此资源组，以便评估主副本的运行情况。 针对 Always On 可用性组 的仲裁基于 WSFC 群集中的全部节点，而与某一给定群集节点是否承载任何可用性副本无关。 与数据库镜像相反，在 Always On 可用性组中没有见证服务器角色。

2、可用性模式

可用性模式是每一个可用性副本的一个属性；可用性模式肯定主副本是否须要等待辅助副本将事务日志写入到磁盘。

1.异步提交模式

异步提交模式是一种灾难恢复解决方案，适合于可用性副本的分布距离较远的状况。 若是每一个辅助副本都在异步提交模式下运行，则主副本不会等待任何辅助副本强制写入日志， 而会在将日志记录写入本地日志文件后，当即将事务确认发送到客户端。 主副本使用与针对异步提交模式配置的辅助副本相关的最小事务滞后运行。

在“异步提交模式”下，辅助副本永远不会与主副本同步。 虽然给定的辅助数据库可能会遇上对应的主数据库，但任何辅助数据库在任什么时候点均可能会落后。 对于主副本和辅助副本相隔很远并且您不但愿小错误影响主副本的灾难恢复方案的状况，或性能比同步数据保护更重要的状况，异步提交模式将会颇有用。 并且，因为主副本不会等待来自辅助副本的确认，于是辅助副本上的问题从不会影响主副本。

异步提交辅助副本会尝试与接收自主副本的日志记录保持一致。 但异步提交辅助数据库每每会保持未同步状态，而且可能稍微滞后于相应的主数据库。一般，异步提交辅助数据库和相应的主数据库之间的这个时间差会很小。可是，若是承载辅助副本的服务器的工做负荷太高或网络速度很慢，则这个时间差会变得较大。

异步提交模式所支持的惟一故障转移形式为强制故障转移（可能形成数据丢失）。 强制故障转移是一种最后手段，仅可用于当前主要副本长时间保持不可用状态而且主数据库的即时可用性比可能丢失数据的风险更为重要的状况。故障转移目标必须是其角色处于 SECONDARY 或 RESOLVING 状态的副本。 故障转移目标将转换为主角色，而且其数据库副本将成为主数据库。 任何剩余的辅助数据库以及变得可用后的之前的主数据库都将被挂起，直到您手动单独恢复它们。 在异步提交模式下，原始主副本还没有发送到之前的辅助副本的任何事务日志都将丢失。 这意味着，某些或所有新的主数据库可能会缺乏最近提交的事务

2.同步提交模式

同步提交模式相对于性能而言更强调高可用性，为此付出的代价是事务滞后时间增长。 在同步提交模式下，事务将一直等到辅助副本已将日志强制写入到磁盘中才会向客户端发送事务确认。

在同步提交可用性模式下，副本联接到某个可用性组后，辅助数据库就会与对应的主数据库求得一致并进入 SYNCHRONIZED（已同步）状态。 只要一直在进行数据同步，辅助数据库就会保持 SYNCHRONIZED 状态。 这可确保对主数据库提交的每一个事务也应用到对应的辅助数据库。在同步辅助副本上的每一个辅助数据库以后，辅助副本的同步运行状态整体上将为 HEALTHY。

注意：

1. 若是为当前主副本配置了异步提交可用性模式，那么对全部的辅助副本都采集异步方式提交事务，无论这些副本各自的可用性模式，因此要保证同步提交模式那么主副本和辅助副本都须要配置同步提交模式。

2.若是主副本与某一同步辅助会话超时，暂时将该辅助副本切换到异步提交模式。在该辅助副本从新与主副本链接后，它们将恢复同步提交模式。

3、故障转移模式

可用性副本的主角色和辅助角色在称为“故障转移” 的过程当中一般是可互换的。 存在三种故障转移形式：自动故障转移（无数据丢失）、计划的手动故障转移（无数据丢失）和强制手动故障转移（可能丢失数据）。最后一种形式一般称为“强制故障转移”

1.自动故障转移所需条件

仅在如下条件下才发生自动故障转移：

• 存在自动故障转移集。 此自动故障转移集由主要副本和次要副本（自动故障转移目标）构成，主要副本和次要副本都配置为同步提交模式而且设置为自动故障转移。若是主要副本设置为手动故障转移，即便次要副本设置为自动故障转移，也没法发生自动故障转移
• 自动故障转移目标具备正常运行的同步状态（这指示故障转移目标上的每一个辅助数据库都与其相应的主数据库同步）。
• Windows Server 故障转移群集 (WSFC) 群集具备仲裁。
• 主副本已变得不可用，而且由灵活的故障转移策略定义的故障转移条件级别已获得知足。

注意：

1.在数据库级别，诸如因数据文件丢失而使数据库成为可疑数据库、删除数据库或事务日志损坏之类的数据库问题不会致使可用性组进行故障转移

2. AlwaysOn 可用性组监视自动故障转移集中两个副本的运行情况。 若是任一副本失败，则该可用性组的运行情况状态将设置为“严重”。 若是辅助副本失败，则自动故障转移将不可行，由于自动故障转移目标不可用。 若是主副本失败，则可用性组将故障转移到辅助副本。 在以前的主副本进入联机状态以前，将不存在任何自动故障转移目标。 在任一状况下，为了在连续出现失败这种近乎不可能发生的状况下确保可用性，咱们建议您将其余辅助副本配置为自动故障转移目标。

3.要设置故障转移模式为“自动”的前提是可用性模式是“同步提交”。

4.若是主要副本设置为手动故障转移，即便次要副本设置为自动故障转移，也没法发生自动故障转移。

5.只能设置一个自动故障转移辅助副本

4、可读辅助副本

1.辅助角色支持的链接访问类型

1.无链接
不容许任何用户链接。 辅助数据库不可用于读访问。 这是辅助角色中的默认行为。

2.仅读意向链接
辅助数据库仅适用于其 Application Intent 链接属性设置为 ReadOnly 的链接（读意向链接）。

3.容许任何只读链接
辅助数据库所有可用于读访问链接。 此选项容许较低版本的客户端进行链接。

2.主角色支持的链接访问类型

1.容许全部链接
主数据库同时容许读写链接和只读链接。 这是主角色的默认行为。

2.仅容许读/写链接
当 Application Intent 链接属性设置为 ReadWrite 或未设置时，容许此链接。 不容许其 Application Intent 链接字符串关键字设置为 ReadOnly的链接。 仅容许读写链接可帮助防止您的客户错误地将读意向工做负荷链接到主副本。

注意：全部的限制只针对配置了可用性数据库，非可用性数据库不受这些链接的限制，配置读写分离至少得保证有两个可读副本，若是只有一个可读副本当可读副本变成了主副本以后会致使只读意向无副本可链接。

5、alwayson同步原理

1.任何一个SQL Server里都有个叫Log Writer的线程，当任何一个SQL用户提交一个数据修改事务时，它会负责把记录本次修改的日志信息先记入一段内存中的日志缓冲区，而后再写入物理日志文件（日志固化）,因此对于任何一个数据库，日志文件里都会有全部数据变化的记录。

2.对于配置为AlwaysOn主副本的数据库，SQL Server会为它创建一个叫Log Scanner的工做线程,这个线程专门负责将日志记录从日志缓冲区或者日志文件里中读出，打包成日志块，发送给各个辅助副本。因为它的不间断工做，才使主副本上的数据变化，能够不断地向辅助副本上传播。

3.在辅助副本上，一样会有两个线程，完成相应的数据更新动做，它们是固化（Harden）和重作（Redo）。固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本的磁盘上的日志文件里（这个过程被称为"固化"）。

而重作线程，则负责从磁盘上读取日志块，将日志记录翻译成数据修改操做，在辅助副本的数据库上完成。当重作线程完成其工做之后，辅助副本上的数据库就会跟主副本一致了。AlwaysOn就是经过这种机制，保持副本之间的同步。重作线程每隔固定的时间点，会跟主副本通讯，告知它本身的工做进度。主副本就可以知道两边数据的差距有多远。

这些线程在工做上各自独立，以达到更高的效率。Log Scanner负责传送日志块，而无须等待Log Writer完成日志固化；辅助副本完成日志固化之后就会发送消息到主副本，告知数据已经传递完毕，而无须等待重作完成。其设计目标，是尽量地减小AlwaysOn所带来的额外操做对正常数据库操做的性能影响。

同步操做按下列方式维护：

1. 从客户端收到事务后，主副本会将事务的日志写入事务日志，同时将该日志记录发送到辅助副本。
2. 日志记录写入主数据库的事务日志后，事务将不能撤消，除非在此时故障转移到还没有收到该日志的辅助副本。主副本将等待来自同步提交辅助副本的确认。
3. 辅助副本将强制写入日志（固化），并将确认消息返回给主副本。
4. 收到来自辅助副本的确认后，主副本将完成提交处理并向客户端发送一条确认消息。

6、会话超时机制

因为软错误不能由服务器实例直接检测到，所以，软错误可能致使一个可用性副本无限期等待会话中另外一个可用性副本的响应。 为了防止发生这种状况， Always On 可用性组实施了会话超时机制，此机制基于如下条件：所链接的可用性副本会在每一个打开的链接上按固定间隔发送 ping。 在超时期限内收到 ping 指示链接还是开放的且服务器实例正在经过此链接进行通讯。 收到 ping后副本将重置此链接上的超时计数器。主副本和辅助副本相互 ping 以指示它们仍处于活动状态， 会话超时限制是用户可配置的副本属性，默认值为 10 秒。

若是在会话超时期限内没有收到来自另外一个副本的ping，该链接将超时、链接将关闭；超时的副本进入 DISCONNECTED 状态。 即便为同步提交模式的副本，事务也将不等待该副本从新链接暂时将该辅助副本切换到异步提交模式。在该辅助副本从新与主副本链接后，它们将恢复同步提交模式。

总结

理解掌握这些概念对部署维护AlwaysOn集群很是的有帮助，能够结合测试对概念更深刻的理解。

 

注意： 域服务器宕机了也不影响使用SQLServer身份验证链接副本或者监听器，Windows身份验证会受影响。因此只要不故障切换AD宕机了也不影响AlwaysOn群集的链接。这个功能减小了AlwaysON对AD的依赖，同时也减小建双域控的成本。

 

针对AlwaysON可用性组的先决条件和限制：https://msdn.microsoft.com/zh-cn/library/ff878487(v=sql.120).aspx

搭建和加入域参考：http://www.cnblogs.com/chenmh/p/4444168.html

搭建故障转移群集参考：http://www.cnblogs.com/chenmh/p/4479304.html

Alwayson搭建参考：http://www.cnblogs.com/chenmh/p/4484176.html

Alwayson配置两个节点加共享文件夹仲裁见证：http://www.cnblogs.com/chenmh/p/7156719.html

Alwayson读写分离参考：http://www.cnblogs.com/chenmh/p/7000236.html

 

备注：     做者：pursuer.chen     博客：http://www.cnblogs.com/chenmh 本站点全部随笔都是原创，欢迎你们转载；但转载时必须注明文章来源，且在文章开头明显处给明连接，不然保留追究责任的权利。 《欢迎交流讨论》