【转】kafka安装及常用命令总结

前提条件

• zookeeper已经安装完毕，分别为hd1:2222,hd2:2222,hd3:2222,hd4:2222,hd5:2222
• 已经在官方网站下载好了二进制包，kafka_2.10-0.10.0.0.tgz
• 将二进制包放到所有要安装kafka的节点上，host指定为：mq1,mq2,mq3,mq4

设置zookeeper

进入hd1, 切换用户为hadoop用户，

进入zookeeper客户端

/home/hadooper/zookeeper/bin/zkCli.sh -server hd1:2222

进入到zookeeper控制台

输入如下命令，建立kafka相关目录

create /kafka ''

退出控制台 

quit

解压二进制包

[plain]  view plain  copy

1. <span style="font-size:18px;">tar -xzvf kafka_2.10-0.10.0.0.tgz  
2. mv kafka_2.10-0.10.0.0 /usr/local/kafka</span>  

编辑配置文件

[plain]  view plain  copy

1.   

编辑配置文件 /usr/local/kafka/config/server_properties如下

[html]  view plain  copy

1. <span style="font-size:18px;">broker.id=0  #不同的服务器，写不同的id，只要是不重复的无符号整数即可，建议连续上  
2. port=9092  #可以指定其他端口  
3. host.name=172.16.1.33  #请填写本台机器的内网地址  
4. ##################  以下配置均可以进行优化 ############  
5. num.network.threads=3  
6. num.io.threads=8  
7. socket.send.buffer.bytes=102400  
8. socket.receive.buffer.bytes=102400  
9. socket.request.max.bytes=104857600  
10. log.dirs=/usr/local/kafka/logs  
11. num.partitions=1  
12. num.recovery.threads.per.data.dir=1  
13. log.retention.hours=168  
14. log.segment.bytes=1073741824  
15. log.retention.check.interval.ms=300000  
16. log.cleaner.enable=false  
17. ##################  以上配置均可以进行优化 ############  
18. #此处为zookeeper的配置，请按照实际情况配置  
19. zookeeper.connect=hd1:2222,hd2:2222,hd3:2222,hd4:2222,hd5:2222,hd6:2222/kafka  
20. zookeeper.connection.timeout.ms=6000</span>  

配置文件的详细说明如下：

