Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Dev Docs: Fix list view in raft-in-scylla dev docs #1

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Dev Docs: Fix list view in raft-in-scylla dev docs #1

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 11 additions & 8 deletions docs/dev/raft-in-scylla.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,10 +11,11 @@ operations. This is why the Raft library in raft/ has the only dependency

In order to use the library, the client (Scylla server) needs to
provide implementations for three key interfaces:
- persistence - to persist Raft state
- rpc - to exchange messages with instances of the library

- persistence - to persist Raft state
- rpc - to exchange messages with instances of the library
on other machines
- the client state machine - to execute commands once
- the client state machine - to execute commands once
they were replicated and committed on a majority of nodes.

Depending on the application (data, topology, or schema) Scylla can use
Expand All @@ -34,13 +35,14 @@ with Raft peers of the group on other nodes.
For example, to persist the changes to schema and topology, Scylla
can (and does) use node-local system tables.
There are three such tables:
- `raft`, the main table which stores the Raft log for each

- `raft`, the main table which stores the Raft log for each
group. The table partition key is group id, so each log
forms its own partition. Since the table is local, this
works fine with many groups.
- `raft_snapshots`, a supporting table storing the so-called
- `raft_snapshots`, a supporting table storing the so-called
snapshot descriptors,
- `raft_config`, a normalized part of raft
- `raft_config`, a normalized part of raft
`raft_snapshots`, storing the cluster configuration
at the time of taking the snapshot. May be out of date with
the real cluster configuration, e.g. when configuration
Expand Down Expand Up @@ -135,7 +137,8 @@ in the same order on every node. However, while Raft guarantees
that if an operation succeeds, it's stored in the logs on the
majority of nodes, it doesn't provide an API for strictly ordered
schema changes out of the box, for two reasons:
- Raft only stores a log of the operations. The operations

- Raft only stores a log of the operations. The operations
themselves - the schema changes - are applied to the client
state machine once they are committed to the log. In order
to construct a new operation it's necessary to read the
Expand All @@ -156,7 +159,7 @@ schema changes out of the box, for two reasons:
yet, and append identical commands for creating the table to
the Raft log. The second command will fail to apply to the
client state machine.
- if a leader or network fails when committing an operation to
- if a leader or network fails when committing an operation to
Raft log, the client has no way of knowing its status. E.g. a
network can time out, and establishing whether or not the
majority of Raft nodes store the command in its log or have applied it
Expand Down