TiDB用的rocksdb，rocksdb有物理备份工具myrockshotbackup，为什么tidb不采用物理备份方案？
现在的BR备份我看了基本原理之后发现还是一个逻辑备份，而且在恢复的时候还要rewrite key，这个看起来在大数据量的情况下性能不会太好，从以前传统数据库例如Oracle以及mysql来看，逻辑备份性能比物理备份性能要差很多数量级。
所以想问问TiDB的BR为何不用物理备份方案？
- Br 就是物理备份，逻辑备份是指通过 tidb server 以库表的形式导出数据，例如使用 dumpling 工具。
- Br 是通过 tikv 扫描当前实例上 region leader 的 key-value 数据，直接生成 rocksdb 的 sst 文件。
- Br 备份时，为了获取一致性备份，会有个 [startTs, endTs)， 基于 tidb 的 mvcc，也就是说会把扫描出来的，但是不在范围内的版本给过滤掉。
- 恢复时候的 rewirte key，那是因为 key 包含 tableId、indexId 信息，在恢复的表上，tableId、indexId 可能变化了，通过 rewrite key 替换为新的前缀，使用物理的方式进行恢复。
- Br 只备份当前 tikv 上为 leader 的 region 数据，因为 tikv 多副本，只需要备份一个的数据就行了。
- myrockshotbackup 这个是不是限制为 myrocks 针对mysql的 rocksdb引擎的备份？在 tidb 体系应该没有适用性；另外就是参考 5，不需要每个 tikv 把所有副本的数据都备份出来。
- br 是分布式备份，所有的 tikv 节点可以同时进行，所以备份速度应该也能接受。
我从tidb的6.2的源码的doc中看到的关于BR的设计原理，select *还是BR的基本实现原理，跟mydumper的区别在于分布式执行而已，我所立即的物理备份即拷贝rocksdb的物理文件的方式，而不是通过tikv去select所有的数据出来形成sst。
你发的这个备份原理，就是我上面写的这个意思。参考 2、3、4、5。
- 参考上面的 5，只需要备份一个副本的数据，如果每个 tikv 都物理备份，那就备份了多个副本数据
- TiDB的体系，可能没有你说的这样的合适的工具，或者说现在还没开发出来，你说的那个工具是基于mysql体系的myrocks引擎，跟tikv使用rocksdb是不一样的。
3 个赞
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。