design: Add raft.md #2318
design: Add raft.md #2318
Conversation
aaronlehmann
force-pushed
the
design-raft
branch
from
195720f
to
d0f71ac
Compare
Codecov Report
@@ Coverage Diff @@
## master #2318 +/- ##
==========================================
+ Coverage 60.1% 60.19% +0.09%
==========================================
Files 128 128
Lines 25930 25891 -39
==========================================
+ Hits 15584 15585 +1
+ Misses 8956 8920 -36
+ Partials 1390 1386 -4 |
design/raft.md
Outdated
| a distributed fashion, we would need some mechanism to resolve conflicts between | ||
| writes made by different nodes. Limiting decision-making to the leader avoids | ||
| the need for this, since we can be certain that there is at most one leader at | ||
| any time. |
There was a problem hiding this comment.
Non-blocking - this is probably understood, it may be useful to mention that the leader has the latest version of the store at any given time, which is another reason why it's useful to run all these services on the leader.
design/raft.md
Outdated
| any time. | ||
|
|
||
| The basic rule is that anything which writes to the Raft-backed data store needs | ||
| to run on the manager. If a follower node tries to write to the data store, the |
There was a problem hiding this comment.
Should "on the manager" be "on the leader"?
| combination of sending snapshots and log entries. It can take a little while for | ||
| a new node to become a functional member of the consensus group, because it | ||
| needs to receive this data first. | ||
|
|
There was a problem hiding this comment.
Would it be useful to say here that as a node is caught up, when it is catching up by means of log entries, it basically plays each log entry, so if something is watching for changes as it is playing through those entries, they'll get lots of update events instead of one final state?
This detail caused some possible issues when I was doing CA rotation, and could be a gotcha to keep in mind.
This document explains how the Raft implementation works. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
aaronlehmann
force-pushed
the
design-raft
branch
from
d0f71ac
to
fd085c7
Compare
|
Updated. |
|
|
||
| WALs and snapshots are both stored encrypted, even if the autolock feature is | ||
| disabled. With autolock turned off, the data encryption key is stored on disk in | ||
| plaintext, in a header inside the TLS key. When autolock is turned on, the data |
There was a problem hiding this comment.
This last sentence is a tongue twister 🤣
This document explains how the Raft implementation works.