【 TiDB 使用环境】生产 【 TiDB 版本】 【遇到的问题】 【复现路径】做过哪些操作出现的问题`
【问题现象及影响】
wal是保证事务持久性的一个重要手段，相当于oracle/mysql中的redo log。事务的写操作一定是先持久化到wal，再异步将脏数据刷到磁盘上的。如果数据库异常宕机，则可利用wal恢复数据。
raft log是raft一致性协议中进行数据复制的日志，也是保证CAP理论中一致性的手段。当事务在leader副本上发起commit时，事务的写操作会被封装成raft log entry，复制到多数派节点并进行append和apply后，commit操作才能成功返回。
ticdc是直接从tikv上读取的kv change log，不是raft log
2 个赞
raft log 是用于tikv 各个实例之间做数据同步的，举个不恰当的比喻就像的mysql的binlog 做主从同步，
而wal 日志是tikv的存储引擎rocksdb 具有的，这一点类似于mysql的redo log
2 个赞
非常感谢，补充的回答解决了我的疑惑，但是想问下，kv change log是独立于 wal 日志和raft log之外的第三个日志吗？
多谢回答，您补充的解决了我的疑惑
在一个问题，rocksdb raft 实例在写入raft log的时候 ，也是需要wal日志来保护的，对吧
是的，数据写入memtable的时候也会写wal
写 raft log到rockdb实例的时候，有写memtable吗？
惭愧了，去年考了pctp，今年新年单位有tidb发现都忘记了，看来得再学一遍了
memtable是rocksdb的组件
是的，还是要学以致用，要不然容易忘
tikv底层分2个rocksdb，其中一个存储raftlog，一个存储数据。这里的raftlog 是tikv写数据的时候，首先通过raftlog保持3个tikv之间的数据一致，是raft协议记录的log，但是这个raftlog最终落到rocksdb也就是在rocksdb的存储一组kv，就是普普通通的一组kv。
然后说下wal rocksdb写数据时，先写memtable，memtable的意思是内存中的表。如果只写内存就返回了，那数据相当于没有持久化，所以要写一个wal，直接追加日志的形式写文件，相当于顺序写文件，磁盘顺序写文件速度是比较快的。
1 个赞
每个tikv有两个rocksdb实例，一个是存raft log的，一个是存真正数据的，分别是：rocksdb raft和rocksdb db这俩实例 , 然后写rocksdb db这个rocksdb实例的时候是先写wal，然后写memtable,请问写raft log到rocksdb raft实例的时候，也是先写wal，然后写memtable的吗？应该是这样吧
经典类似于MySQL的两阶段提交
rocksdb写一个key/value的时候都是先写wal再写memtable，rcksdb-raft也无非是用一个普通的rocksdb存raft数据，所以并没什么不一样。
1 个赞
用户写入的键值对会先写入磁盘上的 WAL (Write Ahead Log)，又可以理解为 KV 变更日志（KV Change Logs）。一旦同步任务创建，TiCDC集群就会拉取这些 row changed events
这段话是我在一片文章上看到的， 这句话对不对呢？ wal就是kv change logs
ticdc不会读wal，wal是rocksdb层的东西。
kv change log是独立于 wal 日志和raft log之外的第三种日志吗？ 最近要整ticdc了，所以想了解下kv change log是啥东西，kv change log是什么写入机制
不了解kv change log是什么。我猜测应该是从raft那一层组织的log。