【TiKV / HTAP 内核】Snapshot、log GC 与副本迁移
内容提要
TiKV 通过 Raft Snapshot 解决副本落后问题，允许副本直接从 Leader 同步，避免日志重放开销。日志 GC 定期清理不再需要的日志，确保副本正常追赶。TiKV 支持 Voter、Learner 和 Witness 三种副本形态，以提高系统容错能力和存储效率。
关键要点
-
TiKV 通过 Raft Snapshot 解决副本落后问题，允许副本直接从 Leader 同步，避免日志重放开销。
-
日志 GC 定期清理不再需要的日志，确保副本正常追赶。
-
TiKV 支持 Voter、Learner 和 Witness 三种副本形态，以提高系统容错能力和存储效率。
-
Snapshot 生成时机与开销，主要在副本日志进度落后超过阈值时触发。
-
日志 GC 通过周期性检查和阈值配置，确保不再需要的日志被截断，避免影响慢副本的追赶。
-
副本迁移过程中采用 Joint Consensus 以降低容错风险，确保在迁移期间维持足够的副本数量。
-
Witness 副本设计用于降低存储成本，参与投票但不存储数据，适用于跨机房容灾场景。
延伸解读
Snapshot 的重要性与开销
TiKV 的 Snapshot 机制在副本落后时提供了有效的解决方案，避免了逐条日志重放的高开销。然而，生成 Snapshot 需要消耗 I/O 和网络带宽，尤其是在数据量大的情况下。因此，合理配置 Snapshot 生成的阈值和频率至关重要，以平衡性能与资源消耗。
日志 GC 的平衡策略
日志 GC 机制确保不再需要的 Raft 日志被及时清理，避免占用过多磁盘空间。但过于激进的日志 GC 可能导致慢副本被迫走 Snapshot，增加系统负担。因此，设置合理的日志保留阈值是确保系统高效运行的关键。
副本迁移中的风险管理
在副本迁移过程中，TiKV 引入了 Joint Consensus 机制以降低容错风险。通过确保新旧副本同时满足多数派确认，系统在迁移期间保持了足够的容错能力。这一设计在三副本集群中尤为重要，避免了因节点故障导致的可用性下降。
不同副本形态的应用场景
TiKV 支持 Voter、Learner 和 Witness 三种副本形态，各自适用于不同的场景。Voter 适合标准投票和数据存储，Learner 用于安全扩容，而 Witness 则在跨机房容灾中降低存储成本。理解这些副本的特性有助于优化系统架构和资源配置。
延伸问答
TiKV 如何解决副本落后问题？
TiKV 通过 Raft Snapshot 允许落后的副本直接从 Leader 同步，避免了日志重放的开销。
什么是日志 GC，TiKV 是如何实现的？
日志 GC 是定期清理不再需要的日志，TiKV 通过周期性检查和阈值配置来确保日志被截断，避免影响慢副本的追赶。
TiKV 支持哪些副本形态，它们有什么区别？
TiKV 支持 Voter、Learner 和 Witness 三种副本形态，分别用于参与投票、只接收日志和降低存储成本。
Snapshot 的生成时机是什么？
Snapshot 在副本日志进度落后超过阈值时触发，或当新副本加入时生成。
什么是 Joint Consensus，TiKV 如何使用它？
Joint Consensus 是一种安全的副本迁移机制，TiKV 在迁移过程中通过同时维持旧新副本的多数派来降低容错风险。
Witness 副本的设计目的是什么？
Witness 副本用于降低存储成本，它参与投票但不存储数据，适用于跨机房容灾场景。
