[
https://issues.apache.org/jira/browse/KAFKA-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16662610#comment-16662610
]
Dong Lin commented on KAFKA-7481:
---------------------------------
After reading through the discussion and thinking through the problem more, I
have the following alternative solution.
Basically we have the following three catagories of features:
1) Features that require only the protocol change. These features can be rolled
back.
2) Features that require both the protocol and disk format change without
having performance impact. These features can not be rolled back.
3) Features that require both the protocol and disk format change and have
performance impact. These features can not be rolled back.
My proposed solution is to this:
1) For features that require only the protocol change, let broker automatically
detect the protocol version (e.g. KIP-35) as the lower version of the two
brokers in communication instead of controlling the version explicitly using
inter.broker.protocol.version.
2) For features that require both the protocol and disk format change without
having performance impact, the version can be specified explicitly using the
existing inter.broker.protocol.version config. And we tell user that this
config can not be rolled back after it is bumped.
3) For features that require both the protocol and disk format change and have
performance impact, the version will be specified explicitly using
message.format.version as we are currently doing. There is no change in this
category.
This solution does not increase config or the testing surface area which meet
the goal of Ismael. And this solution also minimizes the cases in which we do
not allow broker version downgrade which meet the goal of Jason and Ewen. One
additional benefit, as mentioned by Ewen with KIP-35, is that for features that
require only the protocol change, which is the common case, user only need one
rolling bounce to pick up the feature.
Does this sound good?
> 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)
