OceanBase 数据库 UNIT 日志流级别迁移复制进度可视化与排查指南

问题现象

在 OceanBase 数据库的 UNIT 迁移场景下，经常会遇到单个日志流（LS）下包含成千上万个 tablet 的情况。由于缺少直接、精细化的进度可视化手段，运维人员往往只能依赖零散的日志或控制台状态，难以判断一次迁移到底完成了多少——尤其是当同一个迁移任务被多次中断或重试后，更难以把握真正起始点与已完成量的对应关系。

关键信息

1. 线上监控 SQL。

   • avg_migrating_size： 当前处于迁移中的副本的数据量。

   • avg_disk_size： 正常副本，总数据量。

   • migrating_to_disk_ratio_percent： 两者之比（×100），数值越接近 100%，说明正在迁移的副本平均数据量已能与正常的副本持平，整体进度也就越接近完成。

    SET @tenant_id = 1002, @ls_id = 1001;
   
    SELECT
    -- 正在迁移（migrate_status<>0）的副本，平均已迁数据量
    AVG(CASE WHEN migrate_status <> 0 THEN required_data_disk_size END) AS avg_migrating_size,
    -- 正常（migrate_status=0）的副本，平均数据量
    AVG(CASE WHEN migrate_status = 0 THEN required_data_disk_size END)   AS avg_disk_size,
    -- 两者的比值（注：除数为 0 时返回 NULL，可自行加 COALESCE 或 CASE 处理）
    ROUND(
        AVG(CASE WHEN migrate_status <> 0 THEN required_data_disk_size END)
        / NULLIF(AVG(CASE WHEN migrate_status = 0 THEN required_data_disk_size END), 0)
        * 100
        , 2) AS migrating_to_disk_ratio_percent
    FROM __all_virtual_ls_info
    WHERE tenant_id = @tenant_id
    AND ls_id     = @ls_id;
   

2. 线下监控 SQL（更细粒度）。

   • __all_virtual_tablet_to_ls： 记录某个日志流下所有 tablet 的映射，用于统计总 tablet 数。

   • __all_server_event_history： 存储包括 ls_ha_start（启动迁移）和 tablet_finish_migration_task（单个 tablet 迁移完成）在内的各种事件，通过筛选时间区间即可得出某次迁移中已完成的 tablet 数。

    -- 只设置一次变量
    SET @tenant_id = 1002, @ls_id = 1001, @total_inner_tablet_count = 4;
   
    SELECT
    finished.count_finished   AS finished_count,
    total.count_total         AS total_count,
    CASE
        WHEN total.count_total = 0 THEN 0
        ELSE ROUND(
        LEAST(finished.count_finished, total.count_total)
        / total.count_total * 100
        , 2)
    END AS progress_percent
    FROM
    -- 总 tablet 数 + 总 inner tablet 数
    (SELECT COUNT(*) + @total_inner_tablet_count AS count_total
    FROM __all_virtual_tablet_to_ls
    WHERE tenant_id = @tenant_id
        AND ls_id     = @ls_id
    ) AS total
    CROSS JOIN
    -- 自最后一次 ls_ha_start 以来已完成的 tablet 数
    (SELECT COUNT(*) AS count_finished
    FROM __all_server_event_history
    WHERE module LIKE '%storage_ha%'
        AND event = 'tablet_finish_migration_task'
        AND value1 = @tenant_id
        AND value2 = @ls_id
        AND gmt_create >= (
        -- 获取最后一次启动迁移的时间
        SELECT MAX(gmt_create)
        FROM __all_server_event_history
        WHERE module LIKE '%storage_ha%'
            AND event = 'ls_ha_start'
            AND value1 = @tenant_id
            AND value2 = @ls_id
        )
    ) AS finished;
   

问题原因

• OceanBase 默认没有提供面向单个日志流维度的迁移进度可视化。

• 控制台和现有监控指标仅能展示整体租户或服务器级别的迁移情况，无法精确到 LS 维度。

• 多次中断/重试后，进度重叠，使得单纯依赖事件总数难以区分本次迁移的起止范围。

问题的风险及影响

• 当迁移耗时过长且中途多次重试时，运维无法及时发现卡顿或失败而被动等待，影响业务可用性。

• 对 SLA 要求高的业务场景（如在线 OLTP）迁移过程缺乏可靠监控，存在潜在服务中断或性能抖动风险。

适用版本

OceanBase 数据库 V4.x 版本。

解决方法

参考本文档 关键信息 这一章节内容。

规避方式

• 提前规划： 在执行大规模 UNIT 迁移前，评估日志流下 tablet 数量，分批次迁移或调整 LS 粒度，避免单 LS tablet 量过大。

• 细化告警： 配置基于 migrating_to_disk_ratio_percent 的告警，当进度在长时间内停滞不前（如 1 小时内进度增幅 < 5%）时自动通知运维。

• 自定义脚本： 定期（如每 5 分钟）执行上述 SQL 并将结果汇总到监控平台或日报，持续跟踪迁移进度。