kafka-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From srihar...@apache.org
Subject kafka git commit: KAFKA-2551; Update Unclean leader election docs
Date Mon, 14 Mar 2016 03:33:18 GMT
Repository: kafka
Updated Branches:
  refs/heads/trunk c9311d5f4 -> ac7b2e95d


KAFKA-2551; Update Unclean leader election docs

Author: Manikumar reddy O <manikumar.reddy@gmail.com>

Reviewers: Ismael Juma <ismael@juma.me.uk>, Sriharsha Chintalapani <mail@harsha.io>

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 <manikumar.reddy@gmail.com>
Authored: Sun Mar 13 20:32:47 2016 -0700
Committer: Sriharsha Chintalapani <harsha@hortonworks.com>
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.
 


Mime
View raw message