When the current configuration contains only one node, we have a fast path in raft to skip the election and move directly from follower to leader:
|
/* Fast-forward to leader if we're the only voting server in the |
|
* configuration. */ |
|
server = configurationGet(&r->configuration, r->id); |
|
assert(server != NULL); |
|
assert(server->role == RAFT_VOTER); |
|
|
|
if (n_voters == 1) { |
|
tracef("self elect and convert to leader"); |
|
return convertToLeader(r); |
|
} |
This is great, but because the election code is responsible for incrementing the term number, we end up skipping this update for one-node clusters as well. This means we can have two distinct leaders that share a term number, as happens in this test:
|
TEST(cluster, dataOnNewNode, setUp, tearDown, 0, cluster_params) |
I think this behavior is unintuitive at best and we should add a term number increase on the fast path.
When the current configuration contains only one node, we have a fast path in raft to skip the election and move directly from follower to leader:
dqlite/src/raft/convert.c
Lines 171 to 180 in 6035a35
This is great, but because the election code is responsible for incrementing the term number, we end up skipping this update for one-node clusters as well. This means we can have two distinct leaders that share a term number, as happens in this test:
dqlite/test/integration/test_cluster.c
Line 127 in 6035a35
I think this behavior is unintuitive at best and we should add a term number increase on the fast path.