SQL Sever AlwaysOn的数据同步原理

标签：灾难恢复   日志   返回   ext   file   带来   强制   状态   color   

1. SQL Server AlwaysOn数据同步基本工作

AlwaysOn 副本同步需要完成三件事：

1．把主副本上发生的数据变化记录下来。

2．把这些记录传输到各个辅助副本。

3．把数据变化在辅助副本上同样完成一遍。

这3件工作主要由以下4个线程完成

Log Writer线程：当任何一个SQL用户提交一个数据修改事务时，它会负责把记录本次修改的日志信息先记入一段内存中的日志缓冲区，然后再写入物理日志文件（日志固化）。

Log Scanner工作线程：位于主副本所在SQL Server上。这个线程专门负责将日志记录从日志缓冲区或者日志文件里中读出，打包成日志块，发送给各个辅助副本。由于它的不间断工作，才使主副本上的数据变化，可以不断地向辅助副本上传播。

固化（Harden）线程和重做（Redo）线程：位于辅助副本所在的SQL server上。固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本的磁盘上的日志文件里（这个过程被称为"固化"）。而重做线程，则负责从磁盘上读取日志块，将日志记录翻译成数据修改操作，在辅助副本的数据库上完成。

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

AlwaysOn的数据同步有可分为异步提交和同步提交

2. AlwaysOn同步提交模式

在同步提交模式下由可分为 辅助副本发出同步请求和主副本发出同步请求。

2.1 辅助副本发出同步请求

此情况，主要发生在辅助副本刚刚加入可用性组、或者网络等原因主副本出现差异、或者辅助副本出现脏页（物理）等少数情况下。

2.1 主副本发出同步请求，即客户端提交SQL请求触发的同步请求

2. 补充说明

1. 在同步提交模式下，日志块必须在主副本和辅助副本上都被固化到磁盘上，事务才能真正在主数据上提交。但是它并不要求日志在辅助副本上完成重做，这样可以减轻对主副本的性能影响。
2. 进入DISCONNECTED或"NOT SYNCHRONIZING"状态后，即使可用性副本处于同步提交模式，事务也不需要等待该副本的响应就可以在主副本上提交。
3. 如果为当前主副本配置了异步提交可用性模式，则它将通过异步方式为所有辅助副本提交事务，而不管这些副本各自的可用性模式设置如何。
4.   它可以保证事务日志是同步的，也就是可以保证不丢失数据，但不能保证数据变化没有延时，这是由于辅助副本在接收主副本传来的Trans log时，首先将其缓到本地Log Cache，接着强制硬化到本地Ldf，然后随即向主副本告知你可以commit了，但注意，此时的硬化到本地ldf并非本地数据已经变化，这是因为辅助副本将trans log硬化到本地的同时，它是使用一个异步进程去redo这些trans log产生的Page变化到Data文件的，所以数据的延时就是肯定的了。

3.AlwaysOn异步提交模式

•          当辅助副本处于异步提交模式下时，主副本无须确认该辅助副本已经完成日志固化，就可以提交事务。因此，主数据库事务提交不会受到辅助数据库的影响而产生等待。
•           对于主副本和辅助副本相隔很远而且不希望小错误影响主副本性能的灾难恢复方案，异步提交模式将会很有用。而且，由于主副本不会等待来自辅助副本的确认，因而辅助副本上的问题从不会影响主副本。
•       在异步提交模式下，辅助副本会尽量与自主副本的日志记录保持一致。不过，即使辅助数据库和主数据库上的数据事实上是同步的，可用性组也始终认为辅助数据库处于“SYNCHRONIZING”状态（即“未同步”状态）。

部分内容参照书籍《SQL Server 2012 实施与管理实战指南》，感谢原作者。

SQL Sever AlwaysOn的数据同步原理

标签：灾难恢复   日志   返回   ext   file   带来   强制   状态   color   

原文地址：https://www.cnblogs.com/xuliuzai/p/9847301.html