印刻数据库

外观

TiDB 恢复操作指南 ​

基于 BR 的恢复操作 ​

1. 全量恢复 ​

前提条件 ​

  • 已完成全量备份
  • 备份数据可用
  • 目标 TiDB 集群已部署且运行正常
  • BR 工具已安装

恢复步骤 ​

bash
# 1. 确保目标集群正常运行
tiup cluster display <cluster-name>

# 2. 执行全量恢复
tiup br restore full \n  --pd <pd-host>:<pd-port> \n  --storage <storage-url> \n  [--ratelimit <speed-limit>] \n  [--concurrency <thread-count>]

# 示例：从本地存储恢复
tiup br restore full \n  --pd 127.0.0.1:2379 \n  --storage local:///path/to/backup

# 示例：从 S3 存储恢复
tiup br restore full \n  --pd 127.0.0.1:2379 \n  --storage s3://bucket/backup \n  --s3.endpoint https://s3.amazonaws.com \n  --s3.access-key <access-key> \n  --s3.secret-access-key <secret-key>

2. 增量恢复 ​

前提条件 ​

  • 已完成全量备份和至少一个增量备份
  • 备份数据可用且顺序正确
  • 目标 TiDB 集群已部署且运行正常
  • BR 工具已安装

恢复步骤 ​

bash
# 1. 先执行全量恢复
tiup br restore full \n  --pd <pd-host>:<pd-port> \n  --storage <storage-url>\n  --lastbackupts <last-full-backup-ts>

# 2. 执行增量恢复
tiup br restore inc \n  --pd <pd-host>:<pd-port> \n  --storage <storage-url> \n  --lastbackupts <last-backup-ts>

# 示例：全量恢复 + 增量恢复
tiup br restore full \n  --pd 127.0.0.1:2379 \n  --storage local:///path/to/backup \n  --lastbackupts 431435386631809025
tiup br restore inc \n  --pd 127.0.0.1:2379 \n  --storage local:///path/to/backup \n  --lastbackupts 431435386631809025

3. 时间点恢复 ​

前提条件 ​

  • 已完成全量备份和相关的增量备份
  • 知道要恢复到的具体时间点（或 TSO）
  • 目标 TiDB 集群已部署且运行正常
  • BR 工具已安装

恢复步骤 ​

bash
# 执行时间点恢复
tiup br restore point \n  --pd <pd-host>:<pd-port> \n  --storage <storage-url> \n  --restored-ts <timestamp> \n  [--ratelimit <speed-limit>] \n  [--concurrency <thread-count>]

# 示例：恢复到指定时间点
tiup br restore point \n  --pd 127.0.0.1:2379 \n  --storage local:///path/to/backup \n  --restored-ts '2024-01-01 12:00:00'

# 示例：恢复到指定 TSO
tiup br restore point \n  --pd 127.0.0.1:2379 \n  --storage local:///path/to/backup \n  --restored-ts 431435386631809025

4. 单库恢复 ​

前提条件 ​

  • 已完成全量备份
  • 知道要恢复的数据库名称
  • 目标 TiDB 集群已部署且运行正常
  • BR 工具已安装

恢复步骤 ​

bash
# 执行单库恢复
tiup br restore db \n  --pd <pd-host>:<pd-port> \n  --storage <storage-url> \n  --db <database-name> \n  [--ratelimit <speed-limit>] \n  [--concurrency <thread-count>]

# 示例：恢复单个数据库
tiup br restore db \n  --pd 127.0.0.1:2379 \n  --storage local:///path/to/backup \n  --db test_db

5. 单表恢复 ​

前提条件 ​

  • 已完成全量备份
  • 知道要恢复的表名称和所属数据库
  • 目标 TiDB 集群已部署且运行正常
  • BR 工具已安装

恢复步骤 ​

bash
# 执行单表恢复
tiup br restore table \n  --pd <pd-host>:<pd-port> \n  --storage <storage-url> \n  --db <database-name> \n  --table <table-name> \n  [--ratelimit <speed-limit>] \n  [--concurrency <thread-count>]

# 示例：恢复单个表
tiup br restore table \n  --pd 127.0.0.1:2379 \n  --storage local:///path/to/backup \n  --db test_db \n  --table test_table

基于 TiDB Lightning 的恢复操作 ​

1. 逻辑备份恢复 ​

前提条件 ​

  • 已使用 Dumpling 或其他工具生成逻辑备份
  • 备份文件可用
  • 目标 TiDB 集群已部署且运行正常
  • TiDB Lightning 已安装

