[
https://issues.apache.org/jira/browse/KUDU-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Percy updated KUDU-2172:
-----------------------------
Description:
Fractional voting is a concept where different voters in a Raft config get
different voting weights. This can tip the balance in certain cases in which it
would otherwise be impossible to achieve a majority.
Example: With equally-weighted votes -- the standard scenario -- in a 4-voter
config \{A, B, C, D\}, if a network partition bifurcated this config into two
equal groups \{A, B\} and \{C, D\} then no one side could achieve a strict
majority (greater than 2 out of 4 votes) and thus the configuration (as a
whole) would be unavailable for writes. With fractional voting, if some (but
not all) voters got an additional fractional weight to their vote, perhaps
\{A=1.1, B=1.1, C=1.1, D=1.0\} it would be possible for some group of two nodes
to achieve a majority of votes. In this case, the \{A, B\} group would have a
combined weight of 2.2 out of 4.3, which is a strict majority. Therefore the
\{A, B\} group would be able to elect a leader between them and accept writes
to only the two nodes.
There is a durability tradeoff, in exchange for availability, in the above
scenario.
It is worth noting that there is a utility overlap in certain scenarios between
fractional voting and config change cancellation (KUDU-1194).
This idea was suggested by Todd during a discussion of the [3-4-3
re-replication
design|https://docs.google.com/document/d/1_gQ3BONhKVR2hFlDTShtdx1vHkbVTcLE3b-nrNFwGDI].
was:
Fractional voting is a concept where different voters in a Raft config get
different voting weights. This can tip the balance in certain cases in which it
would otherwise be impossible to achieve a majority.
Example: With equally-weighted votes -- the standard scenario -- in a 4-voter
config \{A, B, C, D\}, if a network partition bifurcated this config into two
equal groups \{A, B\} and \{C, D\} then no one side could achieve a strict
majority (greater than 2 out of 4 votes) and thus the configuration (as a
whole) would be unavailable for writes. With fractional voting, if some (but
not all) voters got an additional fractional weight to their vote, perhaps
\{A=1.1, B=1.1, C=1.1, D=1.0\} it would be possible for some group of two nodes
to achieve a majority of votes. In this case, the \{A, B\} group would have a
combined weight of 2.2 out of 4.3, which is a strict majority. Therefore the
\{A, B\} group would be able to elect a leader between them and accept writes
to only the two nodes.
There is a durability tradeoff, in exchange for availability, in the above
scenario.
It is worth noting that there is a utility overlap in certain scenarios between
fractional voting and config change cancellation (KUDU-1729).
This idea was suggested by Todd during a discussion of the [3-4-3
re-replication
design|https://docs.google.com/document/d/1_gQ3BONhKVR2hFlDTShtdx1vHkbVTcLE3b-nrNFwGDI].
> Fractional voting
> -----------------
>
> Key: KUDU-2172
> URL: https://issues.apache.org/jira/browse/KUDU-2172
> Project: Kudu
> Issue Type: Bug
> Components: consensus
> Reporter: Mike Percy
>
> Fractional voting is a concept where different voters in a Raft config get
> different voting weights. This can tip the balance in certain cases in which
> it would otherwise be impossible to achieve a majority.
> Example: With equally-weighted votes -- the standard scenario -- in a 4-voter
> config \{A, B, C, D\}, if a network partition bifurcated this config into two
> equal groups \{A, B\} and \{C, D\} then no one side could achieve a strict
> majority (greater than 2 out of 4 votes) and thus the configuration (as a
> whole) would be unavailable for writes. With fractional voting, if some (but
> not all) voters got an additional fractional weight to their vote, perhaps
> \{A=1.1, B=1.1, C=1.1, D=1.0\} it would be possible for some group of two
> nodes to achieve a majority of votes. In this case, the \{A, B\} group would
> have a combined weight of 2.2 out of 4.3, which is a strict majority.
> Therefore the \{A, B\} group would be able to elect a leader between them and
> accept writes to only the two nodes.
> There is a durability tradeoff, in exchange for availability, in the above
> scenario.
> It is worth noting that there is a utility overlap in certain scenarios
> between fractional voting and config change cancellation (KUDU-1194).
> This idea was suggested by Todd during a discussion of the [3-4-3
> re-replication
> design|https://docs.google.com/document/d/1_gQ3BONhKVR2hFlDTShtdx1vHkbVTcLE3b-nrNFwGDI].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
