Module 02 TiDB 集群备份和恢复

本章节围绕数据备份\恢复、数据导出\导入、数据一致性校验 ，完整覆盖 TiDB 全量 / 增量、逻辑 / 物理备份、异构迁移、数据校验工具链，是生产环境数据容灾、迁移、故障恢复的必备知识。

一、模块整体框架

课程分为 5 节，形成完整闭环：

1. Lesson07：备份恢复策略总览
2. Lesson08：Dumpling 逻辑导出工具（全量 SQL/CSV 导出）
3. Lesson09：TiDB Lightning 高速导入（海量数据入库）
4. Lesson10：BR 分布式物理备份恢复（生产主流冷热备份）
5. Lesson11：sync-diff-inspector 数据一致性校验（迁移 / 备份后核对数据）

二、Lesson07 备份恢复策略概述

1. 核心学习目标

区分热 / 温 / 冷备份、逻辑 / 物理 / 复制备份三类划分维度，掌握不同备份方案优缺点、适用场景，能够根据业务数据量、RTO/RPO 要求选择工具。

2. 备份按业务影响划分（热 / 温 / 冷）

表格

3. 三大备份技术体系

1. 逻辑备份 工具：Dumpling 原理：导出 SQL/CSV 文本，记录每行数据逻辑语句 优势：跨数据库兼容（MySQL ↔ TiDB）、粒度灵活（库 / 表过滤） 劣势：海量数据导出速度慢，占用连接资源
2. 物理备份 工具：BR、操作系统文件拷贝 原理：直接复制 TiKV 底层 SST 数据文件，二进制副本 优势：速度极快，TB 级数据友好，支持增量备份 劣势：仅能恢复至 TiDB，无法跨异构数据库，版本、字符集强兼容限制
3. 基于复制的备份 工具：TiCDC / Binlog 同步 原理：实时同步增量数据至备用集群，实现持续备份 优势：生产集群无备份压力，RPO 极低，可同时做灾备 + 数据同步 劣势：依赖同步链路，初期需要全量基线数据

4. 主流工具对比表

三、Lesson08 Dumpling 逻辑导出工具

1. 工具定位

Dumpling 是 TiDB 官方配套的逻辑导出工具，用于从 TiDB/MySQL 导出 SQL/CSV 格式逻辑数据，适配异构数据库迁移、小体量全量备份场景，和 BR（物理备份工具）形成互补。

2. 基础信息

• 安装：tiup install dumpling或者通过TiDB-community-boolkit安装包获取
• 最小权限：SELECT、RELOAD、LOCK TABLES、REPLICATION CLIENT、PROCESS
• 底层原理：通过 TiDB 快照读取数据，不锁表，依靠 MVCC 保证一致性。

3. 核心特性

1. 支持 SQL、CSV 两种导出格式；
2. table-filter灵活过滤库、表，支持通配符筛选；
3. 支持直接导出至 Amazon S3云盘；
4. 可配置并发线程、单文件大小限制、快照一致性级别。

4. 一致性与性能优化核心参数

4.1. 一致性参数 --consistency

4.2. 并发性能调优参数

5. 适用场景

5.1. 推荐适用场景

1. 数据量级＜50GB：中小体量全量逻辑导出，工具调度、分片开销可控；
2. 异构系统迁移需求：导出标准 SQL/CSV 文件，可直接导入 MySQL、PostgreSQL 等各类关系型数据库；
3. 导出效率要求宽松：非极速备份场景，可接受数小时级导出耗时。

5.2. 不适用场景

1. 需要导出 SST 原始文件：SST 属于 TiDB 底层物理文件，由 BR 工具负责导出，Dumpling 仅做逻辑解析导出；
2. 增量备份诉求：Dumpling 仅支持全量一致性导出，无增量备份能力，增量场景搭配 TiCDC/binlog 同步；
3. 数据量＞50GB 且时效要求高：逻辑导出逐行解析、开销大，超大库极速备份优先选用 BR 物理备份。

