YashanDB|主备延迟怎么排查?这份实用指南收藏好!

在使用 YashanDB 进行主备部署时，遇到备库回放延迟是常见现象。如果延迟持续增长，不仅影响同步一致性，还会对故障切换、容灾策略造成影响。那么，主备延迟出现时，应该从哪些角度分析，快速定位问题?这份指南带你系统梳理!

一、基本原理回顾：理解复制与回放机制

在 YashanDB 中，主库产生 redo 日志，通过复制链路同步到备库，备库再进行日志回放。主备同步涉及的核心指标包括：

rst（Reset ID）：每次主备切换(failover)后，redo 文件的 reset id 都会加 1;

asn（归档序列号）：每生成一份 redo 日志，ASN 自动递增;

blockid：redo 文件内的逻辑页面偏移;

lfn（Log Flush Number）：每次 redo 刷盘时递增，用于衡量日志写入的进度。

只有 redo 复制、刷盘、回放各环节顺畅，主备才能保持低延迟同步。

二、常规分析步骤

1. 查看备库复制与回放状态

可以通过数据库系统视图，观察当前备库的同步状态，包括 redo 的接收进度、回放进度等关键指标。

特别注意 Redo Remain 项和 Remain Time 项：

在数据库启动阶段(MOUNT 到 OPEN)统计的是重启时的 redo 回放信息;

数据库 OPEN 后，Redo Remain 会被刷新，表示当前剩余待回放的日志量及预估所需时间。

如果 Redo Remain 长期居高不下，说明回放速度存在瓶颈。

2. 检查 redo 落盘速度

redo 从网络到达备机后，需要先刷盘到本地存储。如果落盘速度慢，自然会造成回放积压。

可以通过系统视图或 iostat 工具分析磁盘写入能力，关注日志写入相关指标。

3. 辅助查看磁盘 IO 性能

使用 iostat 工具可以细致观察磁盘负载情况：

r/s、w/s：每秒读写次数;

rkB/s、wkB/s：每秒读写数据量;

await：平均每次 IO 等待时间(一般要求小于 5ms);

svctm：设备响应时间;

avgqu-sz：平均 IO 队列长度;

%util：磁盘利用率，接近 100% 说明磁盘繁忙。

如果发现 await 明显高于 svctm，且 avgqu-sz 偏大，则说明磁盘存在严重的 IO 等待瓶颈，需要优化磁盘性能或调整负载。

4. 利用 YCM 平台监控延迟趋势

如果使用的是 YashanDB V23.2.1.100 及以上版本，可以通过 YCM 平台直观监控主备延迟变化曲线，帮助快速识别异常波动时间段。

5. 使用 gstack 检查线程状态

可以在备机上抓取 yasdb 进程的线程栈，分析回放线程是否存在阻塞、死锁或异常长时间等待情况。

命令示例：

gstack yasdb进程号 > gstack.txt
通过分析线程状态，可以进一步确认回放慢是否是由内部线程调度问题引起的。

三、真实案例分享

在一次生产数据迁移后，有用户反馈备库延迟严重。经过排查，发现是备机磁盘带宽不足，导致 redo 写入缓慢，积压了大量待回放日志。最终通过增加磁盘性能并调整并发参数，成功恢复了同步延迟至正常水平。

四、小结建议

遇到主备延迟问题时，推荐按照以下思路系统排查：

1.先确认复制链路是否正常;

2.再确认 redo 是否落盘顺畅;

3.分析回放线程与磁盘 IO 指标;

4.辅助通过 YCM、gstack 观察整体状态;

5.针对瓶颈点，优化存储性能或调整参数配置。

主备延迟虽小，但一旦积累，会影响数据库整体高可用策略，因此需早发现、早处理。