Repository: kafka Updated Branches: refs/heads/trunk c9311d5f4 -> ac7b2e95d
KAFKA-2551; Update Unclean leader election docs Author: Manikumar reddy O <[email protected]> Reviewers: Ismael Juma <[email protected]>, Sriharsha Chintalapani <[email protected]> Closes #1054 from omkreddy/KAFKA-2551 Project: http://git-wip-us.apache.org/repos/asf/kafka/repo Commit: http://git-wip-us.apache.org/repos/asf/kafka/commit/ac7b2e95 Tree: http://git-wip-us.apache.org/repos/asf/kafka/tree/ac7b2e95 Diff: http://git-wip-us.apache.org/repos/asf/kafka/diff/ac7b2e95 Branch: refs/heads/trunk Commit: ac7b2e95d342972e3499d203bc23e1675e90c591 Parents: c9311d5 Author: Manikumar reddy O <[email protected]> Authored: Sun Mar 13 20:32:47 2016 -0700 Committer: Sriharsha Chintalapani <[email protected]> Committed: Sun Mar 13 20:32:47 2016 -0700 ---------------------------------------------------------------------- docs/design.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/kafka/blob/ac7b2e95/docs/design.html ---------------------------------------------------------------------- diff --git a/docs/design.html b/docs/design.html index c04b772..ad40431 100644 --- a/docs/design.html +++ b/docs/design.html @@ -240,7 +240,7 @@ However a practical system needs to do something reasonable when all the replica <li>Choose the first replica (not necessarily in the ISR) that comes back to life as the leader. </ol> <p> -This is a simple tradeoff between availability and consistency. If we wait for replicas in the ISR, then we will remain unavailable as long as those replicas are down. If such replicas were destroyed or their data was lost, then we are permanently down. If, on the other hand, a non-in-sync replica comes back to life and we allow it to become leader, then its log becomes the source of truth even though it is not guaranteed to have every committed message. In our current release we choose the second strategy and favor choosing a potentially inconsistent replica when all replicas in the ISR are dead. In the future, we would like to make this configurable to better support use cases where downtime is preferable to inconsistency. +This is a simple tradeoff between availability and consistency. If we wait for replicas in the ISR, then we will remain unavailable as long as those replicas are down. If such replicas were destroyed or their data was lost, then we are permanently down. If, on the other hand, a non-in-sync replica comes back to life and we allow it to become leader, then its log becomes the source of truth even though it is not guaranteed to have every committed message. By default Kafka chooses the second strategy and favor choosing a potentially inconsistent replica when all replicas in the ISR are dead. This behavior can be disabled using configuration property unclean.leader.election.enable, to support use cases where downtime is preferable to inconsistency. <p> This dilemma is not specific to Kafka. It exists in any quorum-based scheme. For example in a majority voting scheme, if a majority of servers suffer a permanent failure, then you must either choose to lose 100% of your data or violate consistency by taking what remains on an existing server as your new source of truth.
