kafka Replica Tool

Preferred Replica Leader Election Tool

　　有了Replication机制后，每个Partition可能有多个备份。某个Partition的Replica列表叫作AR（Assigned Replicas），AR中的第一个Replica即为“Preferred Replica”。创建一个新的Topic或者给已有Topic增加Partition时，Kafka保证Preferred Replica被均匀分布到集群中的所有Broker上。理想情况下，Preferred Replica会被选为Leader。以上两点保证了所有Partition的Leader被均匀分布到了集群当中，这一点非常重要，因为所有的读写操作都由Leader完成，若Leader分布过于集中，会造成集群负载不均衡。但是，随着集群的运行，该平衡可能会因为Broker的宕机而被打破，该工具就是用来帮助恢复Leader分配的平衡。

　　事实上，每个Topic从失败中恢复过来后，它默认会被设置为Follower角色，除非某个Partition的Replica全部宕机，而当前Broker是该Partition的AR中第一个恢复回来的Replica。因此，某个Partition的Leader（Preferred Replica）宕机并恢复后，它很可能不再是该Partition的Leader，但仍然是Preferred Replica。

对所有Topics进行操作

bin/kafka-preferred-replica-election.sh --zookeeper hadoop16:2181,hadoop17:2181,hadoop18:2181/kafka08

对某个Topic进行操作

cat topicPartitionList.json
{
 "partitions":
  [
    {"topic":"test.example","partition": "0"}
  ]
}

bin/kafka-preferred-replica-election.sh --zookeeper hadoop16:2181,hadoop17:2181,hadoop18:2181/kafka08 --path-to-json-file topicPartitionList.json

　　除了手动运行该工具使Leader分配均匀外，Kafka还提供了自动平衡Leader分配的功能

auto.leader.rebalance.enable 默认值：false

如果设为true，复制控制器会周期性的自动尝试，为所有的broker的每个partition平衡leadership，为更优先(preferred)的replica分配leadership。

leader.imbalance.per.broker.percentage 默认值：10

每个broker允许的不平衡的leader的百分比。如果每个broker超过了这个百分比，复制控制器会重新平衡leadership。

leader.imbalance.check.interval.seconds 默认值：300

检测leader不平衡的时间间隔。

Kafka Reassign Partitions Tool

该工具的设计目标与Preferred Replica Leader Election Tool有些类似，都旨在促进Kafka集群的负载均衡。不同的是，Preferred Replica Leader Election只能在Partition的AR范围内调整其Leader，使Leader分布均匀，而该工具还可以调整Partition的AR。

　　Follower需要从Leader Fetch数据以保持与Leader同步，所以仅仅保持Leader分布的平衡对整个集群的负载均衡来说是不够的。另外，生产环境下，随着负载的增大，可能需要给Kafka集群扩容。向Kafka集群中增加Broker非常简单方便，但是对于已有的Topic，并不会自动将其Partition迁移到新加入的Broker上，此时可用该工具达到此目的。某些场景下，实际负载可能远小于最初预期负载，此时可用该工具将分布在整个集群上的Partition重装分配到某些机器上，然后可以停止不需要的Broker从而实现节约资源的目的。

　　需要说明的是，该工具不仅可以调整Partition的AR位置，还可调整其AR数量，即改变该Topic的replication factor。

kafka-reassign-partitions.sh是kafka提供的用来重新分配partition和replica到broker上的工具
简单实现重新分配需要三步：

• 生成分配计划（generate）
• 执行分配（execute）
• 检查分配的状态（verify）

执行分配计划生成脚本：

kafka-reassign-partitions.sh --zookeeper $ZK_CONNECT --topics-to-move-json-file topics-to-move.json --broker-list "5,6,7,8" --generate

执行结果如下：

[hadoop@sdf-nimbus-perf topic_reassgin]$ kafka-reassign-partitions.sh --zookeeper $ZK_CONNECT --topics-to-move-json-file topics-to-move.json --broker-list "5,6,7,8" --generate
Current partition replica assignment  #当前分区的副本分配

{"version":1,"partitions":[{"topic":"event_request","partition":0,"replicas":[3,4]},{"topic":"event_request","partition":1,"replicas":[4,5]}]}
Proposed partition reassignment configuration #建议的分区配置

{"version":1,"partitions":[{"topic":"event_request","partition":0,"replicas":[6,5]},{"topic":"event_request","partition":1,"replicas":[7,6]}]}

