Index: 08/quickstart.html =================================================================== --- 08/quickstart.html (revision 1563565) +++ 08/quickstart.html (working copy) @@ -37,18 +37,18 @@ Now start the Kafka server: Let's create a topic named "test" with a single partition and only one replica: 
-> bin/kafka-create-topic.sh --zookeeper localhost:2181 --replica 1 --partition 1 --topic test
+> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
We can now see that topic if we run the list topic command: 
-> bin/kafka-list-topic.sh --zookeeper localhost:2181
+> bin/kafka-topics.sh --list --zookeeper localhost:2181
Alternatively, you can also configure your brokers to auto-create topics when a non-existent topic is published to.

Step 4: Send some messages

-Kafka comes with a command line client that will take input from a file or standard in and send it out as messages to the Kafka cluster. By default each line will be sent as a separate message. +Kafka comes with a command line client that will take input from a file or standard input and send it out as messages to the Kafka cluster. By default each line will be sent as a separate message.

Run the producer and then type a few messages to send to the server. @@ -60,10 +60,10 @@ This is another message

Step 5: Start a consumer

-Kafka also has a command line consumer that will dump out messages to standard out. +Kafka also has a command line consumer that will print messages to standard output. 
-> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test --from-beginning
+> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test --from-beginning
 This is a message
 This is another message
@@ -71,12 +71,12 @@ This is another message If you have each of the above commands running in a different terminal then you should now be able to type messages into the producer terminal and see them appear in the consumer terminal.

-All the command line tools have additional options; running the command with no arguments will display usage information documenting them in more detail. +All of the command line tools have additional options; running the command with no arguments will display usage information documenting them in more detail.

Step 6: Setting up a multi-broker cluster

-So far we have been running against a single broker, but that's no fun. For Kafka, a single broker is just a cluster of size one, so nothing much changes other than starting a few more broker instances. But just to get feel for it, let's expand our cluster to three nodes (still all on our local machine). +So far we have been running against a single broker, but that's no fun. For Kafka, a single broker is just a cluster of size one; for a multi-broker cluster, nothing much changes other than starting a few more broker instances. But just to get feel for it, let's expand our cluster to three nodes (still all on our local machine).

First we make a config file for each of the brokers: 

@@ -97,9 +97,9 @@ config/server-2.properties:
     port=9094
     log.dir=/tmp/kafka-logs-2
-The broker.id property is the unique and permanent name of each node in the cluster. We have to override the port and log directory only because we are running these all on the same machine and we want to keep the brokers from trying to all register on the same port or overwrite each others data. +The broker.id property is the unique and permanent name of each node in the cluster. We have to override the port and log directory only because we are running these all on the same machine and we want to keep the brokers from all trying to register on the same port or overwrite each other's data.

-We already have Zookeeper and our single node started, so we just need to start the two new nodes. However, this time we have to override the JMX port used by java too to avoid clashes with the running node: +We already have Zookeeper and our single node started, so we just need to start the two new nodes. However, this time we also have to override the JMX port used by java to avoid clashes with the running node: 

 > JMX_PORT=9997 bin/kafka-server-start.sh config/server-1.properties &
 ...
@@ -109,34 +109,36 @@ We already have Zookeeper and our single node started, so we just need to start
 
 Now create a new topic with a replication factor of three:
 
-> bin/kafka-create-topic.sh --zookeeper localhost:2181 --replica 3 --partition 1 --topic my-replicated-topic
+> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 1 --topic my-replicated-topic
 

 
-Okay but now that we have a cluster how can we know which broker is doing what? To see that run the "list topics" command:
+Okay but now that we have a cluster how can we know which broker is doing what? To see that run the "describe" command:
 
-> bin/kafka-list-topic.sh --zookeeper localhost:2181
-topic: my-replicated-topic  partition: 0  leader: 1  replicas: 1,2,0  isr: 1,2,0
-topic: test	                partition: 0  leader: 0  replicas: 0      isr: 0
+> bin/kafka-topics.sh --describe --zookeeper localhost:2181
+Topic:my-replicated-topic  PartitionCount:1  ReplicationFactor:3  Configs:
+    Topic: my-replicated-topic Partition: 0  Leader: 1  Replicas: 1,0,2  Isr: 1,0,2
+Topic:test                 PartitionCount:1  ReplicationFactor:1  Configs:
+    Topic: test                Partition: 0  Leader: 0  Replicas: 0      Isr: 0
 

 Here is an explanation of output:
  
-Note that both topics we created have only a single partition (partition 0). The original topic has no replicas and so it is only present on the leader (node 0), the replicated topic is present on all three nodes with node 1 currently acting as leader and all replicas in sync.
+Note that both topics we created have only a single partition (partition 0). The original topic has no replicas and thus is only present on the leader (node 0). The replicated topic is present on all three nodes with node 1 currently acting as leader and all replicas in sync.
 

 As before let's publish a few messages message:
 
 > bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-replicated-topic
 ...
-my test message 1
-my test message 2
-^C 
+my test message 1
+my test message 2
+^C
 

-Now consume this message:
+Now consume these messages:
 
-> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic
+> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic
 ...
 my test message 1
 my test message 2
@@ -149,14 +151,16 @@ Now let's test out fault-tolerance. Kill the broker acting as leader for this to
 

 Leadership should switch to one of the slaves:
 
-> bin/kafka-list-topic.sh --zookeeper localhost:2181
+> bin/kafka-topics.sh --describe --zookeeper localhost:2181
 ...
-topic: my-replicated-topic	partition: 0	leader: 2	replicas: 1,2,0	isr: 2
-topic: test	partition: 0	leader: 0	replicas: 0	isr: 0
+Topic:my-replicated-topic  PartitionCount:1  ReplicationFactor:3  Configs:
+    Topic: my-replicated-topic Partition: 0  Leader: 0  Replicas: 1,0,2  Isr: 0,2
+Topic:test                 PartitionCount:1  ReplicationFactor:1  Configs:
+    Topic: test                Partition: 0  Leader: 0  Replicas: 0      Isr: 0
 

 And the messages should still be available for consumption even though the leader that took the writes originally is down:
 
-> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic
+> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic
 ...
 my test message 1
 my test message 2