事务复制的延迟
在数据库的主从复制过程中,包括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在事务复制,订阅节点的吞吐量会得到大幅度提升。
参考: https://red9.com/blog/sql-server-replication-performance-tips/ https://repltalk.com/2010/03/01/navigating-sql-replication-subscriptionstreams-setting/ https://learn.microsoft.com/en-us/sql/relational-databases/replication/administration/enhance-transactional-replication-performance?view=sql-server-ver16 https://learn.microsoft.com/en-us/archive/blogs/sql_server_team/optimizing-replication-agent-profile-parameters-for-better-performance 标签:订阅,事务,SubscriptionStreams,SQLServer,复制,多线程,节点 From: https://www.cnblogs.com/wy123/p/18396228