broker.id =0	每一个broker在集群中的唯一表示，要求是正数。当该服务器的IP地址发生改变时，broker.id没有变化，则不会影响consumers的消息情况
log.dirs=/data/kafka-logs	kafka数据的存放地址，多个地址的话用逗号分割/data/kafka-logs-1，/data/kafka-logs-2
port =9092	broker server服务端口
message.max.bytes =6525000	表示消息体的最大大小，单位是字节
num.network.threads =4	broker处理消息的最大线程数，一般情况下不需要去修改
num.io.threads =8	broker处理磁盘IO的线程数，数值应该大于你的硬盘数
background.threads =4	一些后台任务处理的线程数，例如过期消息文件的删除等，一般情况下不需要去做修改
queued.max.requests =500	等待IO线程处理的请求队列最大数，若是等待IO的请求超过这个数值，那么会停止接受外部消息，应该是一种自我保护机制。
host.name	broker的主机地址，若是设置了，那么会绑定到这个地址上，若是没有，会绑定到所有的接口上，并将其中之一发送到ZK，一般不设置
socket.send.buffer.bytes=100*1024	socket的发送缓冲区，socket的调优参数SO_SNDBUFF
socket.receive.buffer.bytes =100*1024	socket的接受缓冲区，socket的调优参数SO_RCVBUFF
socket.request.max.bytes =100*1024*1024	socket请求的最大数值，防止serverOOM，message.max.bytes必然要小于socket.request.max.bytes，会被topic创建时的指定参数覆盖
log.segment.bytes =1024*1024*1024	topic的分区是以一堆segment文件存储的，这个控制每个segment的大小，会被topic创建时的指定参数覆盖
log.roll.hours =24*7	这个参数会在日志segment没有达到log.segment.bytes设置的大小，也会强制新建一个segment会被 topic创建时的指定参数覆盖
log.cleanup.policy = delete	日志清理策略选择有：delete和compact主要针对过期数据的处理，或是日志文件达到限制的额度，会被 topic创建时的指定参数覆盖
log.retention.minutes=3days	数据存储的最大时间超过这个时间会根据log.cleanup.policy设置的策略处理数据，也就是消费端能够多久去消费数据 log.retention.bytes和log.retention.minutes任意一个达到要求，都会执行删除，会被topic创建时的指定参数覆盖
log.retention.bytes=-1	topic每个分区的最大文件大小，一个topic的大小限制 =分区数*log.retention.bytes。-1没有大小限log.retention.bytes和log.retention.minutes任意一个达到要求，都会执行删除，会被topic创建时的指定参数覆盖
log.retention.check.interval.ms=5minutes	文件大小检查的周期时间，是否处罚 log.cleanup.policy中设置的策略
log.cleaner.enable=false	是否开启日志压缩
log.cleaner.threads = 2	日志压缩运行的线程数
log.cleaner.io.max.bytes.per.second=None	日志压缩时候处理的最大大小
log.cleaner.dedupe.buffer.size=500*1024*1024	日志压缩去重时候的缓存空间，在空间允许的情况下，越大越好
log.cleaner.io.buffer.size=512*1024	日志清理时候用到的IO块大小一般不需要修改
log.cleaner.io.buffer.load.factor =0.9	日志清理中hash表的扩大因子一般不需要修改
log.cleaner.backoff.ms =15000	检查是否处罚日志清理的间隔
log.cleaner.min.cleanable.ratio=0.5	日志清理的频率控制，越大意味着更高效的清理，同时会存在一些空间上的浪费，会被topic创建时的指定参数覆盖
log.cleaner.delete.retention.ms =1day	对于压缩的日志保留的最长时间，也是客户端消费消息的最长时间，同log.retention.minutes的区别在于一个控制未压缩数据，一个控制压缩后的数据。会被topic创建时的指定参数覆盖
log.index.size.max.bytes =10*1024*1024	对于segment日志的索引文件大小限制，会被topic创建时的指定参数覆盖
log.index.interval.bytes =4096	当执行一个fetch操作后，需要一定的空间来扫描最近的offset大小，设置越大，代表扫描速度越快，但是也更好内存，一般情况下不需要搭理这个参数
log.flush.interval.messages=None	log文件”sync”到磁盘之前累积的消息条数,因为磁盘IO操作是一个慢操作,但又是一个”数据可靠性"的必要手段,所以此参数的设置,需要在"数据可靠性"与"性能"之间做必要的权衡.如果此值过大,将会导致每次"fsync"的时间较长(IO阻塞),如果此值过小,将会导致"fsync"的次数较多,这也意味着整体的client请求有一定的延迟.物理server故障,将会导致没有fsync的消息丢失.
log.flush.scheduler.interval.ms =3000	检查是否需要固化到硬盘的时间间隔
log.flush.interval.ms = None	仅仅通过interval来控制消息的磁盘写入时机,是不足的.此参数用于控制"fsync"的时间间隔,如果消息量始终没有达到阀值,但是离上一次磁盘同步的时间间隔达到阀值,也将触发.
log.delete.delay.ms =60000	文件在索引中清除后保留的时间一般不需要去修改
log.flush.offset.checkpoint.interval.ms =60000	控制上次固化硬盘的时间点，以便于数据恢复一般不需要去修改
auto.create.topics.enable =true	是否允许自动创建topic，若是false，就需要通过命令创建topic
default.replication.factor =1	是否允许自动创建topic，若是false，就需要通过命令创建topic
num.partitions =1	每个topic的分区个数，若是在topic创建时候没有指定的话会被topic创建时的指定参数覆盖
以下是kafka中Leader,replicas配置参数
controller.socket.timeout.ms =30000	partition leader与replicas之间通讯时,socket的超时时间
controller.message.queue.size=10	partition leader与replicas数据同步时,消息的队列尺寸
replica.lag.time.max.ms =10000	replicas响应partition leader的最长等待时间，若是超过这个时间，就将replicas列入ISR(in-sync replicas)，并认为它是死的，不会再加入管理中
replica.lag.max.messages =4000	如果follower落后与leader太多,将会认为此follower[或者说partition relicas]已经失效 ##通常,在follower与leader通讯时,因为网络延迟或者链接断开,总会导致replicas中消息同步滞后 ##如果消息之后太多,leader将认为此follower网络延迟较大或者消息吞吐能力有限,将会把此replicas迁移 ##到其他follower中. ##在broker数量较少,或者网络不足的环境中,建议提高此值.
replica.socket.timeout.ms=30*1000	follower与leader之间的socket超时时间
replica.socket.receive.buffer.bytes=64*1024	leader复制时候的socket缓存大小
replica.fetch.max.bytes =1024*1024	replicas每次获取数据的最大大小
replica.fetch.wait.max.ms =500	replicas同leader之间通信的最大等待时间，失败了会重试
replica.fetch.min.bytes =1	fetch的最小数据尺寸,如果leader中尚未同步的数据不足此值,将会阻塞,直到满足条件
num.replica.fetchers=1	leader进行复制的线程数，增大这个数值会增加follower的IO
replica.high.watermark.checkpoint.interval.ms =5000	每个replica检查是否将最高水位进行固化的频率
controlled.shutdown.enable =false	是否允许控制器关闭broker ,若是设置为true,会关闭所有在这个broker上的leader，并转移到其他broker
controlled.shutdown.max.retries =3	控制器关闭的尝试次数
controlled.shutdown.retry.backoff.ms =5000	每次关闭尝试的时间间隔
leader.imbalance.per.broker.percentage =10	leader的不平衡比例，若是超过这个数值，会对分区进行重新的平衡
leader.imbalance.check.interval.seconds =300	检查leader是否不平衡的时间间隔
offset.metadata.max.bytes	客户端保留offset信息的最大空间大小
kafka中zookeeper参数配置
zookeeper.connect = localhost:2181	zookeeper集群的地址，可以是多个，多个之间用逗号分割hostname1:port1,hostname2:port2,hostname3:port3
zookeeper.session.timeout.ms=6000	ZooKeeper的最大超时时间，就是心跳的间隔，若是没有反映，那么认为已经死了，不易过大
zookeeper.connection.timeout.ms =6000	ZooKeeper的连接超时时间
zookeeper.sync.time.ms =2000	ZooKeeper集群中leader和follower之间的同步实际那

