root
/
kafka
mirror of https://github.com/apache/kafka.git
1
0
Fork 0
Code Issues Actions 2 Packages Projects Releases Wiki Activity

KAFKA-7413: Replace slave terminology with follower in documentation (#5653) 

Reviewers: John Roesler <john@confluent.io>, Ryanne Dolan, Ismael Juma <ismael@juma.me.uk>
This commit is contained in:
Sayat 2018-10-29 06:12:42 +01:00 committed by Ismael Juma
parent b4722cc16f
commit eede70a805
2 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/design.html
View File

@ -286,7 +286,7 @@
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&mdash;in fact we implement un-replicated topics as replicated topics where the
replication factor is one.
<p>
@ -300,7 +300,7 @@
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 @@
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>,

2
docs/quickstart.html
View File

@ -192,7 +192,7 @@ ProcessId
&gt; 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;">
&gt; bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic