How to make the leader node implement log compressio？

[wego1236]

In raft-rs, I only found that the follower node can request snapshot to the leader node, or the leader sends snapshot to the follower node when synchronising the logs, but how does the leader node compress the logs itself? Is it truncated by the compact function, and then how to generate a snapshot to save it?

[BusyJay]

raft-rs is a crate that focus on Raft algorithm implementations. Snapshot and raft log are considered as application details that is beyond the crate's scope. raft-rs uses trait Storage to bridge between algorithm and applications.

For example, TiKV implements Storage trait as PeerStorage. It compacts logs via a proposal that will be proposed and commit by raft-rs and then applied outside of raft-rs. Logs are compressed when being written to underlying storage. And snapshot is generated asynchronously by scanning all key value pairs and writting them to SST files.

[wego1236]

Like in the storage example given in the repository, I see that there is a compact function and a snapshot interface, and I want to ask if I understand the workflow correctly?

1. If I use the compact function in the leader node for log compression, then the FOLLOWER node may not be able to catch up, and then LEADER will send a MsgSnapshot to that FOLLOWER, or the FOLLOWER node can directly request_snapshot to the LEADER node, so as to get a snapshot for the LEADER node.
2. If these two cases are correct, I'm also asking if the above two scenarios won't have an effect on the snapshot information of the LEADER node.

[BusyJay]

then the FOLLOWER node may not be able to catch up, and then LEADER will send a MsgSnapshot to that FOLLOWER

Yes, it's correct.

or the FOLLOWER node can directly request_snapshot to the LEADER node, so as to get a snapshot for the LEADER node

No, request_snapshot is another feature that doesn't happen automatically.

if the above two scenarios won't have an effect on the snapshot information of the LEADER node.

I'm not sure what "snapshot information" means. Leader will track follower status, and it will set the status to requesting snapshot and invoke Storage::snapshot to get a physical snapshot.

[wego1236]

No, request_snapshot is another feature that doesn't happen automatically.

Yes, I understand here, what I'm asking is if we can then actively use request_snapshot from Follower node to Leader node through this operation during external operations.

I'm not sure what "snapshot information" means. Leader will track follower status, and it will set the status to requesting snapshot and invoke Storage::snapshot to get a physical snapshot.

The "snapshot information" I'm referring to here is the Storage::snapshot you're talking about, but I'm still not sure if, in a periodic run of raft-rs, if the snapshot information is only transferred to the other nodes via the Leader node, is the content stored in the leader node's Storage ::snapshot of the leader node is still same as the value we first initialized? Some of the operations here are not quite the same as some of the other systems I've looked at before, so I'm a little confused

[BusyJay]

what I'm asking is if we can then actively use request_snapshot from Follower node to Leader node through this operation during external operations.

You can. But it's not recommended as sending snapshot is considered an expansive operation and it will block log replication to the node.

is the content stored in the leader node's Storage ::snapshot of the leader node is still same as the value we first initialized

raft-rs doesn't store the result of Storage::snapshot. The value returned by the function will be handed to application via messages immediately. And application is responsible to parse the message and maintain the physical snapshot files including sending to followers, deleting stale files, etc.

[wego1236]

I understand. Thank you very much! But if possible could you give an example for snapshot in the example in raft-rs, in that case I would appreciate it!