kafka-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jun...@apache.org
Subject svn commit: r1671461 - in /kafka/site/083: configuration.html upgrade.html
Date Mon, 06 Apr 2015 00:38:03 GMT
Author: junrao
Date: Mon Apr  6 00:38:03 2015
New Revision: 1671461

URL: http://svn.apache.org/r1671461
Log:
update new 0.8.3 config inter.broker.protocol.version and upgrade path

Modified:
    kafka/site/083/configuration.html
    kafka/site/083/upgrade.html

Modified: kafka/site/083/configuration.html
URL: http://svn.apache.org/viewvc/kafka/site/083/configuration.html?rev=1671461&r1=1671460&r2=1671461&view=diff
==============================================================================
--- kafka/site/083/configuration.html (original)
+++ kafka/site/083/configuration.html Mon Apr  6 00:38:03 2015
@@ -431,29 +431,34 @@ ZooKeeper also allows you to add a "chro
       <td>5000</td>
       <td>The offset commit will be delayed until this timeout or the required number
of replicas have received the offset commit. This is similar to the producer request timeout.</td>
     </tr>
+    <tr>
+      <td>inter.broker.protocol.version</td>
+      <td>0.8.3</td>
+      <td>Version of the protocol brokers will use to communicate with each other.
This will default for the current version of the broker, but may need to be set to older versions
during a rolling upgrade process. In that scenario, upgraded brokers will use the older version
of the protocol and therefore will be able to communicate with brokers that were not yet upgraded.
See <a href="#upgrade">upgrade section</a> for more details.</td>
+    </tr>
 </tbody></table>
 
 <p>More details about broker configuration can be found in the scala class <code>kafka.server.KafkaConfig</code>.</p>
 
 <h4><a id="topic-config">Topic-level configuration</a></h3>
-    
+
 Configurations pertinent to topics have both a global default as well an optional per-topic
override. If no per-topic configuration is given the global default is used. The override
can be set at topic creation time by giving one or more <code>--config</code>
options. This example creates a topic named <i>my-topic</i> with a custom max
message size and flush rate:
 <pre>
-<b> &gt; bin/kafka-topics.sh --zookeeper localhost:2181 --create --topic my-topic
--partitions 1 
+<b> &gt; bin/kafka-topics.sh --zookeeper localhost:2181 --create --topic my-topic
--partitions 1
         --replication-factor 1 --config max.message.bytes=64000 --config flush.messages=1</b>
 </pre>
 Overrides can also be changed or set later using the alter topic command. This example updates
the max message size for <i>my-topic</i>:
 <pre>
-<b> &gt; bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic my-topic

+<b> &gt; bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic my-topic
     --config max.message.bytes=128000</b>
 </pre>
 
 To remove an override you can do
 <pre>
-<b> &gt; bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic my-topic

+<b> &gt; bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic my-topic
     --deleteConfig max.message.bytes</b>
 </pre>
-    
+
 The following are the topic-level configurations. The server's default configuration for
this property is given under the Server Default Property heading, setting this default in
the server config allows you to change the default given to topics that have no override specified.
 <table class="data-table">
 <tbody>
@@ -745,7 +750,7 @@ Essential configuration properties for t
       <td>request.required.acks</td>
       <td colspan="1">0</td>
       <td>
-        <p>This value controls when a produce request is considered completed. Specifically,
how many other brokers must have committed the data to their log and acknowledged this to
the leader? Typical values are 
+        <p>This value controls when a produce request is considered completed. Specifically,
how many other brokers must have committed the data to their log and acknowledged this to
the leader? Typical values are
            <ul>
              <li>0, which means that the producer never waits for an acknowledgement
from the broker (the same behavior as 0.7). This option provides the lowest latency but the
weakest durability guarantees (some data will be lost when a server fails).
              <li> 1, which means that the producer gets an acknowledgement after the
leader replica has received the data. This option provides better durability as the client
waits until the server acknowledges the request as successful (only messages that were written
to the now-dead leader but not yet replicated will be lost).

Modified: kafka/site/083/upgrade.html
URL: http://svn.apache.org/viewvc/kafka/site/083/upgrade.html?rev=1671461&r1=1671460&r2=1671461&view=diff
==============================================================================
--- kafka/site/083/upgrade.html (original)
+++ kafka/site/083/upgrade.html Mon Apr  6 00:38:03 2015
@@ -1,5 +1,19 @@
 <h3><a id="upgrade">1.5 Upgrading From Previous Versions</a></h3>
 
+<h4>Upgrading from 0.8.0, 0.8.1.X or 0.8.2.X to 0.8.3.0</h4>
+
+0.8.3.0 has an inter-broker protocol change from previous versions. For a rolling upgrade:
+<ol>
+	<li> Update server.properties file on all brokers and add the following property:
inter.broker.protocol.version=0.8.2.X </li>
+	<li> Upgrade the brokers. This can be done a broker at a time by simply bringing it
down, updating the code, and restarting it. </li>
+	<li> Once the entire cluster is upgraded, bump the protocol version by editing inter.broker.protocol.version
and setting it to 0.8.3.0.</li>
+	<li> Restart the brokers one by one for the new protocol version to take effect </li>
+</ol>
+
+Note: If you are willing to accept downtime, you can simply take all the brokers down, update
the code and start all of them. They will start with the new protocol by default.
+
+Note: Bumping the protocol version and restarting can be done any time after the brokers
were upgraded. It does not have to be immediately after.
+
 <h4>Upgrading from 0.8.1 to 0.8.2.0</h4>
 
 0.8.2.0 is fully compatible with 0.8.1. The upgrade can be done one broker at a time by simply
bringing it down, updating the code, and restarting it.



Mime
View raw message