3、迁移场景分类:Schema变更、数据全量迁移、增量同步、回滚策略
在基于 Kubernetes 的数据库迁移实践中,迁移场景的准确分类是编排成功的基础。不同场景对任务编排的原子性、容错性、资源隔离和回滚能力有截然不同的要求。本章将迁移场景划分为四大核心类别:Schema 变更、数据全量迁移、增量同步与回滚策略,并分别阐述其技术特征与编排要点。
3.1 Schema 变更
Schema 变更涉及数据库表结构、索引、约束、存储过程等元数据的修改。在 Kubernetes 环境中,Schema 变更通常以 Job 或 Init Container 的形式执行,要求幂等性与可重入性。
关键特征:
- 原子性:单次变更要么全部生效,要么全部回滚,不允许部分应用。
- 顺序性:多个变更之间存在依赖关系(如先加列,后建索引),必须按序执行。
- 锁影响:DDL 操作可能引发表锁或元数据锁,需在低峰期执行并设置超时。
| 变更类型 | 典型操作 | 编排策略 | 风险等级 |
|---|---|---|---|
| 无损变更 | 新增列(允许 NULL)、新增索引(Online DDL) | 并行执行,依赖检查 | 低 |
| 有损变更 | 删除列、修改列类型、删除索引 | 串行执行,需数据校验 | 中 |
| 高风险变更 | 修改主键、分区表重组、字符集转换 | 串行执行,需预检查与备份 | 高 |
实践建议:在 Kubernetes 中,每个 Schema 变更应封装为独立的 Job,并通过 ConfigMap 或自定义资源(CRD)记录变更版本号。使用
initContainers 确保应用 Pod 启动前 Schema 已就绪。
3.2 数据全量迁移
数据全量迁移指将源数据库中的全部存量数据复制到目标数据库。在 Kubernetes 中,全量迁移通常拆分为多个并行工作单元(Shard/Chunk),以提升吞吐量并降低单点故障影响。
核心指标:
- 迁移速率:通常以 MB/s 或 rows/s 衡量,受网络带宽、磁盘 IO、索引数量影响。
- 数据一致性:迁移完成后需进行行数校验、Checksum 校验或抽样比对。
- 断点续传:支持从失败的分片重新开始,而非从头重试。
| 分片策略 | 适用场景 | Kubernetes 实现方式 | 优势 |
|---|---|---|---|
| 主键范围分片 | 自增主键、有序 UUID | Job 并行 + 分片参数 | 实现简单,无数据重叠 |
| 哈希分片 | 均匀分布、无自然分区 | Job 并行 + 模运算 | 负载均衡好 |
| 列表分片 | 按租户、地域分区 | 多个 Job 独立运行 | 业务隔离性强 |
# 全量迁移 Job 示例(主键范围分片)
apiVersion: batch/v1
kind: Job
metadata:
name: full-migration-shard-3
spec:
template:
spec:
containers:
- name: migrator
image: migrator:latest
env:
- name: SOURCE_DSN
valueFrom:
secretKeyRef:
name: db-secret
key: source-dsn
- name: TARGET_DSN
valueFrom:
secretKeyRef:
name: db-secret
key: target-dsn
- name: SHARD_START
value: "100000"
- name: SHARD_END
value: "200000"
- name: BATCH_SIZE
value: "5000"
restartPolicy: Never
backoffLimit: 3
注意:全量迁移期间,源库的写入操作不会自动同步到目标库。必须在全量迁移完成后,立即启动增量同步,否则会产生数据空洞。
3.3 增量同步
增量同步负责捕获源数据库在迁移过程中的持续变更(INSERT/UPDATE/DELETE),并实时或准实时地应用到目标数据库。在 Kubernetes 中,增量同步通常以长运行 Deployment 或 StatefulSet 形式部署,配合消息队列实现解耦。
技术选型对比:
| 同步方式 | 原理 | 延迟 | Kubernetes 部署形态 | 典型工具 |
|---|---|---|---|---|
| 基于 Binlog/CDC | 解析数据库事务日志 | 秒级 | StatefulSet + 持久化偏移量 | Debezium, Canal |
| 基于时间戳/版本号 | 轮询更新时间戳列 | 分钟级 | Deployment + 定时任务 | 自研脚本 |
| 基于触发器 | 数据库触发器记录变更 | 实时 | Deployment + 消费队列 | 自研 + 中间表 |
3.4 回滚策略
回滚策略是迁移编排的最后一道防线。在 Kubernetes 中,回滚不是简单的“撤销”,而是通过版本化、快照、反向同步等手段,将数据库恢复到迁移前的稳定状态。
回滚分类:
- Schema 回滚:通过 DDL 反向语句(如
ALTER TABLE ... DROP COLUMN)或备份恢复。 - 数据回滚:全量迁移阶段使用快照恢复;增量同步阶段使用反向同步或时间点恢复(PITR)。
- 应用回滚:Kubernetes Deployment 回滚到上一版本,配合数据库回滚保持兼容。
| 回滚场景 | 回滚手段 | 影响范围 | 编排实现 |
|---|---|---|---|
| Schema 变更失败 | 执行反向 DDL 或恢复备份 | 仅变更的表 | Kubernetes Job + 版本号匹配 |
| 全量迁移数据不一致 | 清空目标库,重新迁移 | 整个目标库 | Job 链式重试 + 数据校验 |
| 增量同步数据冲突 | 反向同步或跳过冲突记录 | 冲突记录所在分区 | 消费组逻辑 + 死信队列 |
| 整体迁移失败 | 切换回源库,停止目标库写入 | 全系统 | Argo Workflows DAG + 人工确认 |
# Schema 回滚 Job 示例
apiVersion: batch/v1
kind: Job
metadata:
name: schema-rollback-v1-to-v0
spec:
template:
spec:
containers:
- name: rollback
image: migrator:latest
env:
- name: TARGET_DSN
valueFrom:
secretKeyRef:
name: db-secret
key: target-dsn
- name: ROLLBACK_SQL
value: |
ALTER TABLE users DROP COLUMN IF EXISTS new_column;
ALTER TABLE orders DROP INDEX IF EXISTS idx_new;
- name: DRY_RUN
value: "false"
command: ["/bin/sh", "-c", "echo \"$ROLLBACK_SQL\" | mysql -h ..."]
restartPolicy: Never
backoffLimit: 2
关键原则:
- 回滚脚本必须提前准备,在迁移执行前即生成并存储在 ConfigMap 或 Secret 中。
- 回滚操作必须幂等,多次执行不会产生副作用(如
IF EXISTS、IF NOT EXISTS)。 - 回滚后必须进行数据校验,确保源库与目标库状态一致。
最佳实践:在 Argo Workflows 或 Tekton 中,将回滚步骤定义为独立的 DAG 任务,并设置
onExit 或 onError 触发器。当迁移主流程失败时,自动触发回滚 DAG,无需人工介入。