编辑完毕后，保存配置文件

常用命令

启动kafka:

/usr/local/kafka/bin/kafka-server-start.sh /usr/local/kafka/config/server.properties&

关闭kafka(关闭机器以前，一定要使用此命令来关闭kafka以后再进行关闭，否则启动时，有丢失队列中数据的风险)

/usr/local/kafka/bin/kafka-server-stop.sh

创建topic

/usr/local/kafka/bin/kafka-topics.sh --create--zookeeper hd1:2222,hd2:2222,hd3:2222,hd4:2222,hd5:2222 --replication-factor 3 --partitions 2 --topic nginx_total1

--replication-factor  副本数量

--partitions  分区数量，调用的时候，编号从0开始

--topic       主题的名称

转载内容

以下内容转载自 http://blog.jobbole.com/99195/，感谢分享

（五）某个broker挂掉，本机器可重启

【结论】如果一个broker挂掉，且可以重启则处理步骤如下：
（1）重启kafka进程
（2）执行rebalance（由于已经设置配置项自动执行balance，因此此步骤一般可忽略）

详细分析见下面操作过程。
1、topic的情况

Shell

1 2 3 4 5

bin / kafka - topics .sh -- describe -- zookeeper 192.168.172.111 : 2181 / kafka -- topic test_topic      Topic : test_topic         PartitionCount : 3          ReplicationFactor : 2      Configs :      Topic : test_topic       Partition : 0      Leader : 5        Replicas : 5 , 2    Isr : 5 , 2      Topic : test_topic       Partition : 1      Leader : 2        Replicas : 2 , 3    Isr : 2 , 3      Topic : test_topic       Partition : 2      Leader : 3        Replicas : 3 , 4    Isr : 3 , 4

集群中有4台机器，id为【2-5】,topic 有3个分区，每个分区2个副本，leader分别位于2，3，5中。

