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在事务复制，订阅节点的吞吐量会得到大幅度提升。
 
 
参考：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-ver16https://learn.microsoft.com/en-us/archive/blogs/sql_server_team/optimizing-replication-agent-profile-parameters-for-better-performance 
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。