DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
Update the functionality of
--release-versionflag to set reasonable defaults for the other feature versions known by the tool. Internally this will consist each feature having a mapping from metadata version to that version’s feature version. For example, if we input 3.8-IV2 that could map to TV1, 3.8-IV3 could also be TV1, and 3.8-IV3 IV4 could be TV2. There may be some scenarios where a MV doesn’t exist yet. In that case, we may create a MV to be used only by this tool in order to map to the new feature version.
...
| Code Block |
|---|
bin/kafka-storage.sh format --release-version 3.6-IVI --cluster-id=123456 // Gives the cluster all the versions that map to 3.6-IV1
bin/kafka-storage.sh format --features metadata.version=16,transaction.version=2,group.coordinator.version=1 --cluster-id=123456 // Gives the cluster metadata.version 16, transaction version 2, and group coordinator version 1
bin/kafka-storage.sh format --features metadata.version=16,transaction.version=2 --release-version 3.3-IV2 --cluster-id=123456 // Gives the cluster metadata.version 16, transaction version 2, and any other features map to 3.3-IV2
bin/kafka-storage.sh format --features transaction.version=2 --cluster-id=123456 // Given TV 2 is not known by the storage tool, throws error!
bin/kafka-storage.sh format --features group.coordinator.version=2 --release-version 3.3-IV2 --cluster-id=123456 // Given GCP2 requires MV 3.8-IV3, throws error!
bin/kafka-features.sh upgrade --feature transaction.version=2 // Sets the transaction version to 2
bin/kafka-features.sh upgrade --release-version 3.6-IVI // Upgrades all the features to versions that map to 3.6-IV1
bin/kafka-features.sh upgrade --feature transaction.version=2 --release-version 3.6-IVI // Throws error! |
...