You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by GitBox <gi...@apache.org> on 2021/05/19 05:19:58 UTC

[GitHub] [kafka] dajac commented on pull request #10326: Avoid newly replicating brokers in RackAwareReplicaSelector

dajac commented on pull request #10326:
URL: https://github.com/apache/kafka/pull/10326#issuecomment-843754057


   @lizthegrey Please, excuse me for the delay on this one. I did not have the time to really look into it.
   
   At the moment, it is not clear to me that the PR actually solves the problem that you hit. The part which bugs me a bit is the following one.
   
   If you look at the [code](https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/server/ReplicaManager.scala#L1260) which selects the read replica, it only selects the follower replicas which have the requested fetch offset. My understanding is that the consumer was requesting an offset that the newly added replica did not have yet. Therefore, when the consumer was restarted, the broker should NOT have selected the newly added replica. If it did, I wonder how that could have happened.
   
   Do you see any incidences in the logs that the consumer got a preferred read replica from the leader?
   
   I wonder if the unclean leader election played a role into this. Would you have logs (controller, state changes, etc.) for that partition during that time?
   
   We need to reconstruct the sequence of events to better understand the case.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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