[转帖]TiDB BR 备份至 MinIO S3 实战
https://tidb.net/blog/3a31d41d#3.%E9%83%A8%E7%BD%B2%20MinIO%20S3%20%E5%8F%8A%E5%A4%87%E4%BB%BD%E6%81%A2%E5%A4%8D
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测试环境
集群信息
IP | 版本 | 组件 | 配置 |
---|---|---|---|
192.168.1.1 | 5.1.3 | TiDB | 内存:256G 硬盘:SSD RAID10 CPU:128核 网卡:万兆 |
192.168.1.2 | 5.1.3 | TiDB | |
192.168.1.3 | 5.1.3 | TiDB | |
192.168.1.4 | 5.1.3 | 2 个 TiKV | |
192.168.1.5 | 5.1.3 | 2 个 TiKV | |
192.168.1.6 | 5.1.3 | 2 个 TiKV | |
192.168.1.7 | 5.1.3 | BR |
MinIO 信息
IP | 版本 | 组件 | 配置 |
---|---|---|---|
192.168.1.8 | 5.1.3 | minio server | 内存:256G 硬盘:SSD RAID10 CPU:128核 网卡:万兆 |
192.168.1.9 | 5.1.3 | minio server |
版本信息
TiDB 版本 | BR 版本 | minio |
---|---|---|
5.1.3 | 5.1.3 | RELEASE.2021-09-18T18-09-59Z |
6.2BR备份能力测试
本节主要测试 BR 向 S3 备份能力是否可以满足需求,集群没跑任何业务,40G数据(16张1000万的sysbench表),测试数据如下
BR并发线程 | BR限速 | 备份总耗时(秒) | checksum耗时(秒) | 平均速度 |
---|---|---|---|---|
4 | 不限速 | 126.8 | 6.7 | 320.5MB/s |
8 | 不限速 | 72.2 | 6.7 | 562.8MB/s |
16 | 不限速 | 44.8 | 6.7 | 906.5MB/s |
32 | 不限速 | 31.7 | 6.7 | 1.282GB/s |
48 | 不限速 | 32.4 | 6.7 | 1.254GB/s |
64 | 不限速 | 32.5 | 6.7 | 1.249GB/s |
6.3BR备份对集群的影响
16张1000万的表,40G数据,使用 sysbench 256 线程进行 oltp_read_write 压测,压测期间使用 BR 全速备份。备份开始时间:11:19,备份结束时间:11:30:37,备份期间使用了不同并发线程进行了多次备份。
压测结果如下
BR并发线程 | BR限速 | 备份总耗时(秒) | 平均速度 |
---|---|---|---|
4 | 不限速 | 134 | 301.6MB/s |
8 | 不限速 | 73 | 550.6MB/s |
16 | 不限速 | 46.9 | 866.3MB/s |
32 | 不限速 | 32.5 | 1.251GB/s |
64 | 不限速 | 32 | 1.267GB/s |
![图片]
结论:
(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 定时任务的形式,后续对接平台,方便运维和提升效率。
增量备份测试
全量备份对于备份速度和存储空间都是一个很大的挑战,鉴于此,后续我们将尝试增量备份。
[转帖]TiDB BR 备份至 MinIO S3 实战的更多相关文章
- streamsets 集成 minio s3测试
具体streamsets crate 集成可以参考 streamsets crate 以下文档只关注minio 集成的配置 minio 服务 搭建 具体搭建参考: https://www.cnblog ...
- k8s helm 私服chartmuseum minio s3 存储配置
1. 安装minio 使用docker 安装 参考项目 https://github.com/rongfengliang/mino-thumbor-openresty 备注: 因为是一个集成项目可能会 ...
- cronicle minio s3 存储配置集成
cronicle 后端存储是可配置的 ,通过使用不同的存储配置,我们可以解决多实例部署以及数据共享的问题 cronicle 的后端存储模型,设计的特别方便,包含了基于文件的,基于s3 的,同时我们也可 ...
- 使用s3-sftp-proxy 暴露minio s3 数据为sftp 访问
尽管s3 很不错,但是ftp 也有自己存在的价值,以下是一个简单的通过s3-sftp-proxy 暴露minio s3 数据为ftp 的访问方式 环境准备 docker-compose 文件 vers ...
- 使用s3fs-fuse 挂载minio s3 对象存储
minio 是一个aws s3 兼容的对象存储系统,我们可以通过s3fs 进行数据桶的挂载,这样可以做好多方便的事情 环境准备 使用docker-compose 运行 minio docker-com ...
- nexus && minio s3 存储私有镜像
对于新版本的nexus 已经支持s3 存储了(3.12),但是企业内部可能还是需要使用私有部署的 还好我们有minio,具体的介绍就不说了 minio 项目运行 参考项目: https://githu ...
- Mysql DBA 运维 MySQL数据库索引优化及数据丢失案例 MySQL备份-增量备份及数据恢复基础实战 MySQL数据库生产场景核心优化
需要的联系我,QQ:1844912514
- 使用k8s && minio 进行 postgres 数据库自动备份
通过k8s 的定时任务job,我们可以方便的进行定时任务应用的开发,通过minio s3 兼容的cloud native 存储 我们可以方便的通过http 请求进行数据文件的备份,以下简单演示下如 ...
- kubernetes备份恢复之velero
Velero备份.恢复.迁移Kubernetes集群 Velero简介 Velero 地址:https://github.com/vmware-tanzu/velero Velero属于VMWare开 ...
- FC8下备份linux系统
linux系统可以使用tar来备份.<br><br> 我在FC8上装好了totem, mplayer, audacious, 并搞定了wifi后,我觉得该备份一下FC8系统.& ...
随机推荐
- vue3 + element-plus 的 upload + axios + django 文件上传并保存
之前在网上搜了好多教程,一直没有找到合适自己的,要么只有前端部分没有后端,要么就是写的不是很明白.所以还得靠自己摸索出来后,来此记录一下整个过程. 其实就是不要用默认的 action,要手动实现上传方 ...
- [集训队作业2013] 城市规划(NTT)
一周一博客二专题计划 题面 n 个点的简单 (无重边无自环) 有标号无向连通图数目. 看着就很典 思路 设\(f(n)\)为n点连通图数目.设\(g(n)\)为n点不一定联通图数目,显然直接枚举每条边 ...
- JVM学习-Class文件结构
文章原文:https://gaoyubo.cn/blogs/844dc0e7.html 一.Class类文件的结构 任何一个Class文件都对应着唯一的一个类或接口的定义信息. 但是反过来说,类或接口 ...
- 温故而知新——MYSQL基本操作
相关连接: mysql和sqlserver的区别:https://www.cnblogs.com/vic-tory/p/12760197.html sqlserver基本操作:https://www. ...
- 玩转Sermant开发,开发者能力机制解析
本文分享自华为云社区<开发者能力机制解析,玩转Sermant开发>,作者:华为云开源 . 前言: 在<Sermant框架下的服务治理插件快速开发及使用指南>中带大家一起体验了S ...
- 技术驱动,数据赋能,华为云GaussDB给世界一个更优选择
摘要:5月16日,"数智深耕 让美好发生 2023华为云城市峰会广州站"成功举行. 5月16日,"数智深耕 让美好发生 2023华为云城市峰会广州站"成功举行. ...
- Mysql开发实践:error while loading shared libraries: libaio解决方案
摘要:Mysql出现问题:error while loading shared libraries: libaio解决方案. 本文分享自华为云社区<Mysql出现问题:error while l ...
- 应对全场景AI框架部署挑战,MindSpore“四招”让你躺平
摘要:所谓全场景AI,是指可以将深度学习技术快速应用在云边端不同场景下的硬件设备上,包括云服务器.移动终端以及IoT设备等等,高效运行并能有效协同. 本文分享自华为云社区<AI框架的挑战与Min ...
- 10倍!BoostKit鲲鹏全局缓存3大创新技术助力Ceph性能提升
摘要:本文从四个方面阐述了BoostKit鲲鹏全局缓存技术,该技术针对Ceph开源存储方案存在的痛点,采用三大创新技术,有效的提高了Ceph的性能,最高可以将Ceph性能提升10倍. 本文分享自华为云 ...
- 【鲲鹏 DevKit黑科技揭秘】│如何实现全链路系统问题90%精准诊断?
摘要:DevKit系统诊断工具是鲲鹏性能分析工具的子工具之一,能够针对内存.网络.存储等常见故障和异常,提供精准定位和诊断能力,帮助用户识别出源代码中的问题点,提升程序的可靠性,故障定位准确率高达90 ...