-
Notifications
You must be signed in to change notification settings - Fork 14.9k
KAFKA-15004: Fix configuration dual-write during migration #13767
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…we might miss updating configs or incorrectly update them in Zookeeper. Issue#1: Topic configs are not sycned while handling snapshot. Issue#2: Any broker or topic config resource that is new and not already present in Zookeeper will never be updated in Zookeeper. Issue#3: The senstive configs are not encoded while writing them to Zookeeper.
Add readTopicConfigs to ConfigMigrationClient
| topicClient.iterateTopics( | ||
| util.EnumSet.allOf(classOf[TopicVisitorInterest]), | ||
| new TopicVisitor() { | ||
| override def visitTopic(topicName: String, topicId: Uuid, assignments: util.Map[Integer, util.List[Integer]]): Unit = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just fixing the indentation here
| partitionRegistration.addingReplicas.foreach(brokerIdConsumer.accept(_)) | ||
| topicBatch.add(new ApiMessageAndVersion(record, 0.toShort)) | ||
| } | ||
| // This breaks the abstraction a bit, but the topic configs belong in the topic batch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not really required for the topic config records to come right after the topics. It would be OK to do it in a separate section as we do with snapshots.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was considering the fact that we don't atomically apply the migration records during the migration. I think it's possible for the controller or broker to publish the migration metadata before it's all committed. In this case, I think it's probably safer to include the config records with the topic batch.
This won't be an issue once we implement KIP-868.
metadata/src/main/java/org/apache/kafka/metadata/migration/KRaftMigrationZkWriter.java
Outdated
Show resolved
Hide resolved
cmccabe
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I left two minor comments but maybe we can address those in a follow-on if needed.
|
Got a reasonable test run: |
This patch fixes several small bugs with configuration dual-write during migration. * Topic configs are not written back to ZK while handling snapshot. * New broker/topic configs in KRaft that did not exist in ZK will not be written to ZK. * The sensitive configs are not encoded while writing them to Zookeeper. * Handle topic configs in ConfigMigrationClient and KRaftMigrationZkWriter#handleConfigsSnapshot Added tests to ensure we no longer have the above mentioned issues. Co-authored-by: Akhilesh Chaganti <[email protected]> Reviewers: Colin P. McCabe <[email protected]>
…tream-3.5 * commit 'c2f6f29ca6e1306ac77ec726bac4cd09bd1aa80b': (76 commits) KAFKA-15019: Improve handling of broker heartbeat timeouts (apache#13759) KAFKA-15003: Fix ZK sync logic for partition assignments (apache#13735) MINOR: Add 3.5 upgrade steps for ZK and KRaft (apache#13792) KAFKA-15010 ZK migration failover support (apache#13758) KAFKA-15017 Fix snapshot load in dual write mode for ClientQuotas and SCRAM (apache#13757) MINOR: Update LICENSE-binary following snappy upgrade (apache#13791) Upgrade to snappy v1.1.10.0 (apache#13786) KAFKA-15004: Fix configuration dual-write during migration (apache#13767) KAFKA-8713: JsonConverter replace.null.with.default should prevent emitting default for Struct fields (apache#13781) KAFKA-14996: Handle overly large user operations on the kcontroller (apache#13742) ...
This PR builds on top of #13736.
Fixes the following:
Added tests to ensure we no longer have the above mentioned issues.
Co-Authored-By: Akhilesh C [email protected]