Replies: 1 comment
-
Hi! This isn't actually a Raft-specific concern. Raft itself is agnostic about how state machines are structured - it simply requires that snapshots contain the complete state needed to restore the system to a consistent point. The only exception would be if you implement incremental snapshot transmission, where you might send chunk identifiers and skip transferring data that already exists on the follower. However, that's entirely an implementation detail at the application layer - Raft's protocol doesn't dictate how you handle the actual snapshot content or transmission optimization. The key requirement from Raft's perspective is that after applying a snapshot, the follower has all the state necessary to continue processing log entries from that point forward. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm new to Raft. I understand how it works, but this is my first time using it in production. In this project, I need to handle a large state. You can think of it as a KV database, but each Set command tends to create a new key rather than updating an existing one, making the state grow significantly over time. Typically, only the new keys are queried, so a cache can help with query performance. However, by design, all keys are part of the state and should be queryable, whether frequently or not. My concern now is on the Raft side. Are there best practices for handling a large state? How can I take snapshots without running into OOM issues? Is there anything else I should be aware of?
Beta Was this translation helpful? Give feedback.
All reactions