既然gc清理的只是过期的数据，那么应该只会影响到tikv数据目录中的.sst文件，不会影响到.log文件呀，为什么日志备份还是会因为gc safepoint超过了日志备份的起始时间而失败呢？
tikv数据目录内的文件.sst文件和.log文件：
启动日志备份失败：
并非一个层面的东西，TiKV 是在 Rocksdb 上层又构建了 MVCC 层，通过在 key 后增加版本号来实现的，TiDB 里的 GC 是这里的 GC，删除不在需要的老版本数据
那意思是每次gc既会删除.sst文件内的数据，又回删除.log文件内的数据？
TiKV 日志备份里的 changelog 指的并不是这些 .log 文件，这些变更数据其实也存在RocksDB 上，具体到物理文件也在 .sst 文件内。
具体而言，备份分为 全量备份 和 增量备份，
全量备份 : 备份的是某个 MVCC 的快照，需要保障要读的快照是一致性的。所以 GC 时间必须不能超过备份时的 TSO。 详细的备份逻辑可以见： https://docs.pingcap.com/zh/tidb/stable/br-snapshot-architecture#备份流程
增量备份(PITR)：备份的是 kv changelog，这个也是直接由 TiKV 的单独模块来处理，详细可以见： https://docs.pingcap.com/zh/tidb/stable/br-log-architecture#日志备份
1 个赞
那么是否可以理解为：br实现的增量、差异、日志备份其实原理都是一样的（读取.sst文件内的changelog），所以增量、差异、日志备份因为gc safepoint失败，都是因为gc删除掉了它们所需要的changelog。
还有目录下的那些.log文件是什么文件呢？有什么作用呢？
这些原理性的也都有看过，我主要的问题应该是在具体实现这一块了。 
TiKV 不考虑底层 Rockdb 是如何处理 .sst 文件和 .log 文件的，TiDB 集群的 GC 只是将过期 MVCC 版本调用 Rocksdb 接口删除（实际 Rocksdb 底层还是写入），后边随着 Rocksdb 的 compaction 才会回收空间
既然只删除了MVCC版本，那不应该影响到日志呀。我主要是想不明白为什么这个gc会影响到后续的 增量/差异/日志 备份。
不是一个层面的东西，日志备份不是备份的 Rocksdb 的 wal 日志，TiKV 是在 Rocksdb 上层又构建了 MVCC 层，捕捉 TiKV 数据变化日志，备份的这个日志，需要 TiDB 集群层面 GC 未过期，与更底层的 Rocksdb 的 wal 日志无关
1 个赞
就如龙虾大佬说的，是不同层面的虚拟，就跟 TCP/IP 协议组一样，跨层之间是不会考虑下层的具体实现的。
RocksDB 只是 TiKV 用来做单机存储的一种选择，并不关心 RocksDB 是如何通过 WAL 日志(.log 文件)做持久化的；同理 GC、BR 这些逻辑也只是和 TiKV 打交道，也只和 TiKV 的 GC 逻辑有依赖关系，而 GC 则是清理 TiKV 层面的 MVCC，至于底层的 RocksDB 什么时候清理 WAL 日志，什么时候做 Compact，TiKV 并不关注。
感觉你是没有理解 TiKV 的 GC 到底清理的是什么数据。 你可以认为 TiKV 层面的 GC 和底层 RocksDB 的 compact 清理 WAL 日志(.log文件) ，没有任何关系。 底层 RocksDB 清理 .log 文件对 TiKV 来说是完全透明的。
1 个赞
那应该是这样一个逻辑关系：br，gc – tikv – rocksdb。gc清理只是在tikv层面进行，br日志备份也并非备的就是底层（rocksdb）的WAL日志，也只到tikv层面。所以br的日志备份和底层的WAL日志逻辑实现上其实没有关系。
1 个赞
可以这么理解