2、模拟机器down，kill掉进程
分区0的leader位于id=5的broker中，kill掉这台机器的kafka进程

Shell

1	kill - 9 < em > * * < / em >

3、再次查看topic的情况

Shell

1 2 3 4 5

bin / kafka - topics .sh -- describe -- zookeeper 192.168.172.111 : 2181 / kafka -- topic test_topic      Topic : test_topic         PartitionCount : 3          ReplicationFactor : 2      Configs :      Topic : test_topic       Partition : 0      Leader : 2        Replicas : 5 , 2    Isr : 2      Topic : test_topic       Partition : 1      Leader : 2        Replicas : 2 , 3    Isr : 2 , 3      Topic : test_topic       Partition : 2      Leader : 3        Replicas : 3 , 4    Isr : 3 , 4

可以看到，分区0的leader已经移到id=2的机器上了，它的副本位于2，5这2台机器上，但处于同步状态的只有id=2这台机器。

4、重启kafka进程

Shell

1	bin / kafka - server - start .sh config / server .properties &

5、再次查看状态

Shell

1 2 3 4 5

bin / kafka - topics .sh -- describe -- zookeeper 192.168.172.111 : 2181 / kafka -- topic test_topic      Topic : test_topic         PartitionCount : 3          ReplicationFactor : 2      Configs :      Topic : test_topic       Partition : 0      Leader : 2        Replicas : 5 , 2    Isr : 2 , 5      Topic : test_topic       Partition : 1      Leader : 2        Replicas : 2 , 3    Isr : 2 , 3      Topic : test_topic       Partition : 2      Leader : 3        Replicas : 3 , 4    Isr : 3 , 4

发现分区0的2个副本都已经处于同步状态，但leader依然为id=2的broker。

6、执行leader平衡
详见leader的平衡部分。

Shell

1	bin / kafka - preferred - replica - election .sh -- zookeeper 192.168.172.98 : 2181 / kafka

如果配置文件中

Shell

1	auto .leader .rebalance .enable = true

则此步骤不需要执行。

7、重新查看topic

Shell

1 2 3 4 5

bin / kafka - topics .sh -- describe -- zookeeper 192.168.172.111 : 2181 / kafka -- topic test_topic      Topic : test_topic         PartitionCount : 3          ReplicationFactor : 2      Configs :      Topic : test_topic       Partition : 0      Leader : 5        Replicas : 5 , 2    Isr : 2 , 5      Topic : test_topic       Partition : 1      Leader : 2        Replicas : 2 , 3    Isr : 2 , 3      Topic : test_topic       Partition : 2      Leader : 3        Replicas : 3 , 4    Isr : 3 , 4

此时leader已经回到了id=5的broker，一切恢复正常。

#（六）某个broker挂掉且无法重启，需要其它机器代替

【结论】当一个broker挂掉，需要换机器时，采用以下步骤：
1、将新机器kafka配置文件中的broker.id设置为与原机器一样
2、启动kafka，注意kafka保存数据的目录不会自动创建，需要手工创建

详细分析过程如下：
1、初始化机器，主要包括用户创建，kafka文件的复制等。

2、修改config/server.properties文件
注意，只需要修改一个配置broker.id，且此配置必须与挂掉的那台机器相同，因为kafka是通过broker.id来区分集群中的机器的。此处设为

Shell

1	broker .id = 5

3、查看topic的当前状态

Shell

1 2 3 4 5

bin / kafka - topics .sh -- describe -- zookeeper 192.168.172.111 : 2181 / kafka -- topic test_topic      Topic : test_topic         PartitionCount : 3          ReplicationFactor : 2      Configs :      Topic : test_topic       Partition : 0      Leader : 5        Replicas : 5 , 2    Isr : 2 , 5      Topic : test_topic       Partition : 1      Leader : 2        Replicas : 2 , 3    Isr : 2 , 3      Topic : test_topic       Partition : 2      Leader : 3        Replicas : 3 , 4    Isr : 3 , 4

当前topic有3个分区，其中分区1的leader位于id=5的机器上。

4、关掉id=5的机器
kill -9 ** 用于模拟机器突然down
或者：

