TiDB BR 备份至 MinIO S3 实战

作者：TiDB 社区干货传送门

2022 年 7 月 11 日
本文字数：4820 字
阅读完需：约 16 分钟

原文来源：https://tidb.net/blog/3a31d41d

【是否原创】是

【首发渠道】TiDB 社区

【正文】

作者：
靳献旗汽车之家 DBA，TUG 2021 MVA

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-releaseCentOS Linux release 7.4.1708 (Core)

复制代码

硬件环境及机器分配

192.168.1.31   minio client(BR节点)192.168.1.32   minio server192.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/data1ln -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/data3ln -s /data/minio/data4 /opt/minio/data/data4
2. 下载 minio server 与 client 执行文件192.168.1.32 操作 cd /opt/minio/binwget https://dl.minio.io/server/minio/release/linux-amd64/miniowget https://dl.minio.io/client/mc/release/linux-amd64/mcchmod +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/scriptsvim run_minio.sh#!/bin/bashexport MINIO_ROOT_USER=myminioidexport 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.shscp 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 serviceDocumentation=https://docs.minio.io/[Service]WorkingDirectory=/opt/minio/ExecStart=/opt/minio/scripts/run_minio.shRestart=on-failureRestartSec=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. 启动 minio192.168.1.32 操作systemctl daemon-reload && systemctl start minio
192.168.1.33 操作systemctl daemon-reload && systemctl start minio
6. 检查 minio 服务查看启动状态和日志systemctl status miniotail -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 /datawget https://dl.minio.io/client/mc/release/linux-amd64/mcchmod +x mccp 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 的 buketmc mb myminio/tidbbackup
上传文件到 buket 中echo 'test_upload' > minio_test_upload.logmc 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 中查看创建的 buketmc ls myminiomc 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=myminioidexport 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=myminioidexport 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 定时任务的形式，后续对接平台，方便运维和提升效率。
增量备份测试
全量备份对于备份速度和存储空间都是一个很大的挑战，鉴于此，后续我们将尝试增量备份。

发布于: 刚刚阅读数: 2

原文链接:【http://xie.infoq.cn/article/15b2b8e2ad49f913988e752c1】。文章转载请联系作者。

TiDB 社区干货传送门

关注

TiDB 社区官网:https://tidb.net/ 2021.12.15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

发布

暂无评论

创作场景

TiDB BR 备份至 MinIO S3 实战

1. 背景

2. 为什么选择 MinIO S3

3. 部署 MinIO S3 及备份恢复

3.1 环境介绍

3.2 搭建 MinIO 环境

3.3 备份和恢复

4. 线上备份情况

5. 最佳实践

6. 测试

6.1 测试环境

6.2BR 备份能力测试

6.3BR 备份对集群的影响

7. 展望

TiDB 社区干货传送门

评论