[
https://issues.apache.org/jira/browse/KAFKA-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663274#comment-16663274
]
Dong Lin commented on KAFKA-7481:
---------------------------------
Hey [~ewencp], regarding the change for 2.1.0 release, say we don't make
further code change for this issue, I agree it is good to clarify in the
upgrade note that inter.broker.protocol.version can not be reverted after it is
bumped to 2.1.0.
Regarding the short term solution, I also prefer not to make big code change to
e.g. use KIP-35 idea to solve the issue here. I would prefer to just clarify in
the upgrade note that inter.broker.protocol.version can not be reverted after
it is bumped to 2.1.0. Also, since we currently do not mention anything about
downgrade in the upgrade note, and the other config log.message.format.version
can not be downgraded, I am not sure user actually expect to be able to
downgrade the inter.broker.protocol. So I feel this short term solution is OK
and strictly speaking it does not break any semantic guarantee.
Regarding the long term solution, it seems that we actually want user to
manually manage the protocol version config in order to pickup any new feature
that can change the data format on disk. Otherwise, say we always make things
work with one rolling bounce, then whenever there is feature that change data
format on disk, we will have to bump up the major version for the next Kafka
release to indicate that the version can not be downgraded, which delays the
acceptance for the release. Also, if we automatically bump up the
message.format.version for the new broker version, the broker performance will
downgrade so much because user wont' even have time upgrade client library
version for most users in the organization.
> 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)