Shell

1	bin / kafka - server - stop .sh

用于正常关闭

5、查看topic的状态

Shell

1 2 3 4 5

bin / kafka - topics .sh -- describe -- zookeeper 192.168.172.111 : 2181 / kafka -- topic test_topic      Topic : test_topic         PartitionCount : 3          ReplicationFactor : 2      Configs :      Topic : test_topic       Partition : 0      Leader : 2        Replicas : 5 , 2    Isr : 2      Topic : test_topic       Partition : 1      Leader : 2        Replicas : 2 , 3    Isr : 2 , 3      Topic : test_topic       Partition : 2      Leader : 3        Replicas : 3 , 4    Isr : 3 , 4

可见，topic的分区0的leader已经迁移到了id=2的机器上，且处于同步的机器只有一个了。

6、启动新机器

Shell

1	nohup bin / kafka - server - start .sh config / server .properties

7、再看topic的状态

Shell

1 2 3 4 5

bin / kafka - topics .sh -- describe -- zookeeper 192.168.172.111 : 2181 / kafka -- topic test_topic      Topic : test_topic         PartitionCount : 3          ReplicationFactor : 2      Configs :      Topic : test_topic       Partition : 0      Leader : 2        Replicas : 5 , 2    Isr : 2 , 5      Topic : test_topic       Partition : 1      Leader : 2        Replicas : 2 , 3    Isr : 2 , 3      Topic : test_topic       Partition : 2      Leader : 3        Replicas : 3 , 4    Isr : 3 , 4

id=5的机器也处于同步状态了，但还需要将leader恢复到这台机器上。

8、执行leader平衡
详见leader的平衡部分。

Shell

1	bin / kafka - preferred - replica - election .sh – zookeeper 192.168.172.98 : 2181 / kafka

如果配置文件中

Shell

1	auto .leader .rebalance .enable = true

则此步骤不需要执行。

9、done

Shell

1 2 3 4 5

bin / kafka - topics .sh -- describe -- zookeeper 192.168.172.111 : 2181 / kafka -- topic test_topic      Topic : test_topic         PartitionCount : 3          ReplicationFactor : 2      Configs :      Topic : test_topic       Partition : 0      Leader : 5        Replicas : 5 , 2    Isr : 2 , 5      Topic : test_topic       Partition : 1      Leader : 2        Replicas : 2 , 3    Isr : 2 , 3      Topic : test_topic       Partition : 2      Leader : 3        Replicas : 3 , 4    Isr : 3 , 4

所有内容都恢复了

#（七）扩容

将一台机器加入kafka集群很容易，只需要为它分配一个独立的broker id，然后启动它即可。但是这些新加入的机器上面并没有任何的分区数据，所以除非将现有数据移动这些机器上，否则它不会做任何工作，直到创建新topic。因此，当你往集群加入机器时，你应该将其它机器上的一部分数据往这台机器迁移。
数据迁移的工作需要手工初始化，然后自动完成。它的原理如下：当新机器起来后，kafka将其它机器的一些分区复制到这个机器上，并作为follower，当这个新机器完成复制并成为in-sync状态后，那些被复制的分区的一个副本会被删除。（都不会成为leader?)

1、将新机器kafka配置文件中的broker.id设置为与原机器一样
2、启动kafka，注意kafka保存数据的目录不会自动创建，需要手工创建
此时新建的topic都会优先分配leader到新增的机器上，但原有的topic不会将分区迁移过来。
3、数据迁移，请见数据迁移部分。

#（八）数据迁移

以下步骤用于将现有数据迁移到新的broker中，假设需要将test_topic与streaming_ma30_sdc的全部分区迁移到新的broker中（id 为6和7）
1、创建一个json文件，用于指定哪些topic将被迁移过去
cat topics-to-move.json

Shell

1 2 3 4 5 6

{ "topics" : [ { "topic" : "test_topic" } , { "topic" : "streaming_ma30_sdc" } ] , "version" : 1 }

注意全角，半角符号，或者中文引号之类的问题。

2、先generate迁移后的结果，检查一下是不是你要想的效果

Shell

1 2 3 4 5 6

