数据冷备到其他存储的方案

🪐 TiDB 技术问题 备份&数据迁移
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】V6.5.0
【复现路径】TiDB服务正常备份
【遇到的问题：问题现象及影响】TiDB服务备份数据到磁盘上，在TiDB服务极端Case下保证数据的安全性
【资源配置】

TiDB服务可以正常工作，但是受限于线上机器硬件故障、内存条极端Bit翻转、网卡极端Bit翻转、网络环境、代码未知Bug，导致Tidb Meta数据损坏，从而导致Tidb服务无法正常重启等等。在类似极端Case 情况下，清空集群数据，将冷备的数据从新灌入到新的TiDB集群服务中。
需要考虑如下两个场景

  • 存量数据
  • 增量数据
    数据冷备时，不影响旧的TiDB服务；增量数据备份应该是是一个实时任务，且数据条目不应该有重复的条目

有没有大佬可以给一个存在可行性的方案

2

https://docs.pingcap.com/zh/tidb/v6.5/backup-and-restore-use-cases

用br全量+增量备份。

3 个赞
3

br + s3存储了解一下

4

不用考虑 冷备存储介质，我是想问有什么工具可以使用，楼上给了br 工具，我去看看。

5

机器硬件故障由多副本解决，bit翻转由内存的ECC校验负责，担心数据与元数据损坏，BR全量+增量就可以，不需要一定要冷备。如果一定要冷备，就用CDC同步一份备用库，备份的时候停备库做冷备。

6

我们集群V6.5 采用的是挂载NAS，然后BR备份加增量备份，NAS的数据统一由备份设备抓走，

7

https://docs.pingcap.com/zh/tidb/v6.5/migration-tools
数据迁移和校验的工具介绍

8
  • 逻辑全备可以考虑dumpling，但是对集群性能有一定影响，效率也很低，还不支持增量备份。
  • 物理全备和增备都可以用BR搞定。尤其是6.5之后的PITR备份功能，和MySQL的binlog一样，可以直接增量输出集群的变更到存储中。具体文档见： https://docs.pingcap.com/zh/tidb/v6.5/br-pitr-guide
9

一般都是考虑用br备份。

10

br 备份即可

11

我们测试也是用br，可以

12

br+日志可以用，不过会有1到2分钟延迟，也就是数据库极端情况数据没了，恢复也是少数据的

13

生产环境建议使用cdc同步数据到备库，在备库做br和增量备份到存储，主库出现问题紧急情况下可以直接切换到备库

14

BR加上实时日志就可以

15

实时数据：BR+CDC
历史存量数据：全量S3

16

每周一次br全量+7*24 br log 增量， 历史数据保存一周以上，可以恢复到一周内任何时间点，注意br log 最近2-3分钟的增量会丢失。

另外，如果想减少丢失或者快速恢复，硬件资源允许的话可以ticdc准实时搭建备集群（ticdc要稳定可用，建议v7.1.3及以上，之前的各种bug）

17

可以采用br backup+restore
或者 dumpling+lightning

18

新写了个备份方案，不知道对你有没有用。

19

可使用br备份或者dumpling备份， 实测br备份速度较快，适合大数据量（但外部存储需支持S3协议）

20

试试br + s3