always_on_对相关度的理解

AlwaysOn技术的简要说明：

SQL Server2012所支持的AlwaysOn技术集中了故障转移群集、数据库镜像和日志传送三者的优点，但又不相同。故障转移群集的单位是SQL实例，数据库镜像和日志传送的单位是单个用户数据库，而AlwaysOn支持的单位是可用性组，每个组中可以包括一个或者是多个用户数据库。也就是说，一旦发生切换，则可用性组中的所有数据组会作为一个整体进行切换。
AlwaysOn底层依然采用Windows 故障转移群集的机制进行监测和转移，因此也需要先建立Windows Cluster，只不过可用性组中的数据库不一定非要再存放在共享存储上了。可以是存储在本地磁盘上。

AlwaysOn组可用性模式简要说明：

1．异步提交模式

使用此可用性模式的可用性副本称为“异步提交副本”。当辅助副本处于异步提交模式下时，主副本无须确认该辅助副本已经完成日志固化，就可以提交事务。因此，主数据库事务提交不会受到辅助数据库的影响而产生等待。但是，辅助数据库的更新可能会滞后于主数据库，如果发生故障转移，可能会导致某些数据丢失。如果为当前主副本配置了异步提交可用性模式，则它将通过异步方式为所有辅助副本提交事务，而不管这些副本各自的可用性模式设置如何。

对于主副本和辅助副本相隔很远而且你不希望小错误影响主副本性能的灾难恢复方案，异步提交模式将会很有用。而且，由于主副本不会等待来自辅助副本的确认，因而辅助副本上的问题从不会影响主副本。

在异步提交模式下，辅助副本会尽量与自主副本的日志记录保持一致。不过，即使辅助数据库和主数据库上的数据事实上是同步的，可用性组也始终认为辅助数据库处于“SYNCHRONIZING”状态（即“未同步”状态），因为理论上在异步模式下，辅助数据库在任何时点都可能会落后。

2．同步提交模式

使用此可用性模式的可用性副本称为“同步提交副本”。在同步提交模式下，主数据库在提交事务之前，主副本要等待同步提交辅助副本确认它已将日志固化到磁盘上。只要辅助副本还没有告诉主副本日志固化完成，主副本上的事务就不能提交。这样就保证两边的数据始终是同步的。只要一直在进行数据同步，辅助数据库就会保持“已同步”（SYNCHRONIZED）的状态。

同步提交模式能够保障给定的辅助数据库与主数据库上的数据保持完全的同步。但是这种保障的代价是主数据库上的事务提交会有滞后时间。可以说，同步提交模式相对于性能而言更强调高可用性。

WSFC的简要说明：
下面先介绍下Windows 故障转移群集（WSFC） ，WSFC 群集中的每个节点都参与周期性信号通信，以便与其他节点共享该节点的运行状况。未响应的节点被认为是处于故障状态。
“仲裁”节点集是 WSFC 群集中的大多数投票节点和见证服务器。WSFC 群集的总体运行状况和状态是由定期“仲裁投票”确定的。仲裁的存在意味着群集运行状况正常，且能提供节点级别的容错能力。
没有仲裁并不指示群集未在正常状况下运行。必须维护整体 WSFC 群集运行状况，以便确保运行状况辅助节点可用于要故障转移到的主节点。如果仲裁投票失败，作为一项预防措施，WSFC 群集将被设为脱机。这也将导致停止所有向群集注册的 SQL Server 实例。
注：如果 WSFC 群集因为仲裁失败而被设为脱机，则需要手动干预以便将其重新联机。
仲裁模式”是在 WSFC 群集级别配置的，指示用于仲裁投票的方法。故障转移群集管理器实用工具将会基于群集中的节点数来建议仲裁模式。
以下仲裁模式可用于确定构成投票仲裁的元素（仲裁机制）：
　　节点的大多数：  群集中超过一半的投票节点必须投票赞成群集处于正常状态。
　　节点和文件共享的大多数：  与节点的大多数仲裁模式相似，只有远程文件共享也配置为投票见证除外，并且从任何节点到该共享的连接也作为赞成投票计数。超过一半的可能投票必须赞成群集处于正常状态。
作为最佳实践，见证文件共享不应驻留在该群集中的任何节点上，必须它应该对于该群集中的所有节点都是可见的。
　　节点和磁盘的大多数：  与节点的大多数仲裁模式相似，只有共享磁盘群集资源也指定为投票见证除外，并且从任何节点到该共享磁盘的连接也作为赞成投票计数。超过一半的可能投票必须赞成群集处于正常状态。
　　仅限磁盘：  共享磁盘群集资源指定为见证，并且从任何节点到该共享磁盘的连接也作为赞成投票计数。

查看节点的投票权的语句：

--cmd命令行下运行，注意大小写（区分）

cluster node /prop |find "NodeWeight"

--或者 在新建查询窗口

SELECT member_name, member_state_desc, number_of_quorum_votes

修改节点投票权的语句：

--cmd命令行下运行，注意大小写（区分）

cluster node XXXXXX /prop NodeWeight = 0
cluster node XXXXXX /prop NodeWeight = 1

 清理节点信息的语句（将节点加入新的wsfc之前的准备工作）：

cluster node /force

AlwaysOn与WSFC联系：

AlwaysOn 可用性组承载于 SQL Server 实例上。

指定将连接到主数据库或辅助数据库的逻辑可用性组侦听器名称的客户端请求将重定向至基础 SQL Server 实例或 SQL Server 故障转移群集实例 (FCI) 的相应实例网络名称。

