SQLServer事务复制延迟优化之并行(多线程)复制

事务复制的延迟

在数据库的主从复制过程中,包括MySQL的主从复制,SQLServer的事务复制等等,鉴于主节点往往是并发写入的,而从节点(SQLServer中叫做订阅节点)在重放主节点的写操作的时候,往往会产生一定时间的延迟,如何降低这种复制延迟,并行复制或者说多线程复制是其中手段之一。
 

SQLServer事务复制分发线程

参考如下图例涉及的事务复制相关的线程,类似于MySQL的MTS多线程并行复制技术,SQLServer数据的事务复制同步过程中,数据库在主节点(publication发布节点)上以并发的形式写入,从节点(Subscribtion订阅节点)默认情况下以单线程的方式来“重放”主节点的写入操作,这样在高并发的情况下可能会造成一个较高的复制延迟。这里的并行复制,就是下图中的writer thread,以多个线程的方式并行执行,来尽可能地降低复制延迟。


图片来源于https://red9.com/blog/sql-server-replication-performance-tips/

 

事务复制分发线程参数SubscriptionStreams

以下是SQLServer事务复制的进程结构示例图,从中可以看到,distrib.exe的writer thread就是把distrubution中解析出来的日志在订阅节点上重放的的实现者。
分发代理distrubution agent有一组配置文件,涉及到22个分发相关的参数,参考下图,其中SubscriptionStreams参数就是所谓的并行复制参数,默认值是1。

先看官方对SubscriptionStreams参数的解释:
SubscriptionStreams参数可以极大地提高聚合复制(注:这里官方叫aggregate replication ,一个很奇怪的用词)的吞吐量。
它允许到订阅服务器的多个连接并行应用批量更改,同时保持着事务在单线程下的特征(意思是和单线程回放效果一致)。如果其中一个连接执行或提交失败,则所有连接将中止当前批处理,代理将使用单个流重试失败的批处理。在此重试阶段完成之前,订阅服务器上可能存在暂时的事务不一致。在成功提交失败的批之后,订阅服务器将恢复到事务一致性状态。
SubscriptionStreams默认值是1,也就是distrubution agent使用一个线程在订阅节点做回放,该参数的可配置范围为1~64,但并不意味着事务复制的吞吐量会随着该参数的增加而等比例增加,考虑一下因素:
1,如果分发节点和订阅节点之间网络流存在瓶颈
2,订阅节点服务器CPU核数
3,订阅节点的磁盘IO处理能力有限
以上因素都会影响到订阅节点回放事务操作的效率。
 

SubscriptionStreams值对事务复制吞吐量的影响

参考微软官方的SQLServer team blogs中的测试结果

在单事务( singleton transactions,每个事物一条命令)情况下,在修改默认的commitbatchsize(默认为100)为200,SubscriptionStreams为8的情况如下

在复杂事物事物(each transaction ranging from 500-1000 commands),结果如下。

以上两种情况,均说明SubscriptionStreams在8的情况下,比默认值1在事务复制,订阅节点的吞吐量会得到大幅度提升。

 

 

参考: