Understanding Raft WAL Logs

[pawan (Pawan Rawal)]

My present understanding regarding this is that

1. We have multiple Raft groups(each containing 3 nodes and storing data for a predicate). Note that a node doesn’t mean an instance here. An instance could act and typically would act as nodes for multiple predicates.

2. Now each node has a memory storage and a WAL(this means a log per predicate). If I am thinking correct here then we could just use wal package - github.com/coreos/etcd/wal - Go Packages. Whenever a mutation comes, it is redirected to master of the group of nodes which form the Raft group for the predicate. Master writes it to its logs, sends it to other nodes(they write it to their logs), gets consensus and then the mutation is applied to all nodes.

3. From what I understand RAFT library can be configured to use the memory storage(raft package - github.com/coreos/etcd/raft - Go Packages) for transmitting the entries to other instances. WAL is used to load data into memory in case a node restarts.

4. Whenever a predicate has to be transferred to a new instance, we just make it part of the RAFT group for the predicate and data can then be streamed using Predicate RPC + the storage.

References

RAFT based Changes to commit logs

For Dgraph, RocksDB is our state machine. When we commit our dirty posting lists to RocksDB, and once we have confirmed sync to disk, we can discard the logs. This mechanism is great because we can avoid storing our commit logs. Each mutation would get written to RAFT logs, from where they’d get applied to RocksDB (state machine). As we merge our dirty posting lists, we can discard the older RAFT logs. In the case of server crash and restart, it would proactively go through all pending logs an…