6. 导出示例

-- 1 导出 SQL 格式文件
dumpling -u root -P 4000 -h 127.0.0.1 \
--filetype sql -t 8 -o /tmp/test \
-r 200000 -F 256MiB

• -u/-P/-h：数据库账号、端口、连接地址；
• --filetype sql：导出后缀为.sql的 SQL 脚本文件；
• -t 8：启用 8 个导出并发线程；
• -o /tmp/test：导出文件存放目录；
• -r 200000：每个分片文件最多 20 万行数据；
• -F 256MiB：单个文件最大 256MB，超出自动拆分新文件。

-- 2 导出 CSV 格式文件
./dumpling -u root -P 4000 -h 127.0.0.1 \
-o /tmp/test --filetype csv
​
--3 精细化数据筛选导出
--where "id < 100"
--filter "employees.*" -B employees \
-T employees.WorkOrder

• --filetype csv指定导出 CSV 文本格式，适配大数据分析工具、数仓离线导入场景。
• --where "id < 100"：行级过滤，仅导出满足条件的数据；
• -B employees：指定仅导出employees库；
• -T employees.WorkOrder：精准指定仅导出单张表；
• --filter：更灵活的库表黑白名单过滤规则。

7、Dumpling 导出文件结构说明

导出目录会自动生成规范文件，核心文件如下：

1. metadata：导出元信息，包含快照时间点、导出参数、数据库版本，用于校验一致性；
2. {schema}-schema-create.sql：对应数据库的建库语句；
3. {schema}.{table}-schema.sql：单张表建表语句、索引、约束定义；
4. {schema}.{table}.{序号}.sql/csv：分片业务数据文件，按行数 / 大小拆分。

四、Lesson09 TiDB Lightning 高速数据导入

1. 工具定位

配套 Dumpling 的导入工具，用于静态文件批量灌入 TiDB，支持 Dumpling 导出文件、CSV、Parquet，分为两种导入模式，适配不同业务需求。

2. 两种导入模式核心对比

3. 部署与前置要求

3.1. 硬件资源配置建议

3.2. 必做前置检查项

1. 集群状态：集群版本匹配、无宕机节点、Region 健康无异常副本、无调度任务积压；
2. 权限与空间：导入账号拥有库表 DDL/DML 权限、TiKV 磁盘预留充足导入扩容空间；
3. 业务预检：核查目标表为空表、大 CSV 源文件格式合规无脏数据、集群 Region 分布均衡避免热点；

3.3. 工具安装方式

• TiUP 一键安装：tiup install lightning
• 安装离线工具包：部署 TiDB-community-toolkit 集成套件获取 Lightning 程序

4. 并行导入与数据过滤规则

4.1. 并行导入核心约束

1. 并行导入仅支持空表，存量表并行导入会引发主键冲突、索引错乱；
2. 超大体量导入优先选择 Physical 模式，导入速度可达 TB 级每小时；
3. 硬性限制：Physical、Logical 两种模式禁止同时对同一集群执行导入任务，会造成 Region 元数据紊乱。

4.2. 数据过滤实现方式

1. 命令行参数：使用 -f 参数配置黑白名单过滤库表；
2. 配置文件：编写 mydumper.filter 规则文件，灵活配置库表包含 / 排除规则，适配多库多表精细化筛选。

5. 断点续传核心能力

5.1. 断点配置释义

[checkpoint]
enable = true
# driver可选：file(本地文件存储断点) / mysql(独立库存储断点)
driver = "file"

• 开启后 Lightning 会实时记录每一张表、每一分片导入进度，任务异常崩溃、服务器重启后，重启任务自动从断点续导，完全规避重复导入、数据重复问题。

5.2. 断点管理运维命令

清理指定库表断点记录（重新全量导入场景使用）：

tidb-lightning-ctl --checkpoint-remove="`schema`.`table`"

