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

什么是 TiDB 社区版主?

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

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

版主交流群,是由一群热爱 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个小时左右

@苏州刘三枪

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

@Songxuecheng

恢复肯定慢的

@db_user

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

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

@Kongdom

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

不搞全备就可以了

@苏州刘三枪

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

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

@hey-hoho

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

@苏州刘三枪

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

@db_user

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

@苏州刘三枪

三、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确实是高

@苏州刘三枪

拿去白嫖。。

@db_user

@Songxuecheng

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

@db_user

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

@Songxuecheng

要在本地挂在新的盘?

@hey-hoho

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

@db_user

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

@苏州刘三枪

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

@Songxuecheng

就是挂共享存储?

@苏州刘三枪

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

@db_user

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

@Songxuecheng

ok

@db_user

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

@苏州刘三枪

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

@Songxuecheng

NFS便宜吗。。

@db_user

并不

@Songxuecheng

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

@hey-hoho

可以的
配置filter

@Songxuecheng

就库表过滤就可以是吧

@kongdom

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

@hey-hoho

. 改成指定的库表就行

@Songxuecheng

328cea3719c77350204a2c485549838

就修改tidb lighting的配置文件

@hey-hoho

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

@Songxuecheng

2941dd1133bbe393f5b5ebe9df2c749

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

@lileiaab

文档是这么说的

@Songxuecheng

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

@lileiaab

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

@Songxuecheng

ok

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

6 个赞

沙发~ 哈哈,一个小讨论都置顶了 :ghost:

3 个赞

前排围观~

2 个赞

围观大佬对话

2 个赞

围观ing~