[
https://issues.apache.org/jira/browse/KAFKA-21252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated KAFKA-21252:
-----------------------------------
Description:
{code:java}
val proposedAssignmentForNewPartitions = replicaAssignment.getOrElse {
val startIndex = math.max(0, allBrokers.indexWhere(_.id >=
existingAssignmentPartition0.head))
CoreUtils.replicaToBrokerAssignmentAsScala(AdminUtils.assignReplicasToBrokers(allBrokers.asJava,
partitionsToAdd, existingAssignmentPartition0.size,
startIndex, existingAssignment.size))
} {code}
The zk broker picks partition 0’s replicas for the newly created partitions.
{code:java}
Iterator<PartitionRegistration> iterator =
topicInfo.parts.values().iterator();
if (!iterator.hasNext()) {
throw new UnknownServerException("Invalid state: topic " +
topic.name() +
" appears to have no partitions.");
} {code}
By contrast, the kraft broker picks the "first" partition, but the "first"
depends on the hash slot layout. Hence, it is unpredictable to users :(
It can be fixed simply by replacing the `.next` to `parts.get(0)` :)
was:
/**
* Increase the partition count for a topic to the given \{@code
totalCount}.
* The assignment of new replicas to brokers will be decided by the broker.
*
* @param totalCount The total number of partitions after the operation
succeeds.
*/
public static NewPartitions increaseTo(int totalCount) {
return new NewPartitions(totalCount, null);
}
We don't define the behavior if the replicas of different partitions is not
identical. What the number of replicas will be created by this method? I guess
it depends on the first partition, but I haven't checked that from source code
> NewPartitions#increaseTo no longer follows partition 0’s replication factor
> in KRaft mode
> -----------------------------------------------------------------------------------------
>
> Key: KAFKA-21252
> URL: https://issues.apache.org/jira/browse/KAFKA-21252
> Project: Kafka
> Issue Type: Improvement
> Reporter: Chia-Ping Tsai
> Assignee: Chia-Ping Tsai
> Priority: Minor
>
> {code:java}
> val proposedAssignmentForNewPartitions = replicaAssignment.getOrElse {
> val startIndex = math.max(0, allBrokers.indexWhere(_.id >=
> existingAssignmentPartition0.head))
>
> CoreUtils.replicaToBrokerAssignmentAsScala(AdminUtils.assignReplicasToBrokers(allBrokers.asJava,
> partitionsToAdd, existingAssignmentPartition0.size,
> startIndex, existingAssignment.size))
> } {code}
> The zk broker picks partition 0’s replicas for the newly created partitions.
> {code:java}
> Iterator<PartitionRegistration> iterator =
> topicInfo.parts.values().iterator();
> if (!iterator.hasNext()) {
> throw new UnknownServerException("Invalid state: topic " +
> topic.name() +
> " appears to have no partitions.");
> } {code}
> By contrast, the kraft broker picks the "first" partition, but the "first"
> depends on the hash slot layout. Hence, it is unpredictable to users :(
> It can be fixed simply by replacing the `.next` to `parts.get(0)` :)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
