You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/10/29 05:13:00 UTC
[jira] [Commented] (KAFKA-7413) Replace slave terminology with
follower in website
[ https://issues.apache.org/jira/browse/KAFKA-7413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16666756#comment-16666756 ]
ASF GitHub Bot commented on KAFKA-7413:
---------------------------------------
ijuma closed pull request #5653: KAFKA-7413: Replace slave terminology with follower in website
URL: https://github.com/apache/kafka/pull/5653
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 bdc7e637ea9..77df2d31c1e 100644
--- a/docs/design.html
+++ b/docs/design.html
@@ -286,7 +286,7 @@ <h3><a id="replication" href="#replication">4.7 Replication</a></h3>
Kafka replicates the log for each topic's partitions across a configurable number of servers (you can set this replication factor on a topic-by-topic basis). This allows automatic failover to these replicas when a
server in the cluster fails so messages remain available in the presence of failures.
<p>
- Other messaging systems provide some replication-related features, but, in our (totally biased) opinion, this appears to be a tacked-on thing, not heavily used, and with large downsides: slaves are inactive,
+ Other messaging systems provide some replication-related features, but, in our (totally biased) opinion, this appears to be a tacked-on thing, not heavily used, and with large downsides: replicas are inactive,
throughput is heavily impacted, it requires fiddly manual configuration, etc. Kafka is meant to be used with replication by default—in fact we implement un-replicated topics as replicated topics where the
replication factor is one.
<p>
@@ -300,7 +300,7 @@ <h3><a id="replication" href="#replication">4.7 Replication</a></h3>
As with most distributed systems automatically handling failures requires having a precise definition of what it means for a node to be "alive". For Kafka node liveness has two conditions
<ol>
<li>A node must be able to maintain its session with ZooKeeper (via ZooKeeper's heartbeat mechanism)
- <li>If it is a slave it must replicate the writes happening on the leader and not fall "too far" behind
+ <li>If it is a follower it must replicate the writes happening on the leader and not fall "too far" behind
</ol>
We refer to nodes satisfying these two conditions as being "in sync" to avoid the vagueness of "alive" or "failed". The leader keeps track of the set of "in sync" nodes. If a follower dies, gets stuck, or falls
behind, the leader will remove it from the list of in sync replicas. The determination of stuck and lagging replicas is controlled by the replica.lag.time.max.ms configuration.
@@ -340,7 +340,7 @@ <h4><a id="design_replicatedlog" href="#design_replicatedlog">Replicated Logs: Q
all committed messages. That replica's log will be the most complete and therefore will be selected as the new leader. There are many remaining details that each algorithm must handle (such as precisely defined what
makes a log more complete, ensuring log consistency during leader failure or changing the set of servers in the replica set) but we will ignore these for now.
<p>
- This majority vote approach has a very nice property: the latency is dependent on only the fastest servers. That is, if the replication factor is three, the latency is determined by the faster slave not the slower one.
+ This majority vote approach has a very nice property: the latency is dependent on only the fastest servers. That is, if the replication factor is three, the latency is determined by the faster follower not the slower one.
<p>
There are a rich variety of algorithms in this family including ZooKeeper's
<a href="http://web.archive.org/web/20140602093727/http://www.stanford.edu/class/cs347/reading/zab.pdf">Zab</a>,
diff --git a/docs/quickstart.html b/docs/quickstart.html
index e709cc736f4..001880ce28e 100644
--- a/docs/quickstart.html
+++ b/docs/quickstart.html
@@ -192,7 +192,7 @@ <h4><a id="quickstart_multibroker" href="#quickstart_multibroker">Step 6: Settin
> taskkill /pid 6016 /f
</pre>
-<p>Leadership has switched to one of the slaves and node 1 is no longer in the in-sync replica set:</p>
+<p>Leadership has switched to one of the followers and node 1 is no longer in the in-sync replica set:</p>
<pre class="brush: bash;">
> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic
----------------------------------------------------------------
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
> Replace slave terminology with follower in website
> --------------------------------------------------
>
> Key: KAFKA-7413
> URL: https://issues.apache.org/jira/browse/KAFKA-7413
> Project: Kafka
> Issue Type: Improvement
> Components: website
> Reporter: Sayat Satybaldiyev
> Priority: Major
> Labels: newbie, pull-request-available
> Fix For: 2.2.0
>
>
> I'm prosing to replace the word "slave" with "follower" on Kafka website as "slave" has a negative connotation.
>
> Inspired by: [https://bugs.python.org/issue34605]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)