镜像&AlwaysOn复制的工作原理

最近看了一本书《SQL Server 2012实施与管理实战指南》，这本书不错，推荐给大家

今天聊聊 镜像&AlwaysOn 的原理

 

镜像的工作原理：

那么主体数据库和镜像数据库是如何同步数据的呢？
SQL数据库中任何的数据变化都会先记录到事务日志中，然后才会真正更新数据页面。而事务日志是
先保存在该数据库的日志缓存（log buffer）里，然后将缓冲中的日志固化到磁盘上LDF文件中。在数据库
镜像中，主体服务器在将主体数据库的日志从日志缓存固化到磁盘的同时，还会使用另一个线程来将日志
块（log block）发送到镜像服务器的端点。当镜像服务器通过端点接收到日志块后，他先将日志块
放到镜像数据库的日志缓存里，然后将缓存里的日志固化到磁盘上。一旦日志块被固化后，镜像服务器会
根据日志来对镜像数据库执行“重做（redo）”，最终更新数据页面。当镜像服务器重做日志时，镜像数据库
实际就是在执行日志的前滚操作。如果重做失败，则镜像服务器通过将数据库至于suspended状态
来暂停会话。DBA必须找到问题的原因并解决问题才能继续会话。当主体服务器截断或收缩数据库事务日志时，
镜像服务器也将在日志的同一点收缩日志。

可以看到，数据库镜像其实就是通过发送日志来保持伙伴之间的同步。从SQL2008开始，日志块在被主体服务器
发送网络之前会做压缩处理。这麽做的目的是为了提升日志发送和接收的效率，降低日志块传输对网络链路
和网络设备所带来的负载。对应那些异常繁忙的生产系统，这项功能不但降低了由于网络不胜负荷的镜像会话
异常中断，也降低由于网络延迟导致的数据库镜像性能问题，可谓一举两得。

AlwaysOn的工作原理： AlwaysOn跟镜像有相同也有不同

3.2  AlwaysOn的数据同步原理
像数据库镜像技术一样，AlwaysOn会在各个副本上都维护一套数据副本。主副本上发生的数据变化，会同步到辅助副本上。所以和镜像一样，AlwaysOn也要完成三件事：

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

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

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

那AlwaysOn又是怎么做的呢？在主副本和辅助副本上，SQL  Server都会启动相应的线程来完成相应的任务。
现在先从主副本谈起。

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

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

在辅助副本上，同样会有两个线程，完成相应的数据更新动作，它们是固化（Harden）和重做（Redo）。
固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本的磁盘上的日志文件里（这个过程被称为"固化"）。
而重做线程，则负责从磁盘上读取日志块，将日志记录翻译成数据修改操作，在辅助副本的数据库上完成。

当重做线程完成其工作以后，辅助副本上的数据库就会跟主副本一致了。AlwaysOn就是通过这种机制，保持副本之间的同步。
重做线程每隔固定的时间点，会跟主副本通信，告知它自己的工作进度。主副本就能够知道两边数据的差距有多远。

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

读到这里，你或许会想，既然这些线程都是独立工作的，那主副本和辅助副本之间的数据差异量是怎么控制的呢？如何能保证主副本上的所有数据变化，都能被安全地传递到各个辅助副本上呢？AlwaysOn里有相应的机制，让这些线程相互协作。而副本之间是否允许有数据差异，则是由AlwaysOn的可用性模式决定的。