Always on的原理

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

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

3、在辅助副本上，同样会有两个线程，完成相应的数据更新动作，它们是固化（Harden）和重做（Redo）。固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本的磁盘上的日志文件里（这个过程被称为"固化"）。而重做线程，则负责从磁盘上读取日志块，将日志记录翻译成数据修改操作，在辅助副本的数据库上完成。当重做线程完成其工作以后，辅助副本上的数据库就会跟主副本一致了。AlwaysOn就是通过这种机制，保持副本之间的同步。重做线程每隔固定的时间点，会跟主副本通信，告知它自己的工作进度。主副本就能够知道两边数据的差距有多远。这些线程在工作上各自独立，以达到更高的效率。Log Scanner负责传送日志块，而无须等待Log Writer完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据已经传递完毕，而无须等待重做完成。其设计目标，是尽可能地减少AlwaysOn所带来的额外操作对正常数据库操作的性能影响。

4、同步提交模式的维护方式：从客户端收到事务后，主副本会将事务的日志写入事务日志，同时将该日志记录发送到辅助副本。日志记录写入主数据库的事务日志后，事务将不能撤消，除非在此时故障转移到尚未收到该日志的辅助副本。主副本将等待来自同步提交辅助副本的确认。辅助副本将强制写入日志（固化），并将确认消息返回给主副本。收到来自辅助副本的确认后，主副本将完成提交处理并向客户端发送一条确认消息。在同步提交可用性模式下，副本联接到某个可用性组后，辅助数据库就会与对应的主数据库求得一致并进入 SYNCHRONIZED（已同步）状态。 只要一直在进行数据同步，辅助数据库就会保持 SYNCHRONIZED 状态。 这可确保对主数据库提交的每个事务也应用到对应的辅助数据库。在同步辅助副本上的每个辅助数据库之后，辅助副本的同步运行状态总体上将为 HEALTHY。

5、异步提交模式的维护方式：如果每个辅助副本都在异步提交模式下运行，则主副本不会等待任何辅助副本强制写入日志， 而会在将日志记录写入本地日志文件后，立即将事务确认发送到客户端。由于主副本不会等待来自辅助副本的确认，因而辅助副本上的问题从不会影响主副本，辅助数据库就会保持 SYNCHRONIZING 状态。对于主副本和辅助副本相隔很远而且您不希望小错误影响主副本的灾难恢复方案的情况，或性能比同步数据保护更重要的情况，异步提交模式将会很有用。异步提交辅助副本会尝试与接收自主副本的日志记录保持一致，但异步提交辅助数据库往往会保持未同步状态，通常异步提交辅助数据库和相应的主数据库之间的这个时间差会很小。但是，如果承载辅助副本的服务器的工作负荷过高或网络速度很慢，则这个时间差会变得较大。

6、会话超时机制：由于软错误不能由服务器实例直接检测到，因此，软错误可能导致一个可用性副本无限期等待会话中另一个可用性副本的响应。 为了防止发生这种情况， Always On 可用性组实施了会话超时机制，此机制基于以下条件：所连接的可用性副本会在每个打开的连接上按固定间隔发送 ping。 在超时期限内收到 ping 指示连接仍是开放的且服务器实例正在通过此连接进行通信。 收到 ping后副本将重置此连接上的超时计数器。主副本和辅助副本相互 ping 以指示它们仍处于活动状态， 会话超时限制是用户可配置的副本属性，默认值为 10 秒。如果在会话超时期限内没有收到来自另一个副本的ping，该连接将超时、连接将关闭；超时的副本进入 DISCONNECTED 状态。 即使为同步提交模式的副本，事务也将不等待该副本重新连接暂时将该辅助副本切换到异步提交模式。在该辅助副本重新与主副本连接后，它们将恢复同步提交模式。