数据库迁移概述
数据库迁移是将数据或数据库结构从一个环境迁移到另一个环境的过程。在异步任务超时处理课程中，理解迁移的本质是设计可靠重试与错误恢复机制的前提。迁移操作通常涉及大量数据、长时间运行的事务以及复杂的依赖关系，这些特性天然容易触发超时与部分失败。
1. 数据库迁移的定义
数据库迁移（Database Migration）是指将数据库的结构定义（Schema）或业务数据（Data）从一个源端完整、一致地转移到目标端的过程。迁移的核心目标包括：
- 数据完整性：迁移前后数据内容、约束、关联关系保持一致。
- 结构等价性：目标端的表结构、索引、视图、存储过程等与源端逻辑等价。
- 可回滚性：当迁移过程中出现超时或错误时，能够恢复到迁移前的稳定状态。
- 最小停机：对于在线系统，迁移应尽量缩短业务不可用窗口。
关键认知： 数据库迁移不是简单的"复制粘贴"。在异步任务场景下，迁移操作往往被拆分为多个子任务（如分批迁移、增量同步），每个子任务都可能因网络抖动、锁竞争、资源耗尽等原因超时。因此，迁移设计必须内置超时检测与重试语义。
2. 常见迁移类型
根据迁移对象的不同，数据库迁移主要分为结构迁移和数据迁移两大类。实际项目中通常两者结合进行。
| 迁移类型 | 迁移对象 | 典型操作 | 超时风险点 |
|---|---|---|---|
| 结构迁移 | 表定义、索引、视图、触发器、存储过程、函数、序列等 | CREATE TABLE / ALTER TABLE / CREATE INDEX / CREATE VIEW | 大表加索引锁等待、DDL 语句执行时间过长、元数据锁冲突 |
| 数据迁移 | 业务行记录、配置数据、历史归档数据 | INSERT INTO ... SELECT / 批量导出导入 / 流式复制 | 大事务提交超时、网络传输中断、主键冲突、外键约束检查超时 |
| 全量迁移 | 源端全部数据与结构 | 一次性导出 + 导入 | 数据量大导致单次任务超时、磁盘空间不足、连接超时 |
| 增量迁移 | 源端变更数据（CDC） | 基于 Binlog / WAL / 触发器捕获变更并回放 | 消费延迟堆积、断点续传状态丢失、重复数据导致唯一键冲突 |
实践建议： 在异步任务框架中，结构迁移通常作为"一次性前置任务"执行，而数据迁移则适合拆分为多个"可重试的子任务"。对于增量迁移，必须记录消费位点（Offset）以支持断点续传，这是超时恢复的核心依赖。
3. 迁移工具介绍
业界存在多种成熟的数据库迁移工具，它们在超时处理、重试机制、错误恢复方面的能力差异显著。以下按使用场景分类介绍主流工具：
| 工具名称 | 适用场景 | 超时/重试支持 | 典型命令/配置 |
|---|---|---|---|
| mysqldump | MySQL 全量逻辑备份与迁移 | 弱：单连接、无断点续传、超时直接失败 | mysqldump --single-transaction --quick |
| pg_dump / pg_restore | PostgreSQL 全量迁移 | 中：支持并行转储、自定义格式可分段恢复 | pg_dump -j 4 -Fd -f dump_dir |
| DataX | 异构数据源批量同步（阿里开源） | 强：支持通道控制、任务拆分、失败重试、限流 | python datax.py job.json |
| Debezium | CDC 实时增量迁移（Kafka 生态） | 强：基于 Kafka Offset 持久化、自动重试、Exactly-Once 语义 | 配置 offset.storage.file.filename |
| Liquibase / Flyway | 数据库版本控制与结构迁移 | 中：支持变更集回滚、校验和检测、失败锁定 | liquibase update --rollback-on-error |
| gh-ost / pt-online-schema-change | MySQL 在线 DDL（无锁结构变更） | 强：支持暂停、恢复、超时自动清理临时表 | gh-ost --max-lag-millis=1500 |
注意： 选择迁移工具时，不能只看功能完备性，更要评估其在超时场景下的行为。例如，mysqldump 在连接超时后不会自动重试，可能导致部分数据丢失；而 DataX 和 Debezium 内置了重试与断点续传机制，更适合构建高可靠的异步迁移任务。
4. 迁移流程与超时风险点
下图展示了一个典型的数据库迁移流程，并标注了每个阶段可能出现的超时风险点：
5. 迁移策略选择矩阵
不同的业务场景对迁移的停机时间、数据一致性、超时容忍度要求不同。以下矩阵帮助选择最合适的迁移策略：
| 业务场景 | 推荐策略 | 超时处理方式 | 典型工具组合 |
|---|---|---|---|
| 小数据量（< 10GB）离线迁移 | 全量导出 + 全量导入 | 单次任务超时后整体重试 | mysqldump + mysql |
| 大数据量（> 100GB）在线迁移 | 全量 + 增量 + 在线校验 | 分片任务超时仅重试失败分片 | DataX + Debezium + pt-table-checksum |
| 结构频繁变更的版本管理 | 基于变更集的增量迁移 | 失败变更集自动回滚并锁定 | Flyway / Liquibase |
| 零停机 DDL 变更 | 在线无锁结构变更 | 超时自动暂停，清理临时表 | gh-ost / pt-online-schema-change |
核心原则： 在异步任务超时处理框架中，数据库迁移应遵循"可拆分、可重试、可校验"三大设计原则。将大迁移拆分为多个小任务，每个任务设置合理的超时阈值，失败后根据错误类型（可重试 vs 不可重试）决定是否自动重试或进入人工干预流程。这是后续章节构建重试机制的基础。