TiFlash的高可用问题

🪐 TiDB 技术问题
1

Delta Cache 的设计有丢数据的风险。因此一般存储引擎在写入数据之前需要先写入 WAL，在重启之后从上一个 flush point 恢复。但由于 Delta Tree 是为 TiDB 设计的列存引擎，它充分利用了 TiDB 的特点，即 raft 协议。在 raft 协议中，任何一个更新，会先写入 raft log，等待大多数副本确认之后，才会将这个更新 apply 到状态机（即数据库存储引擎）。所以我们直接利用 raft log 实现了 WAL，即在 flush 之后才更新 raft log applied index。
这段描述我理解是TiDB的高可用保证，但是应该没办法保证Tiflash Delta Tree写Delta Cache数据不会丢失吧。Tiflash副本挂了之后，Delta Cache中的数据从哪里可以找回？raft log中会有？没想明白

2

TiFlash Delta Cache 数据不会丢失，因为所有更新已持久化在 TiKV 的 Raft Log 中；Tiflash 副本挂掉重启后，会从上次已持久化的 Apply Index 开始重放 Raft Log，完整恢复 Delta Cache 中未 Flush 的数据

3

TiFlash 的 Delta Cache 虽无本地 WAL，但其数据源自 TiKV 中持久化的 Raft Log；节点崩溃后可通过重放未应用的 Raft 日志恢复，因此不会丢数据。

1 个赞
4

重新从tikv同步追平方案能不能行呢

5
  • Delta Cache：是 TiFlash 内存中的增量数据缓存，用于高效写入和查询，它本身不保证持久化，重启后会清空。
  • Raft Log：是 TiDB/TiFlash 之间数据同步的核心日志，所有更新都会先写入 Raft Log，并通过 Raft 协议同步到多数副本，保证数据不丢失。
  • TiFlash 利用 Raft Log 实现了类似 WAL 的功能：数据先写入 Raft Log，再 apply 到 Delta Tree，最后通过 flush 持久化到磁盘。
6

会从tikv的raft log中重放