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> > bin/kafka-topics.sh --zookeeper localhost:2181 --create --topic
my-topic --partitions 1
+<b> > 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> > bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic
my-topic
+<b> > 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> > bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic
my-topic
+<b> > 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.
