项目地址：[https://github.com/elison2000/db-archive](https://github.com/elison2000/db-archive)

很多系统的数据库问题并不是某一条 SQL 突然变慢，而是数据一直在增长：订单、交易流水、消息、审计日志不断写入，主库的索引越来越大，备份窗口越来越长，容量和运维成本也随之上升。

但“旧数据”通常不能直接删除。它可能还要满足合规查询、问题追溯、财务对账或离线分析。一个更稳妥的做法是：把满足条件的历史数据迁移到归档库，确认两端结果一致后，再按策略清理源表。

这篇文章介绍 [db-archive](https://github.com/elison2000/db-archive) 的设计与实践。它不是实时同步工具，而是一个面向数据库大表生命周期管理的批处理归档服务。项目最有价值的地方，不只是“把数据复制到另一张表”，而是把异构数据库、业务低峰窗口、分表和分区表清理组合成了一套可执行的归档方案。

## 先看四个核心卖点

### 1. 异构数据库归档：MySQL/OceanBase 到 Doris

源库和目标库不需要是同一种数据库。项目通过统一的 Source/Sink 接口屏蔽数据库差异，支持 MySQL、OceanBase、Oracle、PostgreSQL 和 Doris 的组合，典型链路是：

```text
MySQL / OceanBase（在线交易库）
              │
              ▼
        db-archive 批量归档
              │
              ▼
      Doris（历史分析/查询库）
```

这使得在线库和历史数据可以承担不同职责：在线库保留近期热数据，Doris 集中保存历史冷数据并服务报表、检索和分析查询。列式存储、压缩和面向分析的执行引擎通常能显著降低历史数据的存储成本，并改善大范围扫描、聚合和多维查询的体验；实际收益仍取决于表模型、分桶、排序键、压缩策略和查询模式，不能简单理解为任何场景都会自动提速。

项目还针对 Doris 目标端使用 Stream Load，数据源只需额外配置 FE HTTP 地址。归档控制面仍由 MySQL 元数据库保存，因此业务源库、分析目标库和控制面可以完全解耦。

这条链路的实际收益主要体现在三个方面：

- **导入速度快**：Doris Sink 使用 Stream Load 批量导入，减少逐行写入和网络往返。在合理的批量大小、并发、表模型和集群资源配置下，实际吞吐可以达到每秒 10 万行以上，适合持续处理历史数据。
- **压缩率高**：历史数据进入 Doris 后使用列式存储和压缩，常见业务表的存储体积相比 MySQL/InnoDB 可以达到约 `1:6` 到 `1:10` 的压缩收益，显著降低长期保存成本。最终比例会受字段类型、重复度、排序键、分桶和压缩算法影响，应以实际数据压测为准。
- **查询速度快**：在线库负责交易查询，Doris 负责历史数据的范围扫描、聚合和多维分析，避免报表查询与在线事务争抢资源。对于按时间过滤、聚合统计和大范围历史检索，列式执行通常比直接查询生产库更合适。

### 2. 自定义时间窗口：把归档安排在业务低峰

归档任务支持一个或多个 `HH:MM-HH:MM` 时间窗口，例如：

```text
00:30-06:00
```

也可以配置多个窗口：

```text
00:30-06:00,12:30-13:30
```

调度器只有在窗口内才会把任务提交给 worker；跨午夜窗口和 `00:00-00:00`（全天）也有明确语义。任务如果运行到窗口结束，会进入 `paused`，下一个可用窗口再恢复执行。这样可以把读取、写入和删除压力避开高峰，而不必为了低峰时段另写一套外部 cron 脚本。

### 3. 支持分表：一份配置覆盖一组物理表

对于按月份、租户、区域或哈希后缀拆分的业务表，可以用范围模板批量展开源表和目标表：

```text
source_table: orders_{00..09}
sink_table:   orders_archive_{00..09}
```

系统会预览并检查展开结果，再为每一对表生成单次任务；每个单次任务还可以继续按 ID 或时间切分成子任务。也就是说，项目同时解决了“多张表怎么配置”和“单张大表怎么分批”两个问题。

### 4. 分区表的低压力方案：每天复制，定期手动清理分区

对生产库分区表，最推荐的方案往往不是每天执行大量 `DELETE`，而是：

```text
每天：db-archive 使用 copy_only 复制已封存分区的数据
定期：人工确认归档结果后，执行数据库原生的 DROP/TRUNCATE PARTITION
```

删除分区通常是数据库级元数据操作，避免了逐行删除带来的 undo/redo、锁竞争、索引维护和长事务压力。db-archive 负责可控地读取、限速、复制和记录结果；分区生命周期则由 DBA 按保留策略定期清理。这个方案尤其适合按天或按月分区、历史分区一旦封存就不再更新的表。

需要强调的是，手动清理前仍要核对任务状态、读取/写入行数和目标端查询结果，并确认分区内没有迟到数据或仍需在线访问的记录。分区清理不是自动回滚操作，保留备份和人工审批流程仍然必要。

## 先定义问题：归档不是简单的 `INSERT ... SELECT`

表级归档至少要同时处理四个问题：

1. **范围**：本次归档究竟搬哪些行，如何避免重复和遗漏？
2. **压力**：大表一次性读取、写入或删除，会不会影响线上业务？
3. **一致性**：复制完成后，怎样证明目标端确实收到了预期数据？
4. **可恢复性**：任务暂停、失败或被终止后，能否定位到具体分片并继续？

因此，db-archive 把一次归档拆成几个显式阶段：

```text
配置任务 -> 生成单次任务 -> 预检数据源/表结构
        -> 生成子任务 -> 分批读取/写入 -> 行数核对
        -> 删除（可选） -> 保存状态和任务日志
```

这个拆分很重要。它让“配置正确性”“调度”“数据搬迁”和“删除风险”各自拥有清晰的边界，也让失败之后可以从子任务维度观察和处理。

## 整体架构：元数据库只管控制面

服务由 Go 编写，HTTP 层使用 Gin，元数据使用 GORM 保存到 MySQL。业务数据库通过统一的 Source/Sink 接口接入，当前支持 MySQL、OceanBase、Oracle、PostgreSQL 和 Doris。

```mermaid
flowchart LR
    UI[Web UI / REST API] --> API[Gin Server]
    API --> Meta[(元数据库 MySQL)]
    Planner[Planner 每分钟扫描] --> Scheduler[Scheduler]
    Meta --> Planner
    Scheduler --> Workers[Worker Pool]
    Workers --> Archive[Archiver]
    Archive --> Source[Source 数据源]
    Archive --> Sink[Sink 归档库]
    Archive --> Logs[本地日志 / 任务日志表]
```

元数据库保存的是数据源、周期任务、单次任务、子任务、用户、审计日志和任务日志等控制面数据；它不参与业务表的数据搬迁。这样做有两个好处：

- 归档目标可以是与控制面完全不同的数据库类型。
- 任务状态、进度和日志不会依赖业务库中的表结构。

不同数据库的差异被收敛在 `engine/*` 中。归档层只依赖这些能力：读取字段和分片边界、统计行数、批量读取、批量写入以及批量删除。

## 三级任务模型：配置、执行、分片

项目把任务建模成三层：

```text
archive_jobs              周期任务，可重复生成实例
    └─ archive_tasks      一次实际执行
          └─ archive_sub_tasks  一个范围分片
```

### 周期任务

周期任务描述“以后怎么归档”：源表、目标表、条件、执行间隔、时间窗口、切分字段、批量大小和限速等。服务每天 00:00 检查周期任务，也支持通过 API 手动生成当天的单次任务。

条件可以使用日期宏，例如：

```sql
create_time >= '{{today-31}}'
AND create_time < '{{today-30}}'
```

使用左闭右开区间，可以避免相邻周期重复处理同一时间点的数据。

### 单次任务

单次任务是调度器真正提交的执行单位。周期任务会在生成时解析日期宏，并把任务名称加上日期；手动创建的单次任务则可以直接使用固定条件。

### 子任务

如果不配置 `split_column`，任务只会生成一个子任务。配置后，系统先从源库计算切分边界，再生成类似下面的条件：

```sql
archive_condition
AND id >= 1000001
AND id < 2000001
```

每个子任务都有独立的状态、开始/结束时间、读取行数、写入行数、删除行数和错误消息。大表因此被转换成一组可并发、可重试、可观测的小批次。

切分大小既可以是行数（例如 `1000000`），也可以是时间间隔（例如 `1d`、`1m`、`1y`）。对于按时间增长的表，时间切分通常比一次性扫描更容易控制线上负载；对于有序自增主键，按 ID 切分则更直接。

## 一次子任务是怎样执行的

`Archiver.ExecuteSubTask` 根据归档模式选择执行路径：

| 模式 | 复制到目标 | 删除源数据 | 删除前核对 |
| --- | --- | --- | --- |
| `copy_only` | 是 | 否 | 不适用 |
| `move` | 是 | 是 | 是 |
| `delete_safely` | 否 | 是 | 是 |
| `delete_only` | 否 | 是 | 否 |

复制阶段采用生产者/消费者流水线：源端 `FetchBatch` 持续读取数据，写入端 `InsertBatch` 从 channel 消费并批量落库。两端通过 `errgroup` 共享取消上下文，一侧失败时另一侧会尽快停止。

复制完成后，代码会立即检查 `rowsRead == rowsInserted`。`move` 模式在删除之后还会检查 `rowsInserted == rowsDeleted`。这些检查不是完整的内容校验，但能拦截最常见的“读到了、却没有完整写入”或“删多了/删少了”问题。

对于 `delete_safely` 和 `move`，删除前会分别在源库和目标库执行条件计数。目标端条件中的数据库名会被替换为目标 schema，避免带子查询的条件仍然指向源库。只有两端行数相等，任务才会继续删除源数据。

## 一个更适合生产的分区表实践

假设在线订单表按 `create_date` 每天分区，业务只要求主库保留最近 90 天数据。可以把归档设计成两条相互独立的操作：

1. 每天在低峰窗口创建一个 `copy_only` 任务，将 91 天前已经封存的分区复制到 Doris。
2. 任务完成后观察一段时间，核对源端和 Doris 的行数、关键查询和任务日志。
3. 每周或每月由 DBA 按保留策略手动清理已确认的历史分区，例如执行数据库对应的 `DROP PARTITION` 或 `TRUNCATE PARTITION`。

示意性的周期条件可以写成：

```sql
create_time >= '{{today-91}}'
AND create_time < '{{today-90}}'
```

这套做法的关键不是“把删除按钮藏起来”，而是让删除动作从在线归档链路中独立出来：复制可以每天稳定运行，分区清理可以在更宽的审批和维护窗口执行。相比逐行 `DELETE`，它通常更容易控制事务大小、锁影响和日志增长。

如果业务表不是分区表，或者历史数据仍然混在热数据中，再考虑 `move` 或 `delete_safely`。这两种模式会逐批删除源数据，必须根据索引、锁等待和线上流量谨慎设置 `delete_batch_size`、`delete_rate_limit` 和时间窗口。

## 调度器的三个并发边界

归档系统的并发不能只看 worker 数量。db-archive 的调度器有三层约束：

1. **全局并发**：限制同时运行的任务总数。
2. **数据源并发**：限制同一个 source 数据源上的任务数，避免连接数和 I/O 突然升高。
3. **源表并发**：同一源库、同一张源表同时只允许一个任务执行，避免多个任务互相争抢同一张在线表。

调度队列按 source 分组，并使用轮转游标挑选任务。这样一个繁忙数据源不会完全阻塞其他数据源，任务也不会因为简单的先进先出队列而失去基本的公平性。

任务内部还可以设置子任务并发（代码将其限制在 1 到 32 之间），插入和删除分别使用 token bucket 限速器。最终吞吐量取决于：

```text
实际吞吐量 ≈ min(全局并发、源库并发、任务并发、数据库/网络能力)
```

上线时建议先使用低并发和较小批量，观察源库连接数、锁等待、慢查询和目标库写入延迟，再逐步提高参数。

## 状态机让暂停和恢复变得可解释

任务同时维护准备阶段和执行阶段：

```text
准备阶段：init -> preparing -> prepared
                    \-> failed

执行阶段：init -> queueing -> running -> completed
                                  |-> failed
                                  |-> paused
                                  |-> stopped
                                  \-> resuming -> queueing
```

准备阶段只负责生成子任务；执行阶段只处理已经落库的子任务。任务超出 `time_window` 会进入 `paused`，收到取消信号会进入 `stopped`，普通错误则进入 `failed`。

恢复时，默认跳过已经完成的子任务；如果确认目标端需要覆盖或重做，可以请求：

```json
{"retry_failed_sub_tasks": true}
```

需要注意的是，`stopped` 并不等于自动回滚。终止可能发生在复制或删除的中间，恢复前仍然要核对源表和目标表，必要时清理残留数据或使用 `upsert` 重新执行。

## 分表模板：把重复配置变成批量任务

很多业务会把表按月份、租户或哈希后缀拆开，例如 `orders_00` 到 `orders_09`。项目支持使用一个数字范围模板：

```text
source_table: orders_{00..09}
sink_table:   orders_archive_{00..09}
```

创建前可以通过 `POST /api/archive-tasks/preview-tables` 预览展开结果和表存在性，再通过 `batch-create` 批量创建单次任务。表名展开和行范围切分是两层能力，可以组合使用：先展开多张表，再对每张表按 ID 或时间生成子任务。

使用多源表写入一个目标表时，需要额外确认字段结构兼容，以及主键/唯一键不会冲突。模板功能只支持一个数字范围表达式，不能替代复杂的表路由规则。

## 从源码启动一个最小实例

环境要求是 Go 1.25 和一个可连接的 MySQL 元数据库。先初始化元数据库：

```bash
mysql -h <meta-host> -P 3306 -u <meta-user> -p \
  -e 'CREATE DATABASE IF NOT EXISTS db_archive'
mysql -h <meta-host> -P 3306 -u <meta-user> -p db_archive < sql/init.sql
```

准备与二进制同目录的 `config.ini`（下面只放占位符）：

```ini
http_port = 8080
concurrency = 2
source_concurrency = 1
http_auth_enabled = false

[db]
host = 127.0.0.1
port = 3306
user = db_archive
password = <meta-password>
database = db_archive
```

编译并启动：

```bash
go build -o db_archive ./cmd
./db_archive
```

启动后访问 `http://127.0.0.1:8080/home`。这里为了本地快速体验关闭了鉴权，生产环境必须接入可信认证网关并改为 `http_auth_enabled = true`。第一次使用时，先配置并测试数据源，再做表结构预检，最后创建小范围的 `copy_only` 任务验证链路。确认行数、字段和目标查询都正确后，再切换到 `move` 或 `delete_safely`。

## 生产环境的安全清单

- 归档前确认源端拥有 `SELECT`，复制需要目标端 `INSERT`，删除需要源端 `DELETE`。
- 优先使用有索引、非空且分布均匀的切分字段。
- 周期条件使用左闭右开区间，并为每个周期保留固定的单次任务记录。
- 先 `copy_only`，后 `delete_safely`；只有明确确认过的数据才使用 `delete_only`。
- 开启 `http_auth_enabled`，让可信网关完成登录和身份校验，再注入 `X-User-ID`；后端端口不能暴露给可伪造请求头的客户端。
- 把 `logs/`、`gorm.log`、`http.log` 纳入日志轮转和磁盘监控，但不要在任务运行中移动日志文件。
- 不要把 `config.ini` 中的密码、密钥和生产连接信息提交到版本库。
- 归档不是备份，也没有自动回滚；对 `stopped`、`failed` 任务保留人工核对步骤。

## 这套设计的边界

db-archive 适合“按条件、按批次、按时间窗口”搬运历史数据。它刻意没有覆盖实时 CDC、字段映射、数据清洗、复杂多表 Join、数据库对象迁移和对象存储导出。如果需求是实时同步或复杂 ETL，应选择对应的 CDC/ETL 工具，而不是把归档服务继续堆成一个万能数据平台。

## 结语

数据库归档的难点从来不是把数据从 A 库写到 B 库，而是把一次高风险的数据变更拆成可以调度、限速、核对、暂停、恢复和审计的步骤。

db-archive 的核心取舍可以概括为：用元数据库保存控制面，用统一接口屏蔽数据库差异，用子任务拆分大表，用多级限流保护线上负载，用行数核对降低删除风险。它并不承诺“任何场景都能自动回滚”，但提供了一条足够清晰的工程路径：先小范围验证，再逐步放量，最后让历史数据从主库生命周期中有序退出。


项目地址：https://github.com/elison2000/db-archive

db-archive：跨数据库、低峰窗口与分区表归档实践

这篇文章介绍开源项目db-archive的设计与实践。它不是实时同步工具，而是一个面向数据库大表生命周期管理的批处理归档服务。项目最有价值的地方，不只是“把数据复制到另一张表”，而是把异构数据库、业务低峰窗口、分表和分区表清理组合成了一套可执行的归档方案。

数据库

运维

开发工具

db-archive是面向数据库大表生命周期管理的批量归档服务，支持MySQL/OceanBase到Doris等异构数据迁移，通过统一Source/Sink接口实现跨库归档。采用三级任务模型拆分大表为可并发子任务，支持自定义时间窗口、分表模板与分区表低压力清理。系统通过行数核对保障数据一致性，并提供copy_only、move、delete_safely等安全模式，助力历史数据有序退出主库。

数据清洗

代码解释

对象存储

数据迁移

日志文件

PostgreSQL

路由

MySQL

2026上云采购 | AI焕新·智启新局

tchoused

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

db-archive是面向数据库大表生命周期管理的批量归档服务，支持MySQL/OceanBase到Doris等异构数据迁移，通过统一Source/Sink接口实现跨库归档。采用三级任务模型拆分大表为可并发子任务，支持自定义时间窗口、分表模板与分区表低压力清理。系统通过行数核对保障数据一致性，并提供copy_only、...

db-archive：跨数据库、低峰窗口与分区表归档实践-腾讯云开发者社区-腾讯云

db-archive：跨数据库、低峰窗口与分区表归档实践

db-archive：跨数据库、低峰窗口与分区表归档实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