Skip to content

Conversation

@akhileshchg
Copy link
Contributor

…ot update TopicIdReplicaAssignment during migration (DUAL_WRITE).

Fixed the metadata change events in the Migration component to check correctly for the diff in existing topic changes and replicate the metadata to the Zookeeper. Also, made the diff check exhaustive enough to handle the partial writes in Zookeeper when we're try to replicate changes using a snapshot in the event of Controller failover.

Add migration client and integration tests to verify the change.

…ot update TopicIdReplicaAssignment during migration (DUAL_WRITE).

Fixed the metadata change events in the Migration component to check correctly
for the diff in existing topic changes and replicate the metadata to the
Zookeeper. Also, made the diff check exhaustive enough to handle the partial
writes in Zookeeper when we're try to replicate changes using a snapshot in the
event of Controller failover.

Add migration client and integration tests to verify the change.
@akhileshchg akhileshchg marked this pull request as ready for review May 19, 2023 18:31
Copy link
Member

@mumrah mumrah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great catch @akhileshchg! Looks like we had some gaps in topic/partition metadata even beyond the snapshot handling.

Left some comments inline

Comment on lines 164 to 165
newPartitions.put(topicId, newTopicPartitions);
changedTopics.add(topicId);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's possible that we can see a difference between topicPartitionsInZk (computed based on the partition znodes) and the topic assignment in Kraft, but actually have a correct assignment in ZK (stored in the topic znode). That said, I don't think there's any harm in re-writing the kraft assignment to ZK.

@mumrah mumrah self-assigned this May 22, 2023
@mumrah mumrah added the kraft label May 22, 2023
val (migrationZkVersion, responses) = zkClient.retryMigrationRequestsUntilConnected(requests, state)
val resultCodes = responses.map { response => response.path -> response.resultCode }.toMap
if (resultCodes(TopicZNode.path(topicName)).equals(Code.NODEEXISTS)) {
// topic already created, just return
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this read "partition already created"?

@cmccabe
Copy link
Contributor

cmccabe commented May 31, 2023

Do we handle the case where # of partitions decreased?

How do we handle changes to the partition znodes? Looks like we catch EEXIST in a bunch of cases, do we follow up to see that it has the right stuff in there?

@akhileshchg
Copy link
Contributor Author

akhileshchg commented May 31, 2023 via email

@mumrah
Copy link
Member

mumrah commented May 31, 2023

@akhileshchg there's a case where a topic is deleted and re-created with fewer partitions. Since ZK indexes topics by name, we can't readily see if the deletion happened when processing a KRaft snapshot. I added logic to handle the case of unexpected partitions in ZK.

Copy link
Contributor

@cmccabe cmccabe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

return builder.toString();
}

public boolean hasSameAssignment(PartitionRegistration registration) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be equals. I'll fix it

cmccabe pushed a commit that referenced this pull request Jun 1, 2023
Fixed the metadata change events in the Migration component to check correctly for the diff in
existing topic changes and replicate the metadata to the Zookeeper. Also, made the diff check
exhaustive enough to handle the partial writes in Zookeeper when we're try to replicate changes
using a snapshot in the event of Controller failover.

Add migration client and integration tests to verify the change.

Co-authored-by: Akhilesh Chaganti <[email protected]>
cmccabe pushed a commit that referenced this pull request Jun 1, 2023
Fixed the metadata change events in the Migration component to check correctly for the diff in
existing topic changes and replicate the metadata to the Zookeeper. Also, made the diff check
exhaustive enough to handle the partial writes in Zookeeper when we're try to replicate changes
using a snapshot in the event of Controller failover.

Add migration client and integration tests to verify the change.

Co-authored-by: Akhilesh Chaganti <[email protected]>
@cmccabe
Copy link
Contributor

cmccabe commented Jun 1, 2023

committed

@cmccabe cmccabe closed this Jun 1, 2023
emissionnebula added a commit to confluentinc/kafka that referenced this pull request Jun 16, 2023
…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)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants