Replication的犄角旮旯(七)-- 一个DDL引发的血案(下)(聊聊logreader的延迟)

《Replication的犄角旮旯》系列导读

Replication的犄角旮旯(一)--变更订阅端表名的应用场景

Replication的犄角旮旯(二)--寻找订阅端丢失的记录

Replication的犄角旮旯(三)--聊聊@bitmap

Replication的犄角旮旯(四)--关于事务复制的监控

Replication的犄角旮旯(五)--关于复制identity列

Replication的犄角旮旯(六)-- 一个DDL引发的血案(上)(如何近似估算DDL操作进度)

Replication的犄角旮旯(七)-- 一个DDL引发的血案(下)(聊聊logreader的延迟)

Replication的犄角旮旯(八)-- 订阅与发布异构的问题

Replication的犄角旮旯(九)-- sp_setsubscriptionxactseqno,赋予订阅活力的工具

---------------------------------------华丽丽的分割线--------------------------------------------

前言:这是昨天刚刚发生的案例,尽管事件的起因只是一个简单的DDL操作,但影响面和影响时间可以说是大大超出了预期;我们将在描述本案例的前因后果之后,聊聊如何近似估算DDL的操作进度,以及关于logreader延迟的问题;

前一篇文章《Replication的犄角旮旯(六)-- 一个DDL引发的血案(上)(如何近似估算DDL操作进度)》

http://www.cnblogs.com/diabloxl/p/3844205.html

前因简述:

一个复制节点(即使上级的订阅,又是下级的分发)需要对一个表进行DDL操作,由于需要修改主键,因此将这个表从publication中删除,然后就开始了漫长的DDL操作……

本来需要进行DDL操作的表已经从replication中摘除了,以为不会影响到其他article的复制,结果惨剧还是发生了,原因依旧是VLF对logreader的影响,但这次的问题和以往又有些不同……

=====================华丽丽的分割线=====================

先说说之前遇到的logreader延迟的情况:

1、发布表的写操作

  这里又分为两种情况

  a)大量并发写操作:指大量的小DML操作,特点是事务小、并发多

  b)大事务写操作:指有单个大事务操作,特点是事务大、并发少

2、非发布表的写操作

  指有写操作的表并不是需要复制的表,这里将上述a\b两种情况合并在一起说,这次遇到的是b这个类型;

检查logreader的延迟的利器——sp_replcounters

Replication的犄角旮旯(七)-- 一个DDL引发的血案(下)(聊聊logreader的延迟)

MSDN上关于这个存储过程的解释:

http://msdn.microsoft.com/zh-cn/LIBRARY/ms190486

无论对于上述哪种情况,如果Replicated transactions持续增加,那就是logreader延迟了,初步的现象就是这个发布下所有的订阅都在延迟;

那上述3种情况的差异呢?

  对于1a)

  Replicated transactions快速增加,replbiginlsn和replnextlsn都会较慢速度的变化;(这里的慢速是相对与正常速度而言,受实际业务环境影响,下同)

  这是由于大量的小DML操作都会快速的提交,但由于大量的日志写入,导致存在大量的活动VLF,因而日志不能被截断;同时,尽管logreader根据replnextlsn去定位下一个要复制的lsn,但由于效率下降,且后面涌入的新事务也在增长,导致恶性循环,从而引起logreader的延迟;

  对于1b)

  Replicated transactions慢速增加,replbiginlsn不变、replnextlsn不变;

  虽然事务并发量很小,但由于单个提交的事务很大,仍然导致大量的活动VLF,从而引起logreader效率下降;

  对于2

  Replicated transactions快速增加,replbiginlsn不变、replnextlsn慢速变化;

  由于非复制的表也需要写日志,且占用了大量VLF,因此logreader需要从大量的VLF中获取需要复制的日志信息,这也同样影响到它的执行效率;

那我们该如何应对呢?

  硬件当然是最有效的手段之一,升级内存、磁盘换成IO卡等可以解决根本问题,但这又不是绝对,一个SQL跑死服务器的情况也绝非不可能;

  1、对于1a的情况,建议有频繁写操作的表,还是能分就分,或者分到多个库中,或者分到多个实例下,原则就是不要让logreader干太多活,毕竟的是个单线程的任务,穿少了也cool,喝多了也吐。

  2、对于1b的情况,本身单个大事务就不是OLTP环境中提倡的,不光是复制延迟,光一堆锁估计机器也受不了;建议拆成多个事务来跑;

  3、对于2来说,尽管要搞的表和复制没有任何关系,但不能忽略VLF对logreader的影响,既然在一个库中,公用日志序列,还是小心为妙;如果是大表的DDL的操作,还是通过停写、建新表、导数据的方法实现,bulk insert的方式或许是对日志影响最小的;

  但bulk insert的方式一般要求停写,而受业务的制约,可能不允许长时间的停写,这该怎么破?

  可以看看我之前的文章《Replication的犄角旮旯(一)--变更订阅端表名的应用场景》,复制回路可以说是为这种需求量身定做的~

上一篇:为了解决mysqlbing翻译表字段问题而分析frm文件(持续更新)


下一篇:Codeforces Round #447 (Div. 2) B. Ralph And His Magic Field【数论/组合数学】