BR的备份是保证事务性的吗?

BR的备份是保证事务性的吗?分成几个小问题:

  1. memtable 里面的数据也会被备份走吗?强制flush到SST了?

  2. 刚刚写到wal文件,还没存到memtable的数据怎么被处理呢?

  3. snapshot:被备份的数据事务tso号是备份的开始时间点吗?因为gc时间好像只有几分钟,而数据量大的话,整个备份需要几十分钟。事务结束的时候 备份起始点的数据版本会不会被gc掉了?

  4. 如果上面的问题OK,那么是否可以用br备份的事务tso作为起始位置点,配合binlog的增量备份,来做完善的备份恢复方案?
    比如br半小时执行一次,每次花半小时,binlog随时备份增量。恢复的时候找到br备份的起始点,根据起始位置找到binlog的起始恢复点?

BR 备份其实没有想象的这么多工作
及BR 备份是备份的备份开始的时间节点的数据。其在备份开始时 会去 PD 请求 TSO 并,启用自适应 GC ,之后再进行备份。所以以上问题1 -2-3 问题不用考虑
备份结束后 BR 会在 PD 中将 自适应 GC 时间改回原来的 GC 设置

问题 4 :
其实 PITR 是我们一直在推进的一个重要功能,后续的物理备份通过 BR 增量 日志的备份是通过 TiCDC ,目前 master 分支上已有 将 tikv change log 写入到本地存储和 S3 中的功能。

在 5.0 后续的版本中,将会支持 完整的 PITR 功能,简化此部分的操作复杂度。

@北京大爷
非常感谢您的回复 .

想进一步问一下

https://docs.pingcap.com/zh/tidb/stable/backup-and-restore-use-cases#备份前的准备工作

自 v4.0.8 起,BR 已支持自适应 GC。将 backupTS 注册到 PD 的 safePoint ,保证 safePoint 在备份期间不会向前移动,由此可避免手动设置 GC。

我的理解是 问题3 没问题了.

那么问题1和问题2, 还没有被写到 SST 的内容是如何被备份走的呢?
难道 safePoint 背后有这样的 flush to sst 的机制吗?

这里涉及 2 个 概念
一个是 tikv 的 mvcc 实现。
还有一个是 br 备份的 time point

tidb 的 mvcc 是通过 KV 的 持久化实现的 MVCC
br 备份的是时间点是 备份动作的 开始时间点

所以 当使用 br 发起备份的时候 只用控制 TiDB的 GC 动作 不要把 过去的 MVCC 数据清理掉就可以了。br 向 pd 询问原信息,通知 tikv 导出指定数据到 sst 文件即可

1赞

其实我是想请教一下实现细节:

您说的mvcc是tikv的上层实现,那么底层其实还是rocks db。而在rocksdb的实现细节里,据说是一部分数据在memtable内,到一定的时机才会变成不可变的一块数据进而转存到SST文件内。也就是底层SST并不是所有的数据的集合。
那么问题来了,br只利用上层接口,实际要备份的内容却是底层SST文件,那他如果不命令rocks将memtable吐到SST,岂不是漏掉了需要备份的数据?怎么解决的呢?

备份的结果转成了 SST 文件,但是备份的直接对象并不是 SST 文件吧?

1赞

明白了,多谢指教。

原来是我误解了br。以为SST的备份是物理备份。实际上br的备份是逻辑备份。

https://github.com/pingcap/br/blob/master/docs/cn/2019-08-05-new-design-of-backup-restore.md

捞到这篇文档,总算明白了。

多谢 @buptzhoutian @北京大爷

:+1: