【TiDB 社区版主话题探讨】-深入讨论 BR 备份

什么是 TiDB 社区版主?

TiDB 社区版主：由TiDB社区中的用户、开发者、Contributor 以及合作伙伴共同组成，并拥有参与对 AskTUG 论坛管理及运营的权限。

版主及候选人荣誉榜 TiDB 社区活动

版主荣誉榜 7月份新晋版主 8月份新晋版主 9月份新晋版主 版主候选人荣誉榜 什么是版主？ AskTUG 论坛版主：由TiDB社区中的用户、开发者、Contributor 以及合作伙伴共同组成，并拥有参与对 AskTUG 论坛管理及运营的权限。 如何加入版主？ [image] AskTUG[image] 试运行开始公开招募啦！ 作为一…

关于话题讨论的内容来源?

版主交流群，是由一群热爱 TiDB 的版主、版主候选人及社区活跃小伙伴们组成的一个微信群，我们经常会在群里面交流 TiDB 技术问题，以便于更好地掌握 TiDB 的运维能力，更快速地帮助自己和他人处理 TiDB 问题，获得技术上的提升和成长。

本次话题为 9月29日随意讨论的一个关于 BR 备份的问题?由于讨论的内容兴许可以帮助到遇到：BR 备份问题的小伙伴更好地获得问题解决思路，所以共享出来。

@db_user：

大佬们的 br 备份选择放到哪里，有选择放到s3上的么？

@Kongdom：

我这没有

@db_user：

孔大佬放在哪，共享存储么

@xfworld：

本地放NFS

@db_user：

费用有点高
我正在测试s3的效率。不知道网络会有多大影响

@xfworld：

S3 还好，有奇偶校验，可以分片传递
做成增量的就好弄了
本地放个版本，其他的做成增量丢S3

@db_user：

嗯嗯，功能测了下正常满足
增量恢复起来麻烦

@Kongdom：

我们是两套集群，然后互为备份机

@db_user：

两套集群酷了
我的架构是tidb后面接mysql

@Kongdom：

对，要增量，全量太慢了，有一个客户，全量备份一次需要10个小时，主要是因为机械硬盘

@xfworld：

必须增量，磁盘也很贵的

@db_user：

只要ticdc没有问题，我的备份就很好
我看下时间不行就得增量了

@Kongdom：

我一直劝客户别单机裸跑，一定要上集群，上了集群完全不需要备份。

@db_user：

没挂NFS，全量本地的话，恢复得移文件
不备份多慌

@xfworld：

NFS 必备
不然多麻烦
BR 恢复，每个tikv 还到处挪文件？
累死了还

@Kongdom：

集群不需要备份，坏掉就下线，备用节点顶上去

@xfworld：

果然是金主

@Kongdom：

富则火力覆盖，穷则精准打击

@db_user：

有钱
666

@Kongdom：

单节点部署的，直接用的mysqldump备份，哈哈哈
br都省了

@MyronWang：

备份作业都不用重写，直接复用

@db_user：

哈哈哈
我是集群后面接了mysql，一个为了闪回，一个为了备份
我测试了下。br-s3的200G需要半个小时

@xfworld：

是不是觉得很慢

@db_user：

嗯，但是还可以接受，我再评估下增量还原的复杂程度吧，看选用那种

@Kongdom：

物理备份的瓶颈应该只是单纯的带宽和IO吧

@Songxuecheng：

BR适合多大的集群

@Kongdom：

我觉得上10G就应该考虑BR了
之前几个G的mysqldump备份，还原了好久好久，中间还会丢数据

@db_user：

官方给的也应该是10G

@Songxuecheng：

我现在1T 还用dumpling呢。。

@db_user：

额
那不慢么

@Kongdom：

我就想问问，还原过么？

@db_user：

dumpling单库备么
我lighting还原过200G的单库,大概是3个小时左右

@dba_gc：

我10T还在用dumpling 。BR 会导致CPU和IO异常飙升就停用了。

@Songxuecheng：

恢复肯定慢的

@db_user：

引用：dba_gc——我10T还在用dumpling 。BR 会导致CPU和IO异常飙升就停用了。

这也是我担心的问题，所以一直没用。现在要上正式了，没有个完善的物理备份也担心，所以搞一个看看

@Kongdom：

引用：dba_gc——我10T还在用dumpling 。BR 会导致CPU和IO异常飙升就停用了。

不搞全备就可以了

@dba_gc：

引用：Kongdom——不搞全备就可以了

我现在用dumpling，大表就一周一备，其他的就每天备份。

@hey-hoho：

lightning你们用哪种backend比较多
我这2T的数据也用dumpling备份过，5个小时

@dba_gc：

目前 4.0.15 还没有解决这个问题，不知道后续版本还会优化不。

@db_user：

dumpling还原稍微慢点，br还没测试过

@dba_gc：

三、BR 数据恢复
3.1 BR使用注意事项

1. 恢复单个表时，恢复完成后需要执行 ANALYZE TABLE (单个库则会自动ANALYZE)
2. 恢复的数据 TiCDC/Drainer 不会同步到下游
3. 恢复时必须为空表或者表不存在才能恢复
4. 备份数据可以恢复到另外的集群

3.2 BR恢复时间评估
BR恢复速度：150MB/s (近10GB/1分钟)
恢复 200G 的数据表需要： 23分钟
恢复 5.5T 整个集群数据需要：10小时
极端情况下恢复整个集群为最新数据需要：11-20小时 (每天按500G增量数据算恢复需要1小时。6天增量共6小时恢复时间)

@db_user：

cpu确实是高

@dba_gc：

拿去白嫖。。

@db_user：

酷

@Songxuecheng：

br是备份到本地吗
如果没有s3之类的

@db_user：

我到的s3，本地挂存储吧，要不太麻烦了

@Songxuecheng：

要在本地挂在新的盘？

@hey-hoho：

S3是自己搭的么，还是走公有云

@db_user：

我们之前是把本地一个目录挂到了共享存储上，当时用的是戴尔的

@dba_gc：

BR备份，执行命令的节点和tikv节点，必须能够访问相同的共享目录。

@Songxuecheng：

就是挂共享存储？

@dba_gc：

是的，必须要共享存储。 要不然备份不了

@db_user：

我的S3是走的公有云
要不然恢复的时候需要手动挪数据

@Songxuecheng：

ok

@db_user：

恢复时每个节点都需要所有节点数据

@dba_gc：

是的，不是备份不了，是恢复不了。

@Songxuecheng：

NFS便宜吗。。

@db_user：

并不

@Songxuecheng：

dumpling全备之后 是否可以使用tidb lighting 只恢复单独的库表？

@hey-hoho：

可以的
配置filter

@Songxuecheng：

就库表过滤就可以是吧

@kongdom：

我理解的br就是 物理复制。还原就是 物理覆盖。

@hey-hoho：

. 改成指定的库表就行

@Songxuecheng：

就修改tidb lighting的配置文件

@hey-hoho：

是的
而且还有个隐藏功能，lightning可以支持库表名做route，但是新版本文档没放出来，3.0的文档里面写了

@Songxuecheng：

lightning 导入是影响集群使用的？ 只有tidb模式不影响？

@lileiaab：

文档是这么说的

@Songxuecheng：

我理解是只有tidb-backed 模式，集群还可以对外提供服务
但是这种模式最慢

@lileiaab ：

走tidb是慢点
其他都是直接走tikv的

@Songxuecheng：

ok

如果你也有兴趣加入版主交流群，可以加微信：billmay 了解一下。