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