KAFKA-3852: Clarify how to handle message format upgrade without kill… #1678
Conversation
docs/upgrade.html
Outdated
| <li> Update server.properties file on all brokers and add the following properties: | ||
| <ul> | ||
| <li>inter.broker.protocol.version=CURRENT_KAFKA_VERSION (e.g. 0.8.2 or 0.9.0.0).</li> | ||
| <li>log.message.format.version=CURRENT_KAFKA_VERSION (This is optional, but strongly recommended to ensure that Kafka cluster performance doesn't drop following the upgrade. See <a href="#upgrade_10_performance_impact">potential performance impact following the upgrade</a> for the details.) |
There was a problem hiding this comment.
It turns out that this is not optional (see KAFKA-3827), so we can remove that text for now.
docs/upgrade.html
Outdated
| To avoid such message conversion before consumers are upgraded to 0.10.0.0, one can set the message format to | ||
| e.g. 0.9.0 when upgrading the broker to 0.10.0.0. This way, the broker can still use zero-copy transfer to send the | ||
| data to the old consumers. Once most consumers are upgraded, one can change the message format to 0.10.0 on the broker. | ||
| The effects of this conversion on a broker following the upgrade are quite significant. There has been reports in the Kafka community of brokers going from 20% cpu utilization to 100% utilization following the upgrade. Requiring an emergency upgrade of all the clients to bring performance back to normal. |
There was a problem hiding this comment.
There has been -> There have been
cpu -> CPU
The sentence starting with "Requiring" is a fragment.
Or just change it to something like "Reports from the Kafka community on the performance impact have shown CPU utilization going from 20% before to 100% after an upgrade and forced an immediate upgrade of all clients to bring performance back to normal."
Might make sense to add a final sentence with something like "The conversion is supported to ensure compatibility and can be useful to support a few apps that have not updated to newer clients yet, but is impractical to support all consumer traffic on even an overprovisioned cluster. Therefore it is critical to avoid the message conversion during the upgrade."
|
@gwenshap just one small area that i think needs tweaking, but otherwise LGTM |
docs/upgrade.html
Outdated
| To avoid such message conversion before consumers are upgraded to 0.10.0.0, one can set log.message.format.version to 0.8.2 or 0.9.0 when upgrading the broker to 0.10.0.0. This way, the broker can still use zero-copy transfer to send the data to the old consumers. Once consumers are upgraded, one can change the message format to 0.10.0 on the broker and enjoy the new message format that includes new timestamp and improved compression. | ||
|
|
||
| The conversion is supported to ensure compatibility and can be useful to support a few apps that have not updated to newer clients yet, but is impractical to support all consumer traffic on even an overprovisioned cluster. Therefore it is critical to avoid the message conversion as much as possible when brokers have been upgraded but the majority of clients have not. | ||
| . |
There was a problem hiding this comment.
random extra . here. could be cleaned up during commit
There was a problem hiding this comment.
so clean up and commit? :)
|
LGTM, just left a very minor comment. |
|
LGTM, thanks @gwenshap |
…ing performance …ing performance Author: Gwen Shapira <cshapi@gmail.com> Reviewers: Ismael Juma <ismael@juma.me.uk>, Ewen Cheslack-Postava <ewen@confluent.io> Closes #1678 from gwenshap/kafka-3852 (cherry picked from commit 071b76c) Signed-off-by: Ewen Cheslack-Postava <me@ewencp.org>
3 participants
…ing performance