日志复制疑问

🪐 TiDB 技术问题
1

TIKV写入逻辑（一个TIVK有两个rocksdb，一个存日志，一个存数据）

1.客户都发送请求后进入propose。

2.propose之后会把写入请求变成日志RAFT_log（RAFT日志包含，reagion号，log）append,把本地的日志持久化

3.leader会将日志发给follower，follower接收日志后，写入日志成功后返回消息给leader，当大多数节点返回消息后leader认为写入成功进入日志commit

4.日志commit之后，将l数据写入到rocksdb kv数据中，然后应用commit。

问题：如果在日志commit后 t数据还没有写入到rocksdb kv中，tikv挂了，这个时候应用是返货报错还是返回commit？如果应用返回报错的话是不是意味着数据不一致？（以上写入逻辑自己整理的，不清楚是否正确）

2
  1. 客户端发送写入请求后，请求会进入 TiKV 的 Propose 阶段，即将写入请求提交给 Raft 协议进行处理。
  2. 在 Propose 阶段之后，写入请求会被转换为 Raft 日志（Raft Log），包含了 Region 号和具体的操作日志。这些日志会被追加到 Raft Log 中，并在本地持久化。
  3. Leader 节点会将这些日志发送给 Follower 节点，Follower 节点接收并成功写入日志后会向 Leader 节点发送确认消息。当大多数节点都返回确认消息后，Leader 节点认为写入操作成功，并进入日志 Commit 阶段。
  4. 在日志 Commit 阶段之后，数据会被写入 RocksDB KV 数据库中，并应用 Commit 操作，确保数据的一致性和持久性。

现在来回答您的问题：

  • 如果在日志 Commit 后，数据还没有完全写入到 RocksDB KV 中，而 TiKV 挂掉了，此时应用会返回错误还是返回 Commit？
    • 在这种情况下，TiKV 会返回错误给应用程序。这是因为 TiKV 保证了数据的一致性和持久性，如果数据尚未完全写入 RocksDB KV 中，TiKV 会认为写入操作未完成，因此会返回错误给应用程序，而不是返回 Commit。
  • 如果应用程序返回错误，是否意味着数据不一致？
    • 是的，如果应用程序收到错误响应，意味着写入操作未能成功完成，数据可能存在不一致性。这种情况下，应用程序可以根据错误信息进行相应的处理，例如重试写入操作或者进行其他恢复措施，以确保数据的一致性和完整性。
1 个赞
3
  • 如果在日志 Commit 后，数据还没有完全写入到 RocksDB KV 中，而 TiKV 挂掉了，此时应用会返回错误还是返回 Commit？
    • 在这种情况下，TiKV 会返回错误给应用程序。这是因为 TiKV 保证了数据的一致性和持久性，如果数据尚未完全写入 RocksDB KV 中，TiKV 会认为写入操作未完成，因此会返回错误给应用程序，而不是返回 Commit。
      疑问：这个时候对于应用来说数据是没有写入成功的，但是对于tidb来说这个数据是完全写入成功的吧？（日志持久化后，tikv起来后也会做crash recover），那是否意味着如果在tikv层有flushback操作会更加合理 ？
4

需要应用程序判断