5.3. 配套辅助能力

1. 内置 Web 可视化页面：支持在线查看任务进度、分片导入状态、失败分片详情、任务启停管理；
2. 后台常驻启动命令：

nohup ./tidb-lightning -config tidb-lightning.toml > nohup.out &

后台运行任务，日志持久化留存，方便后续问题排查。

五、Lesson10 BR（Backup & Restore）分布式物理备份恢复

1. 工具定位

BR（Backup & Restore）是 TiDB 官方物理备份恢复工具，分布式物理热备份，直接复制 TiKV SST 文件，兼顾速度与在线业务无中断，支持全量 + 增量备份、对象存储（S3）、加密备份。

2. 核心原理

• 热备份：基于 PD 全局时间戳 TSO 创建一致性快照，备份期间集群正常读写；

• 物理备份：直接拷贝 TiKV 底层 SST 数据文件，无 SQL 解析开销，TB 级数据备份效率远超 Dumpling；

• 增量备份：基于上次备份 TSO，仅备份新增变更数据，大幅缩减备份窗口。

3. 备份输出文件

• .sst：TiKV 原始数据文件，核心业务数据；
• backupmeta：备份元数据，记录快照时间、库表信息、版本；
• backup.lock：锁文件，防止同一目录并发写入备份。

4. 适用场景

• 大规模 TiDB 集群日常一致性备份；

• TB 级数据同架构迁移、机房灾备；

• 长期归档备份至 S3/GCS 对象存储；

• 增量备份缩短每日备份耗时。

5. 重要使用限制

5.1. 版本与配置强兼容约束

• GBK 字符集降级限制

无法将包含charset=GBK表的备份集恢复至 v5.4.0 之前旧集群，低版本 TiDB 原生对 GBK 支持不完善，恢复会出现字符错乱、元数据异常。

• 版本预检强制要求

备份 / 恢复前必须执行br check-requirements校验集群版本、组件兼容性，跨大版本恢复极易触发元数据不兼容报错。

• 两项全局参数必须前后一致

  • tidb_enable_clustered_index（聚簇索引开关）：上下游集群配置不一致会导致主键存储结构不同，恢复后索引失效、查询报错；
  • new_collations_enabled_on_first_bootstrap（新排序规则开关）：集群初始化后固定不可变更，上下游不一致会引发字符串排序、唯一校验异常。

• 全局临时表兼容

v5.3.0 版本 BR 不会备份全局临时表，恢复后临时表结构与数据丢失，需业务侧自行重建临时表逻辑。

5.2. 数据同步与链路限制

BR 物理恢复生成的存量数据，无法被 TiCDC/TiDB Binlog 捕获同步至下游。

原因：BR 直接向 TiKV 写入 SST 物理文件，不会生成 binlog 变更日志，新增业务写入数据才可正常同步；历史存量数据需单独通过 Dumpling 同步下游。

5.3. 运维环境与任务约束

• 硬件基线要求 推荐部署在8 核 CPU、16GB 内存以上独立节点，BR 会并行拉取 / 推送分片数据，低配节点会造成任务卡顿、备份耗时翻倍。

• 执行窗口规范

  • 备份：必须业务低峰执行，备份会扫描 Region、占用 TiKV IO / 网络资源，高峰执行会抬升业务读写延迟；
  • 恢复：不建议直接在线生产集群执行恢复操作，恢复会大量 Ingest SST 文件抢占集群资源，极易引发业务抖动，优先在备用集群验证后再操作。

• 任务并行限制 禁止多个 BR 备份、恢复任务并行运行，多任务会争抢 PD 调度、TiKV 网络与 IO 资源，大概率出现任务失败、备份文件损坏问题。

5.4. 备份存储与校验机制

• 认自动校验** BR 在备份、恢复全流程结束后自动执行数据校验，核对备份文件完整性、分片数据一致性，异常会直接终止任务并告警。