恢复步骤 ​

  1. 准备配置文件
toml
# tidb-lightning.toml
[lightning]
# 日志级别
level = "info"
# 并发数，建议设置为 CPU 核心数
table-concurrency = 16
index-concurrency = 16

[tidb]
# TiDB 连接信息
host = "<tidb-host>"
port = 4000
user = "root"
password = ""
db-name = "test_db"

[mydumper]
# 备份文件目录
data-source-dir = "/path/to/backup"

[tikv-importer]
# 使用 Local-backend 模式
backend = "local"
# 本地临时文件目录
sorted-kv-dir = "/path/to/sorted-kv-dir"
  1. 执行恢复
bash
# 执行恢复操作
tiup tidb-lightning -config tidb-lightning.toml

2. 从 MySQL 恢复数据 ​

前提条件 ​

  • MySQL 数据库可用
  • 已安装 TiDB Lightning
  • 目标 TiDB 集群已部署且运行正常

恢复步骤 ​

  1. 准备配置文件
toml
# tidb-lightning.toml
[lightning]
level = "info"
table-concurrency = 16
index-concurrency = 16

[tidb]
host = "<tidb-host>"
port = 4000
user = "root"
password = ""
db-name = "test_db"

[mydumper]
# MySQL 连接信息
host = "<mysql-host>"
port = 3306
user = "root"
password = ""
# 要备份的数据库和表
databases = ["test_db"]
tables = ["test_table"]

[tikv-importer]
backend = "local"
sorted-kv-dir = "/path/to/sorted-kv-dir"
  1. 执行恢复
bash
tiup tidb-lightning -config tidb-lightning.toml

恢复操作最佳实践 ​

1. 恢复前准备 ​

  • 确认备份数据完整性：在恢复前，验证备份数据的完整性
  • 准备目标环境：确保目标 TiDB 集群已部署且运行正常
  • 规划恢复时间：选择业务低峰期进行恢复，减少对业务的影响
  • 备份目标数据：如果目标集群已有数据，建议先备份目标数据
  • 准备回滚方案：制定恢复失败后的回滚方案

2. 恢复过程中注意事项 ​

  • 监控恢复进度：实时监控恢复进度，及时处理可能出现的问题
  • 控制恢复速度：根据系统资源情况，调整恢复速度，避免影响其他业务
  • 记录恢复过程：详细记录恢复过程中的每一步操作和结果
  • 保持沟通：与相关部门保持沟通，及时通报恢复进度

3. 恢复后验证 ​

  • 验证数据完整性：检查恢复后的数据完整性和一致性
  • 验证业务功能：测试业务功能是否正常
  • 验证性能：检查系统性能是否符合要求
  • 更新文档：更新相关文档，记录恢复操作的详细信息
  • 进行备份：恢复完成后，立即进行一次全量备份

灾难恢复 ​

1. 灾难恢复计划 ​

制定详细的灾难恢复计划是确保快速恢复的关键：

  • 灾难类型定义：明确各种灾难类型和级别
  • 恢复策略：针对不同灾难类型制定相应的恢复策略
  • 恢复流程：详细的恢复步骤和责任人
  • 恢复时间目标：明确不同级别的灾难恢复时间目标
  • 恢复点目标：明确不同级别的数据丢失容忍度
  • 恢复资源：确保恢复所需的资源可用

2. 灾难恢复演练 ​

定期进行灾难恢复演练，验证灾难恢复计划的有效性：

  • 演练频率：建议每季度至少进行一次灾难恢复演练
  • 演练范围：覆盖不同类型的灾难场景
  • 演练参与者：包括所有相关部门和人员
  • 演练评估：评估演练结果，找出问题并改进
  • 更新计划：根据演练结果更新灾难恢复计划

3. 跨区域灾难恢复 ​

对于高可用性要求高的场景，建议采用跨区域灾难恢复方案：

  • 部署跨区域集群：在不同地理区域部署 TiDB 集群
  • 使用 TiCDC 实时复制：使用 TiCDC 在集群间实时复制数据
  • 定期备份到异地：将备份数据存储到异地
  • 制定跨区域恢复流程：明确跨区域恢复的流程和步骤
  • 定期跨区域恢复演练：定期进行跨区域恢复演练

恢复操作常见问题 ​

1. 恢复速度慢怎么办？ ​

