From d39382d3e23bc4f6e3de239fe7b96c54a4aef490 Mon Sep 17 00:00:00 2001 From: Bill Bejeck Date: Sat, 31 Oct 2020 07:52:14 -0400 Subject: [PATCH] MINOR: Move upgraded docs from site to kafak docs (#9532) Reviewers: Matthias J. Sax --- docs/documentation.html | 43 +++++++------ docs/upgrade.html | 137 +++++++++++++++++++++++++++++++++++++--- 2 files changed, 151 insertions(+), 29 deletions(-) diff --git a/docs/documentation.html b/docs/documentation.html index 6b097b91312..bd0db3545d8 100644 --- a/docs/documentation.html +++ b/docs/documentation.html @@ -22,51 +22,56 @@
- -
- + +
+
<
+
+
+ +
+
+ +

Documentation

Kafka 2.8 Documentation

Prior releases: 0.7.x, 0.8.0, 0.8.1.X, 0.8.2.X, 0.9.0.X, 0.10.0.X, 0.10.1.X, 0.10.2.X, 0.11.0.X, 1.0.X, 1.1.X, 2.0.X, 2.1.X, 2.2.X, 2.3.X, 2.4.X, 2.5.X, 2.6.X, 2.7.X. - - -

1. Getting Started

-

1.1 Introduction

+

1. Getting Started

+

1.1 Introduction

-

1.2 Use Cases

+

1.2 Use Cases

-

1.3 Quick Start

- -

1.4 Ecosystem

+

1.3 Quick Start

+ +

1.4 Ecosystem

-

1.5 Upgrading From Previous Versions

+

1.5 Upgrading From Previous Versions

-

2. APIs

+

2. APIs

-

3. Configuration

+

3. Configuration

-

4. Design

+

4. Design

-

5. Implementation

+

5. Implementation

-

6. Operations

+

6. Operations

-

7. Security

+

7. Security

-

8. Kafka Connect

+

8. Kafka Connect

9. Kafka Streams

diff --git a/docs/upgrade.html b/docs/upgrade.html index 1c749d73ba3..a7e4bb58a61 100644 --- a/docs/upgrade.html +++ b/docs/upgrade.html @@ -21,6 +21,48 @@
Notable changes in 2.8.0
+

Upgrading to 2.7.0 from any version 0.8.x through 2.6.x

+ +

If you are upgrading from a version prior to 2.1.x, please see the note below about the change to the schema used to store consumer offsets. + Once you have changed the inter.broker.protocol.version to the latest version, it will not be possible to downgrade to a version prior to 2.1.

+ +

For a rolling upgrade:

+ +
    +
  1. Update server.properties on all brokers and add the following properties. CURRENT_KAFKA_VERSION refers to the version you + are upgrading from. CURRENT_MESSAGE_FORMAT_VERSION refers to the message format version currently in use. If you have previously + overridden the message format version, you should keep its current value. Alternatively, if you are upgrading from a version prior + to 0.11.0.x, then CURRENT_MESSAGE_FORMAT_VERSION should be set to match CURRENT_KAFKA_VERSION. + + If you are upgrading from version 0.11.0.x or above, and you have not overridden the message format, then you only need to override + the inter-broker protocol version. +
      +
    • inter.broker.protocol.version=CURRENT_KAFKA_VERSION (e.g., 2.6, 2.5, etc.)
      • +
    +
    2. +
  2. Upgrade the brokers one at a time: shut down the broker, update the code, and restart it. Once you have done so, the + brokers will be running the latest version and you can verify that the cluster's behavior and performance meets expectations. + It is still possible to downgrade at this point if there are any problems. +
    3. +
  3. Once the cluster's behavior and performance has been verified, bump the protocol version by editing + inter.broker.protocol.version and setting it to 2.7. +
    4. +
  4. Restart the brokers one by one for the new protocol version to take effect. Once the brokers begin using the latest + protocol version, it will no longer be possible to downgrade the cluster to an older version. +
    5. +
  5. If you have overridden the message format version as instructed above, then you need to do one more rolling restart to + upgrade it to its latest version. Once all (or most) consumers have been upgraded to 0.11.0 or later, + change log.message.format.version to 2.7 on each broker and restart them one by one. Note that the older Scala clients, + which are no longer maintained, do not support the message format introduced in 0.11, so to avoid conversion costs + (or to take advantage of exactly once semantics), + the newer Java clients must be used. +
    6. +
+
Notable changes in 2.7.0
+

Upgrading to 2.6.0 from any version 0.8.x through 2.5.x

-
Notable changes in 2.6.0
+

If you are upgrading from a version prior to 2.1.x, please see the note below about the change to the schema used to store consumer offsets. + Once you have changed the inter.broker.protocol.version to the latest version, it will not be possible to downgrade to a version prior to 2.1.

+ +

For a rolling upgrade:

+ +
    +
  1. Update server.properties on all brokers and add the following properties. CURRENT_KAFKA_VERSION refers to the version you + are upgrading from. CURRENT_MESSAGE_FORMAT_VERSION refers to the message format version currently in use. If you have previously + overridden the message format version, you should keep its current value. Alternatively, if you are upgrading from a version prior + to 0.11.0.x, then CURRENT_MESSAGE_FORMAT_VERSION should be set to match CURRENT_KAFKA_VERSION. + + If you are upgrading from version 0.11.0.x or above, and you have not overridden the message format, then you only need to override + the inter-broker protocol version. +
      +
    • inter.broker.protocol.version=CURRENT_KAFKA_VERSION (e.g., 2.5, 2.4, etc.)
      • +
    +
    2. +
  2. Upgrade the brokers one at a time: shut down the broker, update the code, and restart it. Once you have done so, the + brokers will be running the latest version and you can verify that the cluster's behavior and performance meets expectations. + It is still possible to downgrade at this point if there are any problems. +
    3. +
  3. Once the cluster's behavior and performance has been verified, bump the protocol version by editing + inter.broker.protocol.version and setting it to 2.6. +
    4. +
  4. Restart the brokers one by one for the new protocol version to take effect. Once the brokers begin using the latest + protocol version, it will no longer be possible to downgrade the cluster to an older version. +
    5. +
  5. If you have overridden the message format version as instructed above, then you need to do one more rolling restart to + upgrade it to its latest version. Once all (or most) consumers have been upgraded to 0.11.0 or later, + change log.message.format.version to 2.6 on each broker and restart them one by one. Note that the older Scala clients, + which are no longer maintained, do not support the message format introduced in 0.11, so to avoid conversion costs + (or to take advantage of exactly once semantics), + the newer Java clients must be used. +
    6. +
+ +
Notable changes in 2.6.0
  • Kafka Streams adds a new processing mode (requires broker 2.5 or newer) that improves application scalability using exactly-once guarantees @@ -114,17 +197,51 @@ Fetch requests and other requests intended only for the leader or follower return NOT_LEADER_OR_FOLLOWER(6) instead of REPLICA_NOT_AVAILABLE(9) if the broker is not a replica, ensuring that this transient error during reassignments is handled by all clients as a retriable exception.
    • -
  • There are several notable changes to the reassignment tool kafka-reassign-partitions.sh - following the completion of - KIP-455. - This tool now requires the --additional flag to be provided when changing the throttle of an - active reassignment. Reassignment cancellation is now possible using the - --cancel command. Finally, reassignment with --zookeeper - has been deprecated in favor of --bootstrap-server. See the KIP for more detail. -
-
Notable changes in 2.5.0
+

Upgrading to 2.5.0 from any version 0.8.x through 2.4.x

+ +

If you are upgrading from a version prior to 2.1.x, please see the note below about the change to the schema used to store consumer offsets. + Once you have changed the inter.broker.protocol.version to the latest version, it will not be possible to downgrade to a version prior to 2.1.

+ +

For a rolling upgrade:

+ +
    +
  1. Update server.properties on all brokers and add the following properties. CURRENT_KAFKA_VERSION refers to the version you + are upgrading from. CURRENT_MESSAGE_FORMAT_VERSION refers to the message format version currently in use. If you have previously + overridden the message format version, you should keep its current value. Alternatively, if you are upgrading from a version prior + to 0.11.0.x, then CURRENT_MESSAGE_FORMAT_VERSION should be set to match CURRENT_KAFKA_VERSION. + + If you are upgrading from version 0.11.0.x or above, and you have not overridden the message format, then you only need to override + the inter-broker protocol version. +
      +
    • inter.broker.protocol.version=CURRENT_KAFKA_VERSION (e.g., 2.4, 2.3, etc.)
      • +
    +
    2. +
  2. Upgrade the brokers one at a time: shut down the broker, update the code, and restart it. Once you have done so, the + brokers will be running the latest version and you can verify that the cluster's behavior and performance meets expectations. + It is still possible to downgrade at this point if there are any problems. +
    3. +
  3. Once the cluster's behavior and performance has been verified, bump the protocol version by editing + inter.broker.protocol.version and setting it to 2.5. +
    4. +
  4. Restart the brokers one by one for the new protocol version to take effect. Once the brokers begin using the latest + protocol version, it will no longer be possible to downgrade the cluster to an older version. +
    5. +
  5. If you have overridden the message format version as instructed above, then you need to do one more rolling restart to + upgrade it to its latest version. Once all (or most) consumers have been upgraded to 0.11.0 or later, + change log.message.format.version to 2.5 on each broker and restart them one by one. Note that the older Scala clients, + which are no longer maintained, do not support the message format introduced in 0.11, so to avoid conversion costs + (or to take advantage of exactly once semantics), + the newer Java clients must be used. +
    6. +
+ +
Notable changes in 2.5.0
  • When RebalanceProtocol#COOPERATIVE is used, Consumer#poll can still return data while it is in the middle of a rebalance for those partitions still owned by the consumer; in addition