[jira] [Commented] (KAFKA-4711) Change Default unclean.leader.election.enabled from True to False (KIP-106)

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-4711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321146#comment-16321146 ] 

ASF GitHub Bot commented on KAFKA-4711:
---------------------------------------

junrao closed pull request #3567: KAFKA-4711: fix docs onunclean.leader.election.enable default
URL: https://github.com/apache/kafka/pull/3567
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/docs/design.html b/docs/design.html
index 564df386db7..69d1941effd 100644
--- a/docs/design.html
+++ b/docs/design.html
@@ -238,8 +238,8 @@ <h3><a id="semantics" href="#semantics">4.6 Message Delivery Semantics</a></h3>
     can fail, cases where there are multiple consumer processes, or cases where data written to disk can be lost).
     <p>
     Kafka's semantics are straight-forward. When publishing a message we have a notion of the message being "committed" to the log. Once a published message is committed it will not be lost as long as one broker that
-    replicates the partition to which this message was written remains "alive". The definition of committed message, alive partition as well as a description of which types of failures we attempt to handle will be 
-    described in more detail in the next section. For now let's assume a perfect, lossless broker and try to understand the guarantees to the producer and consumer. If a producer attempts to publish a message and 
+    replicates the partition to which this message was written remains "alive". The definition of committed message, alive partition as well as a description of which types of failures we attempt to handle will be
+    described in more detail in the next section. For now let's assume a perfect, lossless broker and try to understand the guarantees to the producer and consumer. If a producer attempts to publish a message and
     experiences a network error it cannot be sure if this error happened before or after the message was committed. This is similar to the semantics of inserting into a database table with an autogenerated key.
     <p>
     Prior to 0.11.0.0, if a producer failed to receive a response indicating that a message was committed, it had little choice but to resend the message. This provides at-least-once delivery semantics since the
@@ -309,11 +309,11 @@ <h3><a id="replication" href="#replication">4.7 Replication</a></h3>
     handle so-called "Byzantine" failures in which nodes produce arbitrary or malicious responses (perhaps due to bugs or foul play).
     <p>
     We can now more precisely define that a message is considered committed when all in sync replicas for that partition have applied it to their log.
-    Only committed messages are ever given out to the consumer. This means that the consumer need not worry about potentially seeing a message that could be lost if the leader fails. Producers, on the other hand, 
-    have the option of either waiting for the message to be committed or not, depending on their preference for tradeoff between latency and durability. This preference is controlled by the acks setting that the 
+    Only committed messages are ever given out to the consumer. This means that the consumer need not worry about potentially seeing a message that could be lost if the leader fails. Producers, on the other hand,
+    have the option of either waiting for the message to be committed or not, depending on their preference for tradeoff between latency and durability. This preference is controlled by the acks setting that the
     producer uses.
     Note that topics have a setting for the "minimum number" of in-sync replicas that is checked when the producer requests acknowledgment that a message
-    has been written to the full set of in-sync replicas. If a less stringent acknowledgement is requested by the producer, then the message can be committed, and consumed, 
+    has been written to the full set of in-sync replicas. If a less stringent acknowledgement is requested by the producer, then the message can be committed, and consumed,
     even if the number of in-sync replicas is lower than the minimum (e.g. it can be as low as just the leader).
     <p>
     The guarantee that Kafka offers is that a committed message will not be lost, as long as there is at least one in sync replica alive, at all times.
@@ -384,8 +384,8 @@ <h4><a id="design_uncleanleader" href="#design_uncleanleader">Unclean leader ele
     <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. 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.
+    have every committed message. By default from version 0.11.0.0, Kafka chooses the first strategy and favor waiting for a consistent replica. This behavior can be changed using
+    configuration property unclean.leader.election.enable, to support use cases where uptime is preferable to consistency.
     <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.
@@ -503,8 +503,8 @@ <h4><a id="design_compactionguarantees" href="#design_compactionguarantees">What
     guarantee the minimum length of time must pass after a message is written before it could be compacted. I.e. it provides a lower bound on how long each message will remain in the (uncompacted) head.
     <li>Ordering of messages is always maintained.  Compaction will never re-order messages, just remove some.
     <li>The offset for a message never changes.  It is the permanent identifier for a position in the log.
-    <li>Any consumer progressing from the start of the log will see at least the final state of all records in the order they were written.  Additionally, all delete markers for deleted records will be seen, provided 
-    the consumer reaches the head of the log in a time period less than the topic's <code>delete.retention.ms</code> setting (the default is 24 hours).  In other words: since the removal of delete markers happens 
+    <li>Any consumer progressing from the start of the log will see at least the final state of all records in the order they were written.  Additionally, all delete markers for deleted records will be seen, provided
+    the consumer reaches the head of the log in a time period less than the topic's <code>delete.retention.ms</code> setting (the default is 24 hours).  In other words: since the removal of delete markers happens
     concurrently with reads, it is possible for a consumer to miss delete markers if it lags by more than <code>delete.retention.ms</code>.
     </ol>
 
@@ -522,7 +522,7 @@ <h4><a id="design_compactiondetails" href="#design_compactiondetails">Log Compac
     <p>
     <h4><a id="design_compactionconfig" href="#design_compactionconfig">Configuring The Log Cleaner</a></h4>
 
-    The log cleaner is enabled by default. This will start the pool of cleaner threads. 
+    The log cleaner is enabled by default. This will start the pool of cleaner threads.
     To enable log cleaning on a particular topic you can add the log-specific property
     <pre class="brush: text;">  log.cleanup.policy=compact</pre>
     This can be done either at topic creation time or using the alter topic command.


 

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> Change Default unclean.leader.election.enabled from True to False (KIP-106)
> ---------------------------------------------------------------------------
>
>                 Key: KAFKA-4711
>                 URL: https://issues.apache.org/jira/browse/KAFKA-4711
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Ben Stopford
>            Assignee: Sharad
>
> See https://cwiki.apache.org/confluence/display/KAFKA/KIP-106+-+Change+Default+unclean.leader.election.enabled+from+True+to+False



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)