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所带来的额外操作对正常数据库操作的性能影响。

时间: 2024-08-09 14:40:00

AlwaysON同步过程的相关文章

SQL Server AlwaysON 同步模式的疑似陷阱

SQL Server 2012 推出的最重要的功能之一Alwayson,是一个集之前Cluster和Mirror于一体的新功能,即解决了Cluster依赖共享存储的问题,又解决了镜像不能实时读以及转移后连接串需要添加转移IP的问题,看起来的确很实用. 而且Alwayson多副本的功能为实现读写分离提供了可能,试想一下,当主副本压力比较大的时候,是否可以将读操作引向辅助副本呢?答案一般来讲是肯定的,请注意,是一般! Alwayson有两个同步模式,同步和异步,即然是同步,理所当然的我认为他是实时的

AlwaysON同步的原理及可用模式

新一代读写分离技术——AlwaysOn 早在SQL Server 2005的时候微软就已经实现了数据库的查询分离技术——发布订阅.但生产库和查询库的同步性能较差,时常出现性能问题,因此在大型生产环境中一直被人所诟病. 从SQL Server 2012开始,微软逐渐使用AlwaysON技术来取代发布订阅.AlwaysOn 作为SQL Server 2012引入的一种新的技术架构,性能相比发布订阅而言提升很多,最明显的区别在于其充分利用内存高效读取的原理来实现日志的传递.下文将通过 AlwaysOn

一个磁盘I/O故障导致的AlwaysOn FailOver 过程梳理和分析

下面是我们在使用AlwaysOn过程中遇到的一个切换案例.这个案例发生在2014年8月,虽然时间相对久远了,但是对我们学习理解AlwaysOn的FailOver原理和过程还是很有帮助的.本次FailOver的触发原因是系统I/O问题.大家需要理解,操作系统I/O出现了问题不一定立即触发SQL Server发生漂移,因为坏的槽点可能不在SQL Server实例所用到的位置,但是随着时间持续 和数据堆积,问题槽点可能扩大升级.我们可以看到在本例中,第一次出现I/O问题到SQL Server 漂移间隔

java多线程的等待唤醒机制及如何解决同步过程中的安全问题

/* class Person{ String name; String sex; boolean flag = true; public void setPerson(String name, String sex){ this.sex=sex; this.name=name; } } class Input implements Runnable{ int x=0; Person p; Input(Person p){ this.p=p; } public void run(){ while

AlwaysOn 同步提交模式是否会丢失数据?

最近朋友去恒大面试,考官给出这样一个观点: 同步情况下丢失数据有两种情况:一种是阻塞丢失,一种是同步失败. 给出的处理办法:阻塞丢失的话干掉阻塞进程,或者重启实例都能解决:同步失败就只能重做节点. 让我们一起来理解下,微软官方对于AlwaysOn同步提交模式的理解,当然直接看英文原文理解更精准: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-modes-a

SQLSERVER 2012之AlwaysOn -- 同步模式下的网卡性能优化

本文是基于上一篇<SQLServer 2012之AlwaysOn -- 指定数据同步链路,消除网络抖动导致的提交延迟问题>的问题继续进行优化:具体背景请参照上文:     前后折腾了一个多月,最近终于把这块难啃的骨头搞定了.问题只是出在网卡的高级功能上:     解决方案:关闭网卡的高级功能Jumbo Mtu和Large Send Offload V2     问题分析:根据Broadcom Ethernet 网络适配器的解释 Jumbo Mtu Jumbo Mtu 属性允许网络适配器发送和接

MySQL配置主从同步过程记录

今天由于工作需要,配置了一下主从同步,这里记录一下配置过程,以备查阅. 事先度娘了一番,主从同步需要保证主从服务器MySQL版本一致(我的略有差别,主服务器版本5.5.31,从服务器版本5.5.19). 1.初始化表结构,将主服务器上的表结构全部备份导入到从服务器上,之后,之后主服务器暂时不要做数据修改操作. 2.下载备份文件,并导入到从服务器,方式有很多,这里不再赘述. 3.修改主服务器master的MySQL配置文件,开启主服务器二进制日志,并设置服务器唯一ID,编辑/etc/my.cnf,

Rsync同步过程中遇到的常见问题

一.Rsync服务介绍 Rsync属于一款实现全量及增量同步数据的软件工具,适用于unix/linux/windows等多种操作系统平台. Rsync软件能实现本地复制,远程复制,或者远程守护进程方式复制.它以其delta-transfer算法闻名,减少通过网络数据发送数量,利用只发送源文件和目标文件之间的差异信息,从而实现数据的增量同步复制. 二.Rsync工作方式 本地数据备份方式 远程传输数据方式 守护进程传输数据方式 以rsync守护进程方式实现为主,通过man rsync帮助,查看用法

centos 6.5设置mysql主从同步过程记录

在centos 6.5上设置了mysql主从功能,记录一下. 服务器1(主)IP:192.168.137.144系统版本:centos 6.5mysql版本:mysql 5.5 服务器2(从)IP:192.168.137.185系统版本:centos 6.5mysql版本:mysql 5.5 这里两台服务器的系统版本和mysql版本均一致,这也是官方推荐的做法.在开始设定之前,最好能确保主库和从库一致. 1.主库和从库创建同步用户 mysql> grant replication slave,