[
https://issues.apache.org/jira/browse/KAFKA-18212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904906#comment-17904906
]
Chia-Ping Tsai commented on KAFKA-18212:
----------------------------------------
{quote}
If we think it is important to avoid rebalance on 2-broker clusters during
rolling restart, we could always wait for the trigger interval, which is
configurable any way.
{quote}
In fact, the side effect we have observed is that unnecessary rebalancing is
triggered by the classic consumer. Additionally, this occurs only when there
are no available nodes. Therefore, it is perfectly acceptable to adjust the
end-to-end (e2e) tests to disable the rebootstrap policy - we don't need to
introduce changes to production code.
I will close this jira after KAFKA-18194 gets fixed.
> Rolling-upgrade broker causes unnecessary re-balance on classic consumer
> ------------------------------------------------------------------------
>
> Key: KAFKA-18212
> URL: https://issues.apache.org/jira/browse/KAFKA-18212
> Project: Kafka
> Issue Type: Bug
> Reporter: Chia-Ping Tsai
> Assignee: Chia-Ping Tsai
> Priority: Blocker
>
> KAFKA-17885 sets the rebootstrap policy by default and introduces
> metadata.recovery.rebootstrap.trigger.ms to control the rebootstrap interval.
> However, DefaultMetadataUpdater#maybeUpdate [0] does not honor
> metadata.recovery.rebootstrap.trigger.ms and triggers a rebootstrap when no
> node is available. This causes the metadata to be reset during rolling
> upgrades of brokers, leading the classic consumer [1] to send a rejoin
> request due to the metadata change.
> [0]
> https://github.com/apache/kafka/blob/7591868aead54fff7d5e8a44c5e06746ed34866b/clients/src/main/java/org/apache/kafka/clients/NetworkClient.java#L1230
> [1]
> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerCoordinator.java#L883
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