Proposed partition reassignment configuration 后是根据命令行的指定的brokerlist生成的分区分配计划json格式。将 Proposed partition reassignment configuration的配置copy保存到一个文件中 topic-reassignment.json

vi topic-reassignment.json

{"version":1,"partitions":[{"topic":"event_request","partition":0,"replicas":[6,5]},{"topic":"event_request","partition":1,"replicas":[7,6]}]}

2. 执行分配（execute）

根据step1 生成的分配计划配置json文件topic-reassignment.json，进行topic的重新分配。

kafka-reassign-partitions.sh --zookeeper $ZK_CONNECT --reassignment-json-file topic-reassignment.json --execute

执行前的分区分布：

[hadoop@sdf-nimbus-perf topic_reassgin]$ le-kafka-topics.sh --describe --topic event_request
Topic:event_request PartitionCount:2    ReplicationFactor:2 Configs:
    Topic: event_request    Partition: 0    Leader: 3   Replicas: 3,4   Isr: 3,4
    Topic: event_request    Partition: 1    Leader: 4   Replicas: 4,5   Isr: 4,5

执行后的分区分布：

[hadoop@sdf-nimbus-perf topic_reassgin]$ le-kafka-topics.sh --describe --topic event_request
Topic:event_request PartitionCount:2    ReplicationFactor:4 Configs:
    Topic: event_request    Partition: 0    Leader: 3   Replicas: 6,5,3,4   Isr: 3,4
    Topic: event_request    Partition: 1    Leader: 4   Replicas: 7,6,4,5   Isr: 4,5

3. 检查分配的状态

查看分配的状态：正在进行

[hadoop@sdf-nimbus-perf topic_reassgin]$ kafka-reassign-partitions.sh --zookeeper $ZK_CONNECT --reassignment-json-file topic-reassignment.json --verify
Status of partition reassignment:
Reassignment of partition [event_request,0] is still in progress
Reassignment of partition [event_request,1] is still in progress
[hadoop@sdf-nimbus-perf topic_reassgin]$ 

查看“is still in progress” 状态时的分区，副本分布状态：

发现Replicas有4个哦，说明在重新分配的过程中新旧的副本都在进行工作。

[hadoop@sdf-nimbus-perf topic_reassgin]$ le-kafka-topics.sh --describe --topic event_request
Topic:event_request PartitionCount:2    ReplicationFactor:4 Configs:
    Topic: event_request    Partition: 0    Leader: 3   Replicas: 6,5,3,4   Isr: 3,4
    Topic: event_request    Partition: 1    Leader: 4   Replicas: 7,6,4,5   Isr: 4,5

查看分配的状态：分配完成。

[hadoop@sdf-nimbus-perf topic_reassgin]$ kafka-reassign-partitions.sh --zookeeper $ZK_CONNECT --reassignment-json-file topic-reassignment.json --verify
Status of partition reassignment:
Reassignment of partition [event_request,0] completed successfully
Reassignment of partition [event_request,1] completed successfully

查看“completed successfully”状态的分区，副本状态：

已经按照生成的分配计划正确的完成了分区的重新分配。

[hadoop@sdf-nimbus-perf topic_reassgin]$ le-kafka-topics.sh --describe --topic event_request
Topic:event_request PartitionCount:2    ReplicationFactor:2 Configs:
    Topic: event_request    Partition: 0    Leader: 6   Replicas: 6,5   Isr: 6,5
    Topic: event_request    Partition: 1    Leader: 7   Replicas: 7,6   Isr: 6,7

下线broker

分两种情况处理：

• 所有的topic的replica >= 2

       此时，直接停止一个broker，会自动触发leader election操作，不过目前leader election是逐个partition进行，等待所有partition完成leader election耗时较长，这样不可服务的时间就比较长。为了缩短不可服务时间窗口，可以主动触发停止broker操作，这样可以逐个partition转移，直到所有partition完成转移，再停止broker。

bin/kafka-run-class.sh kafka.admin.ShutdownBroker --zookeeper 192.168.2.225:2182 --broker #brokerId# --num.retries 3 --retry.interval.ms 60
然后shutdown broker
bin/kafka-server-stop.sh 

•        当存在topic的副本数小于2，只能手工把当前broker上这些topic对应的partition转移到其他broker上。当此broker上剩余的topic的replica > 2时，参照上面的处理方法继续处理。存在topic的replica=1