1.背景

TiDB 集群的备份方式有很多种，主流的包括：逻辑备份工具 Mydumper、Dumpling，物理备份工具 BR。本文主要介绍 BR 相关的以下几点内容：

• 我司 TiDB 物理备份经历（测试）的几个阶段

• 为什么选择 MinIO S3 存储 TiDB 备份数据

• 如何使用 BR 工具将 TiDB 集群数据备份到 MinIO S3 及一些使用经验

2.为什么选择 MinIO S3

对于 TiDB 集群的物理备份，我们经历（测试）了多个阶段：将 TiDB 集群数据利用 Binlog 同步到下游 MySQL，在下游 MySQL 上使用 Xtrabackup 进行物理备份 —> BR 备份到持久卷 NFS —> BR 备份到 Ceph S3 —> BR 备份到 MinIO S3。

在不断摸索和测试中最终走向正轨，目前处于稳定状态。下面回顾一下各个阶段遇到的问题和最终的解决方案。

• Xtrabackup 备份

   
  我们最早使用的物理备份是将 TiDB 集群数据利用 Binlog 同步到下游 MySQL，在下游 MySQL 上使用 Xtrabackup 进行备份，因为早期 TiDB 版本不支持 BR 工具(TiDB 4.0 版本开始支持 BR)。

   

这种备份方式是一种可选方案，但是存在一些问题需要关注，比如

(1)成本问题

我们的目的是将 TiDB 集群数据直接备份到目的地(存储服务器或者Hadoop)，但是现在多了一层 MySQL ，无疑增加了服务器成本。

(2)运维问题

如果 TiDB 集群本来是未使用 Binlog 的，但是，由于要在下游 MySQL 进行备份，因此需要开启集群的 Binlog（向下游 MySQL 同步数据需要），这对目前和将来都增加了维护成本。

(3)其它问题

除了以上问题，还会面临一些其它问题，比如一张10亿大表，在上游 TiDB 集群添加一个字段可以秒级完成，但是同步到下游 MySQL 后会添加很长时间，达到 N 个小时(可以升级下游 MySQL 到 8.0 版本解决这个问题，8.0 版本支持快速加列)。

好在 TiDB 4.0 的时候，BR 工具横空出世了，我们开始转向新的物理备份方式。大家知道，目前 BR 工具支持将 TiDB 集群数据备份到兼容 S3 的存储、Google Cloud Storage 、持久卷。

• Google Cloud Storage

   
  这个未使用过，不作评价和介绍

   

• 持久卷

   
  对于 BR 备份，我们最早测试的备份方式是使用持久卷，比如 NFS ，因为官方文档推荐部署配置里有一句话是：推荐使用一块高性能 SSD 网盘，挂载到 BR 节点和所有 TiKV 节点上，网盘推荐万兆网卡，否则带宽有可能成为备份恢复时的性能瓶颈。

   

但是在测试和使用过程中遇到各种问题：

(1)操作繁琐

这种备份方式要求网盘挂载到所有 TiKV 节点，操作相对繁琐，尤其 TiKV 实例多的时候。

(2)失败率高

如果挂载到所有 TiKV 节点可以忍受，那备份过程中遇到的各种失败问题就难以接受了，下面是备份过程中遇到的一种典型问题，错误日志如下：

[error="[BR:KV:ErrKVStorage]tikv storage occur I/O error: File or directory not found error occurs on TiKV Node(store id: 94004; Address: xx.xx.xx.xx:20160)"] [“work around”=“please ensure br and tikv node share a same disk and the user of br and tikv has same uid.”]

错误信息很明显，要求 TiKV 服务器的 UID 和 NFS UID 相同（早期 BR 版本没有这个提示信息）。但是线上已经存在很多套集群运行业务了，UID 和 NFS UID 不同，如果修改集群 UID 会影响集群业务，因此放弃了这种备份方式。

• 兼容 S3 的存储

   
  既然 NFS 方式备份失败率高，操作繁琐，我们再换一种备份方式，将数据备份到兼容 S3 的存储。我们测试了两种 S3，一种是 Ceph S3，一种是 MinIO S3。

   

(1)Ceph S3

由于公司私有云提供统一的 Ceph S3 供业务使用，因此，我们优先申请了 Ceph S3 资源进行测试，但是一直未测试成功，官方内部测试 BR 备份时使用的是 MinIO ，未对 Ceph S3 进行充分测试。

