THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
We use a separate file to store the current state of the quorum. This is both for convenience and correctness. It helps us to initialize the quorum state after a restart, but we also need it in order to know which broker we have voted for in a given election. The Raft protocol does not allow voters to change their votes, so we have to preserve this state across restarts. Below is the schema for this quorum-state file.
| Code Block |
|---|
{
"type": "messagedata",
"name": "QuorumStateMessage",
"validVersions": "0",
"flexibleVersions": "0+",
"fields": [
{"name": "ClusterId", "type": "string", "versions": "0+"},
{"name": "LeaderId", "type": "int32", "versions": "0+"},
{"name": "LeaderEpoch", "type": "int32", "versions": "0+"},
{"name": "VotedId", "type": "int32", "versions": "0+"},
{"name": "AppliedOffset", "type": "int64", "versions": "0+"},
{"name": "CurrentVoters", "type": "[]Voter", "versions": "0+", "fields": [
{"name": "VoterId", "type": "int32", "versions": "0+"}
]},
{"name": "TargetVoters", "type": "[]Voter", "versions": "0+", "nullableVersions": "0+", "fields": [
{"name": "VoterId", "type": "int32", "versions": "0+"}
]}
]
} |
...
Writing the dummy entry with the new epoch is not necessary for correctness, but as an optimization to reduce the client request latency. Basically it allows for faster advancement of the high watermark following a leader election (the need for this is discussed in more detail below in the handling of FetchQuorumRecords). The dummy record will be a control record with Type=3. Below we define the schema:
| Code Block |
|---|
{
"type": "messagedata",
"name": "LeaderChangeMessage",
"validVersions": "0",
"flexibleVersions": "0+",
"fields": [
{"name": "LeaderId", "type": "int32", "versions": "0+",
"about": "The ID of the newly elected leader"},
{"name": "VotedIds", "type": "[]int32", "versions": "0+",
"about": "The IDs of the voters who voted for the current leader"},
]
} |
...