[
https://issues.apache.org/jira/browse/KAFKA-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671625#comment-16671625
]
点儿郎当 commented on KAFKA-7481:
-----------------------------
kafka version1.0
[2018-11-01 21:37:26,250] ERROR [Controller id=13 epoch=8] Initiated state
change for partition
topic.cloud.service.bigdata.news_contents_submits_stats.content-6 from
OnlinePartition to OnlinePartition failed (state.change.logger)
kafka.common.StateChangeFailedException: [Controller id=13 epoch=8] Encountered
error while electing leader for partition
topic.cloud.service.bigdata.news_contents_submits_stats.content-6 due to:
Preferred replica 12 for partition
topic.cloud.service.bigdata.news_contents_submits_stats.content-6 is either not
alive or not in the isr. Current leader and ISR:
[{"leader":13,"leader_epoch":74,"isr":[13]}]
at
kafka.controller.PartitionStateMachine.electLeaderForPartition(PartitionStateMachine.scala:324)
How did it happen?How to solve?
coding
def selectLeader(topicAndPartition: TopicAndPartition,
currentLeaderAndIsr: LeaderAndIsr): (LeaderAndIsr, Seq[Int])
= {
val assignedReplicas =
controllerContext.partitionReplicaAssignment(topicAndPartition)
val preferredReplica = assignedReplicas.head
// check if preferred replica is the current leader
val currentLeader =
controllerContext.partitionLeadershipInfo(topicAndPartition).leaderAndIsr.leader
if (currentLeader == preferredReplica) {
throw new LeaderElectionNotNeededException("Preferred replica %d is
already the current leader for partition %s"
.format(preferredReplica,
topicAndPartition))
} else {
info("Current leader %d for partition %s is not the preferred
replica.".format(currentLeader, topicAndPartition) +
" Triggering preferred replica leader election")
// check if preferred replica is not the current leader and is alive and
in the isr
if (controllerContext.isReplicaOnline(preferredReplica,
topicAndPartition) && currentLeaderAndIsr.isr.contains(preferredReplica)) {
val newLeaderAndIsr = currentLeaderAndIsr.newLeader(preferredReplica)
(newLeaderAndIsr, assignedReplicas)
} else {
throw new StateChangeFailedException(s"Preferred replica
$preferredReplica for partition $topicAndPartition " +
s"is either not alive or not in the isr. Current leader and ISR:
[$currentLeaderAndIsr]")
}
}
> Consider options for safer upgrade of offset commit value schema
> ----------------------------------------------------------------
>
> Key: KAFKA-7481
> URL: https://issues.apache.org/jira/browse/KAFKA-7481
> Project: Kafka
> Issue Type: Bug
> Reporter: Jason Gustafson
> Priority: Blocker
> Fix For: 2.1.0
>
>
> KIP-211 and KIP-320 add new versions of the offset commit value schema. The
> use of the new schema version is controlled by the
> `inter.broker.protocol.version` configuration. Once the new inter-broker
> version is in use, it is not possible to downgrade since the older brokers
> will not be able to parse the new schema.
> The options at the moment are the following:
> 1. Do nothing. Users can try the new version and keep
> `inter.broker.protocol.version` locked to the old release. Downgrade will
> still be possible, but users will not be able to test new capabilities which
> depend on inter-broker protocol changes.
> 2. Instead of using `inter.broker.protocol.version`, we could use
> `message.format.version`. This would basically extend the use of this config
> to apply to all persistent formats. The advantage is that it allows users to
> upgrade the broker and begin using the new inter-broker protocol while still
> allowing downgrade. But features which depend on the persistent format could
> not be tested.
> Any other options?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
