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

作者： Billmay 原文来源：https://tidb.net/blog/7696c29a

什么是 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 了解一下。