“SQL Server 实例”当前承载于单个节点上。

如果存在，则独立的 SQL Server 实例始终驻留在具有静态实例网络名称的单个“节点”上。如果存在，则 SQL Server FCI 在两个或多个具有单个虚拟“实例网络名称”的可能的故障转移节点之一上处于活动状态。

“节点”为 WSFC 群集的成员。

每个节点上存储了所有节点的WSFC 配置元数据和状态。每个服务器都为用户或系统数据库提供非对称存储或共享存储 (SAN) 卷。在一个或多个 IP 子网上，每个服务器都至少具有一个物理网络接口。

WSFC 服务监视一组服务器的运行状况和管理它们的配置。

“Windows Server 故障转移群集 (WSFC)”服务将对“WSFC 配置”元数据和状态的更改传播到群集中的所有节点。部分元数据和状态可能存储在 WSFC 仲裁见证服务器远程文件共享上。两个或更多活动的节点或见证服务器构成一个仲裁，以便对 WSFC 群集的运行状况进行投票。

AlwaysOn的特性：

下面，先看一下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，好处是：可用性副本是个单机实例，那么数据库副本就存放在该运行该实例节点的本地磁盘上；如果可用性副本是个群集实例，那么数据库副本就存放在共享磁盘上。
可用性组从Windows群集角度来看，就是一个群集资源，其中的所有数据库作为一个整体在节点间进行故障转移，当然这不包括系统数据库，系统数据库是不能加入高可用性组中的。
因为需要借助Windos群集实现监控和转移，所以AlwaysOn会受到一些限制：
一个可用性组中的所有可用性副本必须运行在单一的Windows群集上，跨不同Windows群集的SQL Server实例不能配置成一个AlwaysOn可用性组。
一个可用性组的所有可用性副本必须运行在Windows群集的不同节点上。运行在同一个节点上的两个不同实例不能用作同一个可用性组的副本。
如果某个可用性副本实例是一个SQL群集实例，那同一个SQL群集的其他非活跃节点上安装的任何其他SQL实例都不能作为它的辅助副本。
一个数据库只能属于一个可用性组。
AlwaysOn最多可以支持五个副本，但只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库（PrimaryDatabase），同时这个可用性副本被称为主副本（primaryreplica）。其余的副本都被称为辅助副本（secondaryreplica），辅助副本上的数据库可能是不可访问的，或者是只能接受只读操作（取决于可用性组的配置），这些数据库被称为辅助数据库。一但发生故障转移，任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。

AlwaysOn在各副本间数据同步原理：
AlwaysOn必须要维护各副本间的数据一致性，当主副本上的数据发生变化，会同步到辅助副本上。这里AlwaysOn通过三个步骤来完成：
步骤1：主副本记录发生变化的数据；
步骤2：将记录传输到各个辅助副本；
步骤3:把数据变化操作在辅助副本上执行一遍。
具体实现如下：
在主副本和辅助副本上，SQL Server都会启动相应的线程来完成相应的任务。对于一般的SQL Server服务器，即没有配置高可用性，会运行Log Writer的线程，当发生数据修改事务时，此线程负责将本次操对应的日志信息记录到日志缓冲区中，然后再写入到物理日志文件。但如果配置了AlwaysOny主副本的数据库，SQL Server会为它建立一个叫Log Scanner的线程，不间断的工作，负责将日志从日志缓冲区或日志文件里读出，打包成日志块，发送到辅助副本。因此可以保证发生的数据变化，不断送给各辅助副本。
辅助副本上存在固化和重做两个线程完成数据更新操作，固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本磁盘上的日志文件里，因此称为固化，然后重做线程负责从磁盘上读取日志块，将日志记录对应的操作重演一遍，此时主副本和辅助副本上的数据就一致了。重做线程每隔固定的时间点，会跟主副本通信，告知自己的工作进度。主副本由此知道两边数据的差距。Log Scanner负责传送日志块，不需要等待Log Writer完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据传输完成，而不需要等待重做完成，这样各自独立的设计，是尽可能减少 AlwaysOn所带来的操作对数据库性能的影响。

《SQL Server 2012实施与管理实战指南》中指AlwaysON同步过程如下：

任何一个SQL Server里都有个叫Log Writer的线程，当任何一个SQL用户提交一个数据修改事务时，
它会负责把记录本次修改的日志信息先记入一段内存中的日志缓冲区，然后再写入物理日志文件（日志固化）。
所以对于任何一个数据库，日志文件里都会有所有数据变化的记录。
对于配置为AlwaysOn主副本的数据库，SQL Server会为它建立一个叫Log Scanner的工作线程。
这个线程专门负责将日志记录从日志缓冲区或者日志文件里中读出，打包成日志块，发送给各个辅助副本。
由于它的不间断工作，才使主副本上的数据变化，可以不断地向辅助副本上传播。
在辅助副本上，同样会有两个线程，完成相应的数据更新动作，它们是固化（Harden）和重做（Redo）。
固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本的磁盘上的日志文件里（这个过程被称为"固化"）。
而重做线程，则负责从磁盘上读取日志块，将日志记录翻译成数据修改操作，在辅助副本的数据库上完成。
当重做线程完成其工作以后，辅助副本上的数据库就会跟主副本一致了。AlwaysOn就是通过这种机制，保持副本之间的同步。
重做线程每隔固定的时间点，会跟主副本通信，告知它自己的工作进度。主副本就能够知道两边数据的差距有多远。

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

今天的文章always_on_对相关度的理解分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。