TIDB为什么不学习oracle以redo log写入为事务commit成功的标志

oracle的事务提交成功以redo log写入成功为标识,而tidb则要等待apply完毕才算提交成功。如果提前到rocksdb的raft committed阶段结束会不会好一点?

tidb是多节点啊,需要保证一致性。

这是分布式环境,不一样

原理不一样啊,tidb是以mvcc控制分布式事务的

oracle 是commit了,最新的数据放内存里面就行了,等落盘。分布式数据库要把数据同步给大多数的

tidb分布式事务强一致性,raft log committed阶段数据是已经持久化,也就是多副本已收到raft数据并返回消息给leader,而应用层事务提交要等raft log应用到rocksdb kv才算结束。

:thinking:分布式和集中式的区别一下子就出来了~

Oracle在提交时,为保证线性一致性,需要修改undo段头事务表(内存中的,不用立即落盘),让事务对其他会话可见,写入redo(必须写入磁盘),保证事务持久性,实例宕机也能恢复。
Tidb在提交时,为了保证线性一致性,需要等待apply完成,这样才能让其他会话看到,同时在这之前,要保证raft 层面commit,写入多个节点,保证单个节点宕机数据不丢失

2 个赞

rocksdb 加raft

架构的一样锕

我理解是commit了就要保证数据不丢,即持续性。
所以oracle单节点时默认本地redo log写完就好,而分布式tidb要保证完成多数派写,因为万一本地写成功的节点挂了,其他2个节点还是旧数据,就不能保证commit的持续性。

oracle默认是要等redo log落盘才返回commit成功的,少数非交互式的场景可使用commit write nowait实现你说的异步提交。

分布式的要等同步到别的节点才行啊

这是分布式环境呢

oracle不也是支持事务的吗?支持事务的话不都得遵循mvcc吗?oracle 又是怎么来控制事务的呢?

实际上redo log被LGWR进程写到文件就提供了事务恢复的条件。对应是rockdb raft日志的commit。apply的过程跟oracle块数据回磁盘是对应的。所以感觉应该是可以搞的。

设计理念都不一样,没有必要学习他

tidb对应的应该是写到存储数据的rocksdb的WAL