同步延迟，Logreader日志显示： Replicated transactions are waiting for next Log backup or for mirroring partner to catch up.

Question

同步延迟，Logreader日志显示： Replicated transactions are waiting for next Log backup or for mirroring partner to catch up.

已经确定发布数据库没有打开 sync with backup 选项，而且测试验证过，没有日志备份，日志读取器工作不会受影响

跟踪标记 1448 已经打开，测试验证，手工将镜像 suspend，日志读器工作不受影响

但 LogReader agent 日志仍然会出现  Replicated transactions are waiting for next Log backup or for mirroring partner to catch up. 而且持续时间长，初步确定的现象是：

online rebuild index，这时候会产生大量日志（超过1G），完成之后日志 logreader agent 出现等待，并显示上述信息，在镜像同步完成之前不会消失（镜像是高性能模式 parter safety off),  将镜像暂停 (set partner suspend), 很快 logreader agent 继续工作，再将镜像恢复 (set partner resume), logreader agent 仍然继续工作，不再受镜像同步的影响

不知道大家有没有遇到这种问题，有没有什么彻底的解决方法

诡异的是为什么logreader agent会堵塞，镜像要 suspend 再resume就不再受影响（当然，这个suspend 再resume不是持久的，如果这样设置一次之后就再也没问题，那也算解决问题了）

顺便一提的是联机重建索引的日志开销，有时候一个几非MB的表，重建一个索引的日志开销超过10G，不管是排序放到tempdb，还是取消并行，都不会降低这种日志开销

Answer 1

原因： As per message i checked the transaction log backups were happened or not,
checked it and log backups were happening . Finally one option
is pending to review and it is mirroring. I checked the status of mirroring  and
seen principal database went to synchronizing mode.
May be mirroring went in synchronizing mode due to heavy or so many
transactions in the route to apply at mirror database. So replication is
waiting  to be synchronized status of principal database. I exactly do not know
why replication went in waiting even transaction log backups were happened. I
checked online solution and received some of the solutions from here and it
suggests following,

解决办法： Enable trace flag 1448

After this setting the Log Reader Agent can continue replicating changes regardless of the mirroring state. Please read more here. I never applied these suggestions. Replication and mirroring both are using
transaction logs and this could be the reason why replication was in high delay status while mirroring was stuck or in process to synchronize mirror database.
So i turned off mirroring and monitored replication status. Finally replication was succeed to remove delay and applied all pending commands. Then i configured mirroring again after done with replication sync.

Conclusion : We have two options either to wait for synchronized status of principal database or turned of mirroring, getting replication synced properly and reconfigure mirroring again depend on priority and importance.It will be better to go for correct solution to avoid such issue

---

Please Mark As Answer if it is helpful.

Answer 2

1448 我已经说了，这个是开着的，而且测试验证了是有效的，问题不在这里（麻烦再看一下我的描述）

Answer 3

问题最终没正确的解释

Logreader就卡在 rebuild index 产生大量日志之后，但是镜像重启一下就好了，不重启就一直卡着

最终换镜像服务器了，镜像磁盘IO加强了，镜像的处理速度与日志生成速度基本匹配了，这个问题就没了

Answer 4

如果搭建了镜像， 那么logreader是读取mirror端的日志，而不是primary端的日志。所以如果大量的rebuild index，出现这种情况是正常的。

即使没有镜像，rebuild index也会造成log reader读取缓慢，因为log reader要过滤大量的non-replciate日志

Answer 5

不管是读 primary 还是读 mirror, 都无法解释为什么把  mirror 做了 suspend 再 resume 后， logreader 马上就好了

不过你说到的是读 mirro， 我倒是想到了一种可能， rebuild 产生大量日志，在没有同步到 mirror 前，无法从 mirror 读，所以等，但是 suspend mirror的话，logreader 认为不可以读mirror了，所以改为读 primary， 这时候是肯定可以读的，于是 logreader 继续，mirror 在 resume 后也继续

我想这个才算是 suspend 再 resume mirror 可解决问题的原因吧？否则一味只读 mirror 或只读 primary 始终是解释不通的

Answer 6

多啰嗦一句的就是 rebuild index 的日志，这个开销有时候很猛，1G的表，有时候能够弄出10G的日志出来，真是唉了

Answer 7

问一下，如果数据库用了CDC，CDC也是依赖logreader，那么CDC也会延迟，对吧

在新公司里，cdc，镜像，复制都用到了

既然这样，如果需要cdc要抽取的数据跟订阅的数据是一样的话（需求一样），那就不需要cdc了，减轻主库压力

---

Love SQL

Answer 8

You are right only if replication and cdc same tables to same destination.

Answer 9

You are right only if replication and cdc same tables to same destination.

有相同需求才能这样

---

Love SQL

Answer 10

我们生产环境有三台机器，用了复制和镜像，

155：发布服务器，镜像主库

254：镜像库

110：订阅端

我发现在254这台机根本没有110这台机的连接，所以不能证明

如果搭建了镜像， 那么logreader是读取mirror端的日志，而不是primary端的日志。

 

---

Love SQL

Answer 11

确实没有sql连接，不知道 logreader 是什么原理，是不是有什么特殊手段直接通过镜像端点去拿数据

就算想通过 sql 连接应该也不能啊，至少在我的环境中， 没有留帐号给它去做 sql 连接

Answer 12

sql7.0到现在，微软的复制一直不思进取，不支持分组提交和并行复制，尤其是rebuild index不能单独禁止log，不然楼主这个问题迎刃而解.

这也是我从不在核心系统使用rep的原因.