A: 可以采取以下措施提高恢复速度：

  • 增加恢复工具的并发数
  • 使用更高性能的存储设备
  • 增加目标集群的资源配置
  • 优化恢复工具的配置参数
  • 选择合适的恢复工具和方法

2. 恢复过程中出现错误怎么办？ ​

A: 恢复过程中出现错误时，建议采取以下措施：

  • 查看错误日志，定位错误原因
  • 根据错误信息采取相应的解决措施
  • 如果无法解决，可以尝试重新恢复
  • 必要时，联系 TiDB 官方支持

3. 恢复后数据不一致怎么办？ ​

A: 如果恢复后发现数据不一致，建议采取以下措施：

  • 检查备份数据的完整性
  • 检查恢复过程是否正确
  • 验证恢复前后的数据量和内容
  • 必要时，重新进行恢复
  • 分析数据不一致的原因，避免再次发生

4. 如何选择合适的恢复工具？ ​

A: 选择恢复工具时，应考虑以下因素：

  • 恢复的数据源和格式
  • 数据量大小
  • 恢复速度要求
  • 恢复的灵活性要求
  • 目标集群的配置
  • 恢复的复杂度

恢复操作案例 ​

案例 1：全量恢复 ​

场景：TiDB 集群因硬件故障导致数据丢失，需要从全量备份中恢复。

恢复步骤：

  1. 停止目标 TiDB 集群的所有写入操作
  2. 使用 BR 工具执行全量恢复
  3. 恢复完成后，验证数据完整性
  4. 启动业务服务，验证业务功能

命令示例：

bash
tiup br restore full \n  --pd 127.0.0.1:2379 \n  --storage s3://bucket/backup-20240101 \n  --s3.endpoint https://s3.amazonaws.com

案例 2：时间点恢复 ​

场景：误操作删除了重要数据，需要恢复到误操作前的时间点。

恢复步骤：

  1. 确定误操作发生的时间点
  2. 使用 BR 工具执行时间点恢复
  3. 恢复完成后，验证数据是否已恢复
  4. 从恢复的数据中提取误删除的数据
  5. 将提取的数据导入到生产集群

命令示例：

bash
tiup br restore point \n  --pd 127.0.0.1:2379 \n  --storage local:///path/to/backup \n  --restored-ts '2024-01-01 11:59:00'

案例 3：单表恢复 ​

场景：单个表的数据损坏，需要从备份中恢复该表。

恢复步骤：

  1. 确定需要恢复的表
  2. 使用 BR 工具执行单表恢复
  3. 恢复完成后，验证表数据完整性
  4. 验证业务功能是否正常

命令示例：

bash
tiup br restore table \n  --pd 127.0.0.1:2379 \n  --storage local:///path/to/backup \n  --db test_db \n  --table important_table

常见问题（FAQ） ​

Q1: 如何选择全量恢复和增量恢复？ ​

A1: 选择全量恢复还是增量恢复，应考虑以下因素：

  • 数据丢失的范围：如果大部分数据丢失，建议使用全量恢复
  • 恢复速度要求：全量恢复速度快，增量恢复需要先进行全量恢复
  • 恢复点要求：如果需要恢复到特定时间点，可能需要结合使用全量恢复和增量恢复
  • 备份数据的完整性：确保所需的备份数据都可用

Q2: 如何提高恢复速度？ ​

A2: 提高恢复速度的措施包括：

  • 增加恢复工具的并发数
  • 使用更高性能的存储设备
  • 优化恢复工具的配置参数
  • 增加目标集群的资源配置
  • 选择合适的恢复工具和方法

Q3: 恢复过程中可以中断吗？ ​

A3: 大部分恢复工具不支持断点续传，中断后需要重新开始恢复。因此，在恢复过程中应尽量避免中断，确保恢复过程顺利完成。

Q4: 如何验证恢复后的数据完整性？ ​

A4: 验证恢复后的数据完整性的方法包括：

  • 比较恢复前后的数据量
  • 抽样检查数据内容
  • 运行业务功能测试
  • 计算数据校验和
  • 检查数据库日志，确认没有错误

Q5: 如何防止恢复操作影响生产环境？ ​

A5: 防止恢复操作影响生产环境的措施包括：

  • 在测试环境进行恢复测试
  • 选择业务低峰期进行恢复
  • 控制恢复速度，避免资源竞争
  • 恢复前备份生产数据
  • 制定回滚方案，以便在出现问题时快速回滚