bin / kafka - reassign - partitions .sh -- zookeeper 192.168.172.98 : 2181 / kafka -- topics - to - move - json - file topics - to - move .json -- broker - list "6,7" — generate Current partition replica assignment { "version" : 1 , "partitions" : [ { "topic" : "streaming_ma30_sdc" , "partition" : 2 , "replicas" : [ 2 ] } , { "topic" : "test_topic" , "partition" : 0 , "replicas" : [ 5 , 2 ] } , { "topic" : "test_topic" , "partition" : 2 , "replicas" : [ 3 , 4 ] } , { "topic" : "streaming_ma30_sdc" , "partition" : 1 , "replicas" : [ 5 ] } , { "topic" : "streaming_ma30_sdc" , "partition" : 0 , "replicas" : [ 4 ] } , { "topic" : "test_topic" , "partition" : 1 , "replicas" : [ 2 , 3 ] } , { "topic" : "streaming_ma30_sdc" , "partition" : 3 , "replicas" : [ 3 ] } , { "topic" : "streaming_ma30_sdc" , "partition" : 4 , "replicas" : [ 4 ] } ] }   Proposed partition reassignment configuration { "version" : 1 , "partitions" : [ { "topic" : "test_topic" , "partition" : 0 , "replicas" : [ 7 , 6 ] } , { "topic" : "streaming_ma30_sdc" , "partition" : 2 , "replicas" : [ 7 ] } , { "topic" : "test_topic" , "partition" : 2 , "replicas" : [ 7 , 6 ] } , { "topic" : "streaming_ma30_sdc" , "partition" : 1 , "replicas" : [ 6 ] } , { "topic" : "test_topic" , "partition" : 1 , "replicas" : [ 6 , 7 ] } , { "topic" : "streaming_ma30_sdc" , "partition" : 0 , "replicas" : [ 7 ] } , { "topic" : "streaming_ma30_sdc" , "partition" : 4 , "replicas" : [ 7 ] } , { "topic" : "streaming_ma30_sdc" , "partition" : 3 , "replicas" : [ 6 ] } ] }

分别列出了当前的状态以及迁移后的状态。
把这2个json分别保存下来，第一个用来万一需要roll back的时候使用，第二个用来执行迁移。

3、执行迁移

Shell

1	bin / kafka - reassign - partitions .sh -- zookeeper 192.168.172.98 : 2181 / kafka -- reassignment - json - file expand - cluster - reassignment .json -- execute 其中 expand - cluster - reassignment .json为保存上面第二段 json的文件。

4、查看迁移过程

Shell

1 2 3 4 5 6 7 8 9 10

bin / kafka - reassign - partitions .sh -- zookeeper 192.168.172.98 : 2181 / kafka -- reassignment - json - file expand - cluster - reassignment .json -- verify Status of partition reassignment : Reassignment of partition [ streaming_ma30_sdc , 0 ] is still in progress Reassignment of partition [ streaming_ma30_sdc , 4 ] is still in progress Reassignment of partition [ test_topic , 2 ] completed successfully Reassignment of partition [ test_topic , 0 ] completed successfully Reassignment of partition [ streaming_ma30_sdc , 3 ] is still in progress Reassignment of partition [ streaming_ma30_sdc , 1 ] is still in progress Reassignment of partition [ test_topic , 1 ] completed successfully Reassignment of partition [ streaming_ma30_sdc , 2 ] is still in progress

5、当所有迁移的完成后，查看一下结果是不是你想要的

Shell

1 2 3 4 5

bin / kafka - topics .sh -- describe -- zookeeper 192.168.172.111 : 2181 / kafka -- topic test_topic      Topic : test_topic         PartitionCount : 3          ReplicationFactor : 2      Configs :      Topic : test_topic       Partition : 0      Leader : 7        Replicas : 7 , 6    Isr : 6 , 7      Topic : test_topic       Partition : 1      Leader : 6        Replicas : 6 , 7    Isr : 6 , 7      Topic : test_topic       Partition : 2      Leader : 7        Replicas : 7 , 6    Isr : 6 , 7

完成

