使用OMS4.2.7将TiDB迁移到OB，增量同步延迟越来越大，请问该如何排查？

DBRE · 2025 年1 月 14 日 16:58

【使用环境】生产环境
【 OB or 其他组件】OMS
【使用版本】OMS4.2.7, TiDBv5.1.1
【问题描述】OMS 社区版4.2.7版本开始实现 TiDB 数据库 V4.x 之后版本的增量组件，去除对 TiCDC 和 Kakfa 的依赖。
因为之前使用ticdc+kafka，tidb的checkpoint老是停滞，所以改用了OMS4.2.7将TiDB迁移到OB，但是增量同步的延迟越来越大，请问是什么问题呢？

淇铭 · 2025 年1 月 14 日 17:01

查一下组件监控看看是哪个组件有延迟

DBRE · 2025 年1 月 14 日 17:02

增量有延迟，下游ob是有全量数据的

淇铭 · 2025 年1 月 14 日 17:05

你按照截图发一下日志

DBRE · 2025 年1 月 14 日 17:21

这个是需要登录到oms对应的docker后获取日志，还是直接在OMS平台上获取日志呢？

淇铭 · 2025 年1 月 14 日 17:33

oms对应的docker后获取日志这样比较全

淇铭 · 2025 年1 月 14 日 17:35

系统租户oceanbase库 下执行如下查询SQL
WITH palf_log_stat AS (
SELECT
tenant_id,
MAX(begin_scn) AS palf_available_start_scn,
MIN(end_scn) AS palf_available_latest_scn,
SCN_TO_TIMESTAMP(MAX(begin_scn)) AS palf_available_start_scn_display,
SCN_TO_TIMESTAMP(MIN(end_scn)) AS palf_available_latest_scn_display
FROM GV$OB_LOG_STAT
WHERE tenant_id & 0x01 = 0 or tenant_id = 1
GROUP BY tenant_id
),
archivelog_stat AS (
SELECT
a.tenant_id AS tenant_id,
MIN(b.start_scn) AS archive_start_scn,
a.checkpoint_scn AS archive_latest_scn,
a.checkpoint_scn_display AS archive_available_latest_scn_display
FROM CDB_OB_ARCHIVELOG a
LEFT JOIN CDB_OB_ARCHIVELOG_PIECE_FILES b
ON a.tenant_id = b.tenant_id AND a.round_id = b.round_id
AND b.file_status != ‘DELETED’ AND a.STATUS = ‘DOING’
GROUP BY a.tenant_id
)
SELECT
pls.tenant_id,
pls.palf_available_start_scn,
pls.palf_available_latest_scn,
pls.palf_available_start_scn_display AS palf_available_start_scn_display,
pls.palf_available_latest_scn_display AS palf_available_latest_scn_display,
als.archive_start_scn AS archive_available_start_scn,
als.archive_latest_scn AS archive_available_latest_scn,
CASE WHEN als.archive_start_scn IS NOT NULL THEN SCN_TO_TIMESTAMP(als.archive_start_scn) ELSE NULL END AS archive_available_start_scn_dispalay,
als.archive_available_latest_scn_display
FROM palf_log_stat pls
LEFT JOIN archivelog_stat als ON pls.tenant_id = als.tenant_id
GROUP BY pls.tenant_id, pls.palf_available_start_scn;