If broker 1 is down in step 4, the producer will get a broken socket error
immediately. If broker 1 is up in step 4 and just the leader is moved
(e.g., due to preferred leader balancing), the producer will get an error
after the timeout specified in the producer request.
Thanks,
Jun
On Mon, Jun
Hi Michal,
Thanks for the perfect links. They really help. Now it looks like with
request.required.acks=1 (let alone 0) messages can be lost in the case I
described. The aphyr's article, seemingly, describes a more tricky case
than I have.
I'm still not sure on Kafka behavior in case of request.r
Hi Yury,
If I understand correctly, the case you're describing is equivalent to the
leader re-election (in terms of data consistency). In that case messages
can be lost depending on your "acks" setting:
https://kafka.apache.org/documentation.html
see: request.required.acks:
E.g. "only messages th
Thanks!
I'm also trying to understand how replicas will catch up once the leader
goes down. Say, we have 3 brokers with IDs 1, 2, 3. The leader is broker 1.
Followers are 2 and 3. Consider the following scenario assuming that all
messages fall into the same partition:
1. Producer sends message A
You don't gain much by running #4 between broker bounces. Running it after
the cluster is upgraded will be sufficient.
Thanks,
Neha
On Wed, Jun 18, 2014 at 8:33 AM, Yury Ruchin wrote:
> Hi folks,
>
> In my project, we want to perform to update our active Kafka 0.8 cluster to
> Kafka 0.8.1.1 wi
Hi folks,
In my project, we want to perform to update our active Kafka 0.8 cluster to
Kafka 0.8.1.1 without downtime and losing any data. The process (after
reading http://kafka.apache.org/documentation.html#upgrade) looks to me
like this. For each broker in turn:
1. Bring the broker down.
2. Upd