以上步骤将整个topic迁移，也可以只迁移其中一个或者多个分区。
以下将test_topic的分区1移到broker id为2，3的机器,分区2移到broker id为4,5的机器.
【其实还是整个topic迁移好一点，不然准备迁移文件会很麻烦】

1、准备迁移配置文件
cat custom-reassignment.json

Shell

1	{ "version" : 1 , "partitions" : [ { "topic" : "test_topic" , "partition" : 1 , "replicas" : [ 2 , 3 ] } , { "topic" : "test_topic" , "partition" : 2 , "replicas" : [ 4 , 5 ] } ] }

3、执行迁移

Shell

1	bin / kafka - reassign - partitions .sh -- zookeeper 192.168.172.98 : 2181 / kafka -- reassignment - json - file custom - reassignment .json -- execute

4、查看迁移过程

Shell

1	bin / kafka - reassign - partitions .sh -- zookeeper 192.168.172.98 : 2181 / kafka -- reassignment - json - file custom - reassignment .json -- verify

5、查看迁移结果

Shell

1	bin / kafka - topics .sh -- describe -- zookeeper 192.168.172.111 : 2181 / kafka -- topic test_topic

#（九）机器下线

当一个机器下线时，kafka并不会自动将这台机器上的副本迁移到其它机器上，因此，我们需要手工进行迁移。这个过程会相当的无聊，kafka打算在0.8.2版本中添加此特性。
有了吗？再找找。如果只是替换机器则不会有这个问题。

#（十）增加副本数量Increasing replication factor

Increasing the replication factor of an existing partition is easy. Just specify the extra replicas in the custom reassignment json file and use it with the –execute option to increase the replication factor of the specified partitions.
For instance, the following example increases the replication factor of partition 0 of topic foo from 1 to 3. Before increasing the replication factor, the partition’s only replica existed on broker 5. As part of increasing the replication factor, we will add more replicas on brokers 6 and 7.

The first step is to hand craft the custom reassignment plan in a json file-

cat increase-replication-factor.json
{“version”:1,
“partitions”:[{“topic”:”foo”,”partition”:0,”replicas”:[5,6,7]}]}

Then, use the json file with the –execute option to start the reassignment process-
> bin/kafka-reassign-partitions.sh –zookeeper localhost:2181 –reassignment-json-file increase-replication-factor.json –execute
Current partition replica assignment

{“version”:1,
“partitions”:[{“topic”:”foo”,”partition”:0,”replicas”:[5]}]}

Save this to use as the –reassignment-json-file option during rollback
Successfully started reassignment of partitions
{“version”:1,
“partitions”:[{“topic”:”foo”,”partition”:0,”replicas”:[5,6,7]}]}
The –verify option can be used with the tool to check the status of the partition reassignment. Note that the same increase-replication-factor.json (used with the –execute option) should be used with the –verify option

bin/kafka-reassign-partitions.sh –zookeeper localhost:2181 –reassignment-json-file increase-replication-factor.json –verify
Status of partition reassignment:
Reassignment of partition [foo,0] completed successfully
You can also verify the increase in replication factor with the kafka-topics tool-
> bin/kafka-topics.sh –zookeeper localhost:2181 –topic foo –describe
Topic:foo PartitionCount:1 ReplicationFactor:3 Configs:
Topic: foo Partition: 0 Leader: 5 Replicas: 5,6,7 Isr: 5,6,7

#（十一）leader的平衡

当一个broker down掉时，所有本来将它作为leader的分区会被将leader转移到其它broker。这意味着当这个broker重启时，它将不再担任何分区的leader，kafka的client也不会从这个broker来读取消息，导致资源的浪费。
为了避免这种情况的发生，kafka增加了一个标记：优先副本（preferred replicas）。如果一个分区有3个副本，且这3个副本的优先级别分别为1，5，9，则1会作为leader。为了使kafka集群恢复默认的leader，需要运行以下命令：

Shell

1	bin / kafka - preferred - replica - election .sh -- zookeeper 192.168.172.98 : 2181 / kafka

或者可以设置以下配置项，leader 会自动执行balance：

Shell

1	auto .leader .rebalance .enable = true

这配置默认即为空，但需要经过一段时间后才会触发，约半小时。