• 备份存储选型推荐 优先使用兼容 S3/GCS/Azure Blob 协议的对象存储存放备份集，支持断点续传、多副本容灾、生命周期归档，远优于本地磁盘存储的可靠性。

6. BR 实操使用方式

6.1. 命令行基础备份 & 恢复示例

-- 全库备份
br backup full \
--pd "${PDIP}:2379" \
--storage "s3://backup-data/2022-01-30/" \
--ratelimit 128 \
--log-file backupfull.log

-- 全库恢复
br restore full \
--pd "${PDIP}:2379" \
--storage "s3://backup-data/2022-01-30/"

restore full读取指定路径备份集，自动匹配 Region 范围、Ingest SST 文件完成全集群数据恢复。

6.2. SQL 交互式用法

支持直接在 TiDB 客户端执行标准 SQL 语句完成备份恢复：

• 备份语句：BACKUP DATABASE * TO 's3://xxx/backup';
• 恢复语句：RESTORE DATABASE * FROM 's3://xxx/backup'; 适合 DBA 日常快速运维操作，无需登录服务器执行二进制命令。

6.3. 任务进度查看

通过 TiDB 内置 SQL 实时查看备份、恢复任务运行状态：

-- 查看备份任务列表与进度
SHOW BACKUPS;
-- 查看恢复任务列表与进度
SHOW RESTORES;

可查看任务 ID、起止时间、完成分片比例、任务状态、报错详情等信息。

六、Lesson11 sync-diff-inspector 数据一致性校验工具

1. 工具定位

TiDB 官方数据核对工具，用于备份恢复后、数据迁移后、主从同步后校验两端数据完全一致，自动生成修复 SQL，解决数据漂移、丢失问题。

2. 核心功能

1. 结构 + 数据双重校验

2. 同时比对上下游库表字段、索引、约束等表结构，以及全量业务数据内容，覆盖迁移完整性校验场景。

3. 自动生成修复 SQL

4. 识别数据差异后输出标准化修复语句，可直接执行补齐缺失数据、删除冗余数据，降低人工核对成本。

5. 灵活映射适配异构名称

6. 支持上下游库名、表名不一致场景配置映射规则校验，适配分库分表合并到 TiDB、业务库改名迁移场景。

7. 分库分表专属校验能力

8. 适配上游 MySQL 分库分表、下游合并单表的主流迁移架构，可批量核对分片数据完整性。

9. TiDB 集群间校验

10. 支持 TiDB 主从集群、同城多活集群之间的数据一致性对账，用于容灾演练后数据核验。

11. 对接 DM 配置一键校验

12. 可直接读取 TiDB DM 任务配置文件，自动提取上下游连接、库表过滤规则，无需重复编写连接配置。

3. 底层校验原理

3.1. 分块校验提速逻辑

1. 以主键 / 唯一索引为分片依据，将整张表拆分为多个 Chunk 数据块；
2. 先对每个 Chunk 计算 Checksum 校验和，快速筛选出校验和不一致的异常 Chunk；
3. 仅针对异常 Chunk 逐行逐条比对明细数据，大幅减少全表逐行比对带来的性能开销。

3.2. 差异修复 SQL 生成规则

• 下游缺失源端数据：自动生成 REPLACE INTO 语句补齐缺失行；
• 下游多余源端不存在数据：自动生成 DELETE 语句清理冗余脏数据； 生成的 SQL 可落地执行，完成上下游数据对齐。

4. 权限要求与硬性使用限制

4.1. 两端账号最小权限要求

源端、目标端数据库账号必须具备权限： SELECT（查询数据）、SHOW DATABASES（查看库列表）、RELOAD（刷新表元数据）。

4.2. 数据类型兼容性限制

4.3. 运行模式约束

MySQL ↔ TiDB、MySQL ↔ MySQL 场景不支持在线实时校验，校验会扫描全表数据，建议业务低峰离线执行，避免影响在线业务性能。