而且社区有用户反馈过相关 Ceph S3 的 Bug(TIDB备份引发公司所有TIDB集群不可用,详情请见 https://asktug.com/t/topic/63756))，最终放弃了这种备份方式。

(2)MinIO S3

MinIO S3 详细部署文档请见下文，经过测试，灰度上线，9月份陆续上线，到目前运行了将近4个月时间，运行良好，暂时未发生过任何故障或问题。

基于 MinIO S3 的测试结果和稳定性，我们最终选择了这种 S3 作为 BR 备份的存储。

3.部署 MinIO S3 及备份恢复

部署 MinIO S3 主要参考了王天宜老师的文章，在此表示感谢，文章地址如下：

https://asktug.com/t/topic/153129

3.1环境介绍

操作系统环境

在本例中，使用 CentOS Stream release 7 版本。

# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)

硬件环境及机器分配

192.168.1.31   minio client(BR节点)
192.168.1.32   minio server
192.168.1.33   minio server

3.2搭建 MinIO 环境

本例中的 minio 集群由 2 台服务器构成(官方推荐集群最小为 4 台服务器)，每台服务器上挂载两个磁盘目录，最小的数据挂载点为 4 个。

1. 创建 minio 目录
192.168.1.32 操作 
mkdir -p /opt/minio/{data,conf,bin,scripts}
mkdir -p /data/minio/{data1,data2}
ln -s /data/minio/data1 /opt/minio/data/data1
ln -s /data/minio/data2 /opt/minio/data/data2

192.168.1.33 操作 
mkdir -p /opt/minio/{data,conf,bin,scripts}
mkdir -p /data/minio/{data3,data4}
ln -s /data/minio/data3 /opt/minio/data/data3
ln -s /data/minio/data4 /opt/minio/data/data4

2. 下载 minio server 与 client 执行文件
192.168.1.32 操作 
cd /opt/minio/bin
wget https://dl.minio.io/server/minio/release/linux-amd64/minio
wget https://dl.minio.io/client/mc/release/linux-amd64/mc
chmod +x /opt/minio/bin/*
scp /opt/minio/bin/* root@192.168.1.33:/opt/minio/bin

3. 创建 minio 启动脚本
192.168.1.32 操作
cd /opt/minio/scripts
vim run_minio.sh
#!/bin/bash
export MINIO_ROOT_USER=myminioid
export MINIO_ROOT_PASSWORD=myminioPassWord
/opt/minio/bin/minio server --config-dir /opt/minio/conf \"
http://192.168.1.32/data/minio/data1 http://192.168.1.32/data/minio/data2 \"
http://192.168.1.33/data/minio/data3 http://192.168.1.33/data/minio/data4

chmod +x run_minio.sh
scp run_minio.sh root@192.168.1.33:/opt/minio/scripts/

4. 创建 minio 服务文件
192.168.1.32 操作
vim /usr/lib/systemd/system/minio.service
[Unit]
Description=Minio service
Documentation=https://docs.minio.io/
[Service]
WorkingDirectory=/opt/minio/
ExecStart=/opt/minio/scripts/run_minio.sh
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target

scp /usr/lib/systemd/system/minio.service root@192.168.1.33:/usr/lib/systemd/system/minio.service

5. 启动 minio
192.168.1.32 操作
systemctl daemon-reload && systemctl start minio

192.168.1.33 操作
systemctl daemon-reload && systemctl start minio

6. 检查 minio 服务
查看启动状态和日志
systemctl status minio
tail -f /var/log/messages

测试 minio 服务
浏览器中输入 http://192.168.1.32:9000 或 http://192.168.1.33:9000

7. minio 客户端命令测试
在下载了 minio 客户端 mc 的机器上可以进行如下测试，本示例中客户端服务器是 192.168.1.31

下载 mc 客户端 
cd /data
wget https://dl.minio.io/client/mc/release/linux-amd64/mc
chmod +x mc
cp mc /usr/bin

在 mc 客户端添加主机信息
mc config host add myminio http://192.168.1.32:9000 myminioid myminioPassWord

查看 mc 客户端已经添加的主机信息
mc config host ls myminio

在 minio 中创建名为 tidbbackup 的 buket
mc mb myminio/tidbbackup

上传文件到 buket 中
echo 'test_upload' > minio_test_upload.log
mc cp minio_test_upload.log myminio/tidbbackup

查看 buket 中的文件
mc ls myminio/tidbbackup

下载 buket 中的文件
mc cp myminio/tidbbackup/minio_test_upload.log /tmp/
cat /tmp/minio_test_upload.log

删除 buket 中的文件
mc rm myminio/tidbbackup/minio_test_upload.log

在 minio 中查看创建的 buket
mc ls myminio
mc ls myminio/tidbbackup

级联删除目录
mc rm myminio/tidbbackup/bak_20210922/ --recursive --force

递归强制删除8天之前的文件，单位支持天，小时，分钟等
mc rm myminio/tidbbackup/fullbackup/ --recursive --force --older-than 8d

更多命令请参考官方网站
https://docs.min.io/minio/baremetal/reference/minio-cli/minio-mc/mc-rm.html#mc-rm-older-than

3.3备份和恢复

备份表 db23.t1，限速 60M

export AWS_ACCESS_KEY_ID=myminioid
export AWS_SECRET_ACCESS_KEY=myminioPassWord
/data/br_513/br backup table --db db23 --table t1 --ratelimit 60 --pd "192.168.1.25:2379" --storage "s3://tidbbackup/bak_20220105" --send-credentials-to-tikv=true --s3.endpoint "http://192.168.1.32:9000" --log-file /tmp/backup.log

恢复表 db23.t1，限速 60M

export AWS_ACCESS_KEY_ID=myminioid
export AWS_SECRET_ACCESS_KEY=myminioPassWord
/data/br_513/br restore table --db db23 --table t1 --ratelimit 60 --pd "192.168.2.25:2379" --storage "s3://tidbbackup/bak_20220105" --send-credentials-to-tikv=true --s3.endpoint "http://192.168.1.32:9000" --log-file restore.log

更详细的 BR 备份恢复命令请参考官网。

4.线上备份情况

从 2021 年 9 月份开始，陆续上线了十几套 TiDB 集群使用 BR 进行备份，A 机房集群数据备份到 A 机房 MinIO S3，B 机房集群数据备份到 B 机房 MinIO S3，截至到目前为止，运行平稳，未发生过异常。

备注：

4.0.9 <= TiDB 版本 <= 4.0.14，BR 4.0.14 版本，凌晨备份，一周一全备。

5.最佳实践

目前线上绝大部分集群都是 4.0 (>= 4.0.9)的版本，因此某些建议可能仅适用于 4.0 版本。

• BR 备份时建议使用 --ratelimit 进行限速，在业务低峰期备份

• 物理备份可以使用 BR 命令，也可以使用 BACKUP 语句，建议使用 BR 工具，更稳定，官方测试更充分

• 上线前建议进行充分测试，如果有条件可以测试一下各种异常情况，比如 S3 卡顿等；先上线非核心集群观察，再陆续上线核心集群

• 对于 4.0 版本，BR 版本建议 >= 4.0.14，因为在 v4.0.3 之后，一直到 v4.0.13 有一个限速无法正确执行的 Bug

6.测试

6.1测试环境

集群信息

MinIO 信息

版本信息

6.2BR备份能力测试

本节主要测试 BR 向 S3 备份能力是否可以满足需求，集群没跑任何业务，40G数据(16张1000万的sysbench表)，测试数据如下

6.3BR备份对集群的影响

16张1000万的表，40G数据，使用 sysbench 256 线程进行 oltp_read_write 压测，压测期间使用 BR 全速备份。备份开始时间：11:19，备份结束时间：11:30:37，备份期间使用了不同并发线程进行了多次备份。

压测结果如下

![图片]

结论：

(1)压测期间，对 BR 备份速度影响不大，猜测应该和 OLTP 压测对磁盘 IO 和 CPU 消耗未达到瓶颈导致的。

(2)压测期间，BR 备份对 TiDB 集群的 QPS 和响应时间影响不大，猜测原因同上。

从以上测试得知，BR 备份期间好像对集群影响不大，但是还是建议大家在线上备份时进行限速，因为：

BR 备份期间会大量使用 TiKV 服务器的 CPU 资源：在一个空集群上使用 BR 全速备份期间，TiKV 实例的 CPU 使用率大概在 500% 以下，BR 备份完成后在 checksum 阶段，TiKV 实例的 CPU 使用率会突增到 1300% 左右。

如果限速 50M，TiKV 实例的 CPU 使用率大概在 150% 以下，BR 备份完成后在 checksum 阶段，TiKV 实例的 CPU 使用率会突增到 900% 左右。

以上测试使用的默认并发线程4，结果因环境不同而不同。

7.展望

• 平台化支持

   
  目前 BR 备份采取了脚本 + Crontab 定时任务的形式，后续对接平台，方便运维和提升效率。

   

• 增量备份测试

   
  全量备份对于备份速度和存储空间都是一个很大的挑战，鉴于此，后续我们将尝试增量备份。