延迟是AlwaysOn最大的敌人之一

延迟是AlwaysON的最大敌人之一。对AlwaysON而言，其首要目标就尽量减少（无法避免）主副本、辅助副本的数据延迟，实现主副本、辅助副本的“数据同步”。只有主副本、辅助副本的同步延迟越小越高，只读访问的实性性才会越高，数据库的RTO（Estimating Failover Time ）和RPO（Estimating Potential Data Loss）也才会越小。

但延迟可能存在于AlwaysON同步的各个环节中，因此，在分析现延迟情况时，应该首先理解AlwaysON的同步过程，然后切分到每个过程中进行监控和分析。

AlwaysON同步的6大步骤

在我的上篇文章《AlwaysON的同步原理及同步模式》中，曾介绍过AlwaysON的同步过程。归结起来，主要包括如下六个步骤：

① log flush(primary)

② log capture(primary)

③ send(primary and secondary)

④ log receive and cache(secondary)

⑤ log hardened(secondary)

⑥ redo(secondary)

前两个步骤发生在主副本，最后三个步骤发生在辅助副本，中间的第三个步骤发生主副本和辅助副本之间。

另外，如果是同步提交模式，还需要增加一个步骤：辅助副本在步骤5之后，会发送一个（日志硬化）确认信息给主副本，然后才能进入redo阶段。

监控AlwaysOn的同步过程

Log Flush(Primary)

Log Flush就是将log buffer中的日志刷入到磁盘中。在SQL Server中，log buffer的大小固定为60KB，当发生事务提交时、checkpoint、或者buffer可用空间不足时，日志就会被flush磁盘中。

AlwaysON只有待主副本的日志刷入磁盘后才能继续后面的步骤（为了保护主副本的数据一致性）。因此，log flush的越快，AlwaysON后续步骤进入的就越早，延迟就越小，反之亦然。

那么，在这个阶段中，如何监控log flush的速度和性能呢？通常，我们使用如下两个性能计数器：

• Avg. Disk sec/Write

这是一个磁盘的性能计数器，这个指标反映的是flush期间磁盘的写操作的平均响应时间，如果10ms以内，说明磁盘性能非常好，如果在10ms到20ms，说明性能较好，如果在20ms到50ms说明性能较差，如果在50ms以上，说明性能很差。

• SQL Server:Database > Log bytes flushed\sec

这个指标直接反映了每秒flush的日志大小，因在不同的时段、不同的业务中日志产生的大小可能不同，因此不能提供一个标准值用来衡量flush性能的好坏，不过，当这个值很大时，说明数据库操作（增、删、改）比较频繁，需要引起注意，结合后续步骤中的其他指标一起分析。

SQL Server:Availabiltiy Replica > Log Bytes Received/sec

解释：每秒接受的日志大小（单位为KB）；

说明：接受的速度越快，说明网络性能和内存性能均越好。

Log Hardened(sencondary)

介绍log hardened时不得不谈一谈第一个步骤的log flush，两者其实是一个东西，只是表述不一样。因为它们无论是工作原理还是对事务提交的影响都非常类似，因此对log hardened的监控，直接参考步骤一就好了。

redo(secondary)

redo的对象是辅助副本中已经固化的日志（该日志可能是内存中副本，也可能来自磁盘上），是AlwaysON中“实现”数据同步的步骤，其他步骤都是为此做铺垫，即便是上个步骤的日志固化，它也只能保证主副本和辅助副本的数据一致，而真正的数据同步必须等待辅助副本的redo完成。

在这个阶段中，有两个因素决定了数据延迟的大小：redo的日志大小和redo的速度。下面我们从这两个角度来了解下redo阶段的性能监控：

监控redo日志大小

SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server, dr_state.database_id as database_id,

dr_state.redo_queue_size, is_ag_replica_local = CASE

WHEN ar_state.is_local = 1 THEN N'LOCAL'

ELSE 'REMOTE'

END ,

ag_replica_role = CASE

WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'

ELSE ar_state.role_desc

END

FROM (( sys.availability_groups AS ag JOIN sys.availability_replicas AS ar ON ag.group_id = ar.group_id )

JOIN sys.dm_hadr_availability_replica_states AS ar_state ON ar.replica_id = ar_state.replica_id)

JOIN sys.dm_hadr_database_replica_states dr_state on

ag.group_id = dr_state.group_id and dr_state.replica_id = ar_state.replica_id;

监控redo的速度

redo的速度通过如下性能计数器即可：

• SQL Server:Database Replica > Redone Bytes/sec

解释：辅助副本每秒完成redo的字节数；

说明：在分析此指标时，必须结合redo的日志大小，将两者的结果相除可得到一个大致的同步延迟时间。

结尾

我们知道AlwaysON是SQL Server 2012才开始引入的技术，目前笔者做的案例还不是很多，本文所表述的内容都是基于我有限的实践经验总结而来，如有不妥之处还请批评指正。

附上我的新浪微博二维码，希望我的分享能够为您带来一些价值。