You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@kafka.apache.org by li...@apache.org on 2018/11/09 23:45:24 UTC

[kafka-site] branch asf-site updated: Update docs for 2.1.0 RC1 (#168)

This is an automated email from the ASF dual-hosted git repository.

lindong pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/kafka-site.git


The following commit(s) were added to refs/heads/asf-site by this push:
     new d48694d  Update docs for 2.1.0 RC1 (#168)
d48694d is described below

commit d48694d81911ba802f3ea008c3ed72e071e651ac
Author: Dong Lin <li...@gmail.com>
AuthorDate: Fri Nov 9 15:45:20 2018 -0800

    Update docs for 2.1.0 RC1 (#168)
---
 21/.upgrade.html.swp          | Bin 118784 -> 0 bytes
 21/streams/upgrade-guide.html |   6 +++---
 21/upgrade.html               |  45 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/21/.upgrade.html.swp b/21/.upgrade.html.swp
deleted file mode 100644
index ad08ac6..0000000
Binary files a/21/.upgrade.html.swp and /dev/null differ
diff --git a/21/streams/upgrade-guide.html b/21/streams/upgrade-guide.html
index e79b106..7fecfeb 100644
--- a/21/streams/upgrade-guide.html
+++ b/21/streams/upgrade-guide.html
@@ -112,14 +112,14 @@
     </p>
 
     <p>
-        We updated a list of methods that take <code>long</long> arguments as either timestamp (fix point) or duration (time period)
+        We updated a list of methods that take <code>long</code> arguments as either timestamp (fix point) or duration (time period)
         and replaced them with <code>Instant</code> and <code>Duration</code> parameters for improved semantics.
         Some old methods base on <code>long</code> are deprecated and users are encouraged to update their code.
         <br />
         In particular, aggregation windows (hopping/tumbling/unlimited time windows and session windows) as well as join windows now take <code>Duration</code>
         arguments to specify window size, hop, and gap parameters.
         Also, window sizes and retention times are now specified as <code>Duration</code> type in <code>Stores</code> class.
-        The <code>Window</code> class has new methods <code>#startTime()</code> and <code>#endTime</code> that return window start/end timestamp as <code>Instant</code>.
+        The <code>Window</code> class has new methods <code>#startTime()</code> and <code>#endTime()</code> that return window start/end timestamp as <code>Instant</code>.
         For interactive queries, there are new <code>#fetch(...)</code> overloads taking <code>Instant</code> arguments.
         Additionally, punctuations are now registerd via <code>ProcessorContext#schedule(Duration interval, ...)</code>.
         For more details, see <a href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-358%3A+Migrate+Streams+API+to+Duration+instead+of+long+ms+times">KIP-358</a>.
@@ -127,7 +127,7 @@
 
     <p>
         We deprecated <code>KafkaStreams#close(...)</code> and replaced it with <code>KafkaStreams#close(Duration)</code> that accepts a single timeout argument
-        Note: the new <code>#close</code> method has improved (but slightly different) semantics than the old one.
+        Note: the new <code>#close(Duration)</code> method has improved (but slightly different) semantics.
         For more details, see <a href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-358%3A+Migrate+Streams+API+to+Duration+instead+of+long+ms+times">KIP-358</a>.
     </p>
 
diff --git a/21/upgrade.html b/21/upgrade.html
index f879ae3..33d9964 100644
--- a/21/upgrade.html
+++ b/21/upgrade.html
@@ -20,6 +20,47 @@
 <script id="upgrade-template" type="text/x-handlebars-template">
 
 <h4><a id="upgrade_2_1_0" href="#upgrade_2_1_0">Upgrading from 0.8.x, 0.9.x, 0.10.0.x, 0.10.1.x, 0.10.2.x, 0.11.0.x, 1.0.x, 1.1.x, or 2.0.0 to 2.1.0</a></h4>
+
+<p><b>Note that 2.1.x contains a change to the internal schema used to store consumer offsets. Once the upgrade is
+  complete, it will not be possible to downgrade to previous versions. See the rolling upgrade notes below for more detail.</b></p>
+
+<p><b>For a rolling upgrade:</b></p>
+
+<ol>
+    <li> 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.
+        <ul>
+            <li>inter.broker.protocol.version=CURRENT_KAFKA_VERSION (e.g. 0.8.2, 0.9.0, 0.10.0, 0.10.1, 0.10.2, 0.11.0, 1.0, 1.1).</li>
+            <li>log.message.format.version=CURRENT_MESSAGE_FORMAT_VERSION  (See <a href="#upgrade_10_performance_impact">potential performance impact
+                following the upgrade</a> for the details on what this configuration does.)</li>
+        </ul>
+        If you are upgrading from 0.11.0.x, 1.0.x, 1.1.x, or 2.0.x and you have not overridden the message format, then you only need to override
+        the inter-broker protocol version.
+        <ul>
+            <li>inter.broker.protocol.version=CURRENT_KAFKA_VERSION (0.11.0, 1.0, 1.1, 2.0).</li>
+        </ul>
+    </li>
+    <li> 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. 
+    </li>
+    <li> Once the cluster's behavior and performance has been verified, bump the protocol version by editing
+        <code>inter.broker.protocol.version</code> and setting it to 2.1.
+    </li>
+    <li> 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.
+    </li>
+    <li> 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.1 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 <a href="#upgrade_11_exactly_once_semantics">exactly once semantics</a>),
+        the newer Java clients must be used.
+    </li>
+</ol>
+
 <p><b>Additional Upgrade Notes:</b></p>
 
 <ol>
@@ -39,6 +80,10 @@
         you will instead need to override <code>delivery.timeout.ms</code>.</li>
     <li>The <code>ListGroup</code> API now expects, as a recommended alternative, <code>Describe Group</code> access to the groups a user should be able to list.
         Even though the old <code>Describe Cluster</code> access is still supported for backward compatibility, using it for this API is not advised.</li>
+    <li><a href="https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=87298242">KIP-336</a> deprecates the ExtendedSerializer and ExtendedDeserializer interfaces and
+        propagates the usage of Serializer and Deserializer. ExtendedSerializer and ExtendedDeserializer were introduced with
+        <a href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-82+-+Add+Record+Headers">KIP-82</a> to provide record headers for serializers and deserializers
+        in a Java 7 compatible fashion. Now we consolidated these interfaces as Java 7 support has been dropped since.</li>
 </ol>
 
 <h5><a id="upgrade_210_notable" href="#upgrade_210_notable">Notable changes in 2.1.0</a></h5>