kafka-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhishek Agarwal <abhishc...@gmail.com>
Subject Re: Under-replicated Partitions while rolling Kafka nodes in AWS
Date Tue, 10 Jan 2017 11:38:44 GMT
FYI, DNS caching is still not fixed in 0.10. The zookeeper DNS cache has
been fixed for the zookeeper server where quorum members refresh the ip
address of their peers. But the client still doesn't do ip address refresh.

On Mon, Jan 9, 2017 at 9:56 PM, Jack Lund <jack.lund@braintreepayments.com>
wrote:

> On Thu, Jan 5, 2017 at 4:32 PM James Cheng <wushujames@gmail.com> wrote:
>
> >
> > FYI, zookeeper 3.4.8 fixes the issue where you have to restart zookeeper
> > nodes when their DNS mapping changes. I'm not sure how it affects
> > restarting kafka though, when the zookeeper DNS changes.
> >
> > https://zookeeper.apache.org/doc/r3.4.8/releasenotes.html <
> > https://zookeeper.apache.org/doc/r3.4.8/releasenotes.html>
> > https://issues.apache.org/jira/browse/ZOOKEEPER-1506 <
> > https://issues.apache.org/jira/browse/ZOOKEEPER-1506>
> >
> >
> Actually, the problem for us isn't zookeeper but Kafka, because the IP
> addresses for the zookeeper instances changes, and we have to update Kafka
> with the new ones.
>
> We chose not to have Kafka access the zookeeper nodes via DNS because we
> had issues with Kafka caching the DNS entries (IIRC) so we had to restart
> the kafka nodes anyway to get the changes (this was with, I believe, 0.8,
> so it's possible this is fixed in 0.10).
>
>
> > > What we've noticed is that, as the brokers are restarted, we get alerts
> > for
> > > under-replicated partitions, which seems strange since it seems like
> the
> > > shutdown process should take care of moving any replicas and the
> > leadership
> > > election process.
> > >
> >
> > During a controlled shutdown, you are right that *leadership* is moved
> > from one broker to another. But the replica list does not change. A topic
> > assigned to brokers 1 2 3 for example will only live on 1 2 3. If broker
> 1
> > is the leader for the topic, then during controlled shutdown of 1,
> > leadership may move to 2 or 3. But a broker 4 would never automatically
> > take over as replica for the topic.
> >
> > You can build such functionality yourself, if you wanted. You could, for
> > example, move the topic to 2 3 4 before shutting down 1, and then move it
> > back to 1 2 3 once 1 is back up. But that's a bunch of work you've have
> to
> > do yourself.
>
>
> We don't actually want this behavior, but we thought this would explain
> what we're seeing with the under-replicated partitions JMX metric. If the
> partitions aren't being moved (which makes sense), then it makes sense that
> it would claim that the partition is under-replicated, because, well, it
> is, at least briefly.
>
>
> >
> >
> -James
> >
> >
> Thanks!
>
> -Jack
>



-- 
Regards,
Abhishek Agarwal

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message