【数据存储】灰度迁移：数据迁移的分批推进方案

实战应用：用在哪里

存储层从旧数据库迁移到新数据库时一次性切换风险高，灰度迁移分批推进：将数据按角色 ID 分成多个批次，每批次切换后验证数据完整性再推进下一批，出问题时只回滚当前批次，影响范围可控。

灰度迁移的分批策略

按角色 ID 取模分成 10 个批次，每批次切换后校验该批次的数据完整性再推进下一批，出问题时只回滚当前批次。

local TOTAL_BATCH = 10
local currentBatch = 0
local function migrateNextBatch()
    currentBatch = currentBatch + 1
    if currentBatch > TOTAL_BATCH then return end
    local startId = (currentBatch - 1) * 1000
    local endId = currentBatch * 1000
    for roleId = startId, endId do
        local old = readOld(roleId)
        if old then writeNew(roleId, old) end
    end
end

迁移完成的一致性校验

每批次迁移完成后比对新旧两库的记录数与关键字段，全部一致才标记该批次完成，不一致的批次自动重试。

local function verifyBatch(batchId)
    local startId = (batchId - 1) * 1000
    local endId = batchId * 1000
    local oldCnt, newCnt = 0, 0
    for roleId = startId, endId do
        if readOld(roleId) then oldCnt = oldCnt + 1 end
        if readNew(roleId) then newCnt = newCnt + 1 end
    end
    return oldCnt == newCnt
end

验证与监控

灰度迁移验证分批推进的顺序正确、每批次的数据完整性与一致性、回滚操作只影响当前批次。监控每批次迁移的耗时与差异数，耗时持续增长说明数据量超出预估需要调整批次大小。

踩坑记录

批次大小 1000 条在高峰期迁移耗时过长导致超时，改为 500 条一批并增加重试机制。迁移过程中新写入的数据没有同步到新库导致差异，双写策略在迁移期间同步写入新旧两库。灰度比例从 10% 开始逐步提升，一次性全量切换的风险不可控，按 10% → 30% → 50% → 100% 四个阶段渐进推进。迁移过程中旧库的读性能下降 15%，读流量分摊到从库缓解。

核对脚本建议按小时跑一次，只比对新表写入后的增量记录，字段逐个对照，差异行连同主键写入差异文件交给值班处理。双写期间两边的时间戳可能存在毫秒级偏差，比对时把时间字段剔除，只校验业务字段，能明显减少误报，值班也不必反复人工排查。

迁移期间保留旧表的只读入口，查询类需求在切换完成前一律走旧表，写请求才进新表。切换当天安排值班盯错误日志，回滚开关提前演练，异常时秒级切回，玩家侧无感知。灰度比例按行会逐步放大，先迁小行会再迁大会，出现差异时影响范围可控。