5.Kafka集群维护

5.Kafka集群维护

更多干货

• 分布式实战（干货）
• spring cloud 实战（干货）
• mybatis 实战（干货）
• spring boot 实战（干货）
• React 入门实战（干货）
• 构建中小型互联网企业架构（干货）
• python 学习持续更新
• ElasticSearch 笔记

一、概述

二、Kafka集群基本信息实时查看和修改

集群信息实时查看(topic工具)：

• 列出集群当前所有可用的topic：

bin/kafka-topics.sh --list –zookeeper   zookeeper_address

查看集群特定topic 信息：

bin/kafka-topics.sh --describe --zookeeper zookeeper_address --topic topic_name

集群信息实时修改(topic工具)：

• 创建topic：

bin/kafka-topics.sh --create --zookeeper zookeeper_address    --replication-factor 1 --partitions 1 --topic topic_name

增加(不能减少) partition(最后的4是增加后的值)：

bin/kafka-topics.sh --zookeeper zookeeper_address    --alter –topic topic_name  --partitions 4 

Topic-level configuration 配置都能修改

三、Kafka集群leader平衡机制

当一个broker停止或者crashes时，所有本来将它作为leader的分区将会把leader转移到其它broker上去。这意味着当这个broker重启时，它将不再担任何分区的leader，kafka的client也不会从这个broker来读取消息，从而导致资源的浪费。比如broker 7是挂掉重启的，我们可以发现Partition 1虽然在broker 7上有数据，但是由于它挂了，所以Kafka重新将broker 3当作该分区的Leader，然而broker 3已经是Partition 6的Leader了。

[ctoedu ~]$ kafka-topics.sh --topic ctoedu   \
--describe --zookeeper www.ctoedu.com:2181
 
Topic:ctoedu PartitionCount:7  ReplicationFactor:2 Configs:
  Topic: ctoedu  Partition: 0  Leader: 1 Replicas: 1,4 Isr: 1,4
  Topic: ctoedu  Partition: 1  Leader: 3 Replicas: 7,3 Isr: 3,7
  Topic: ctoedu  Partition: 2  Leader: 5 Replicas: 5,7 Isr: 5,7
  Topic: ctoedu  Partition: 3  Leader: 6 Replicas: 6,1 Isr: 1,6
  Topic: ctoedu  Partition: 4  Leader: 4 Replicas: 4,2 Isr: 4,2
  Topic: ctoedu  Partition: 5  Leader: 2 Replicas: 2,5 Isr: 5,2
  Topic: ctoedu  Partition: 6  Leader: 3 Replicas: 3,6 Isr: 3,6

幸运的是，Kafka中有一个被称为优先副本(preferred replicas)的概念。如果一个分区有3个副本，且这3个副本的优先级别分别为1，5，9，根据优先副本的概念，1会作为leader。为了使kafka集群恢复默认的leader，需要运行以下命令：

[ctoedu ~]$ kafka-preferred-replica-election.sh   \
--zookeeper www.ctoedu.com:2181
 
Successfully started preferred replica election for partitions Set([ctoedu,1],
 [ctoedu,5], [ctoedu,4], [ctoedu,6], [ctoedu,2], [ctoedu,0], [ctoedu,3])

每次运行上面的命令是比较烦躁的，不过Kafka为我们提供了一个参数，可以使得Kafka集群自动平衡Leader，我们只需要在server.properties文件中配置如下设置

auto.leader.rebalance.enable=true

这个值默认就是打开的。下面是Leader平衡的结果：

[ctoedu ~]$ kafka-topics.sh --topic ctoedu --describe \
--zookeeper www.ctoedu.com:2181
 
Topic:ctoedu PartitionCount:7  ReplicationFactor:2 Configs:
  Topic: ctoedu  Partition: 0  Leader: 1 Replicas: 1,4 Isr: 1,4
  Topic: ctoedu  Partition: 1  Leader: 7 Replicas: 7,3 Isr: 3,7
  Topic: ctoedu  Partition: 2  Leader: 5 Replicas: 5,7 Isr: 5,7
  Topic: ctoedu  Partition: 3  Leader: 6 Replicas: 6,1 Isr: 1,6
  Topic: ctoedu  Partition: 4  Leader: 4 Replicas: 4,2 Isr: 4,2
  Topic: ctoedu  Partition: 5  Leader: 2 Replicas: 2,5 Isr: 5,2
  Topic: ctoedu  Partition: 6  Leader: 3 Replicas: 3,6 Isr: 3,6

可以看出broker 7重新变成Partition 1的Leader了

每个partitiion的所有replicas叫做“assigned replicas”，“assigned replicas”中的第一个replicas叫“preferred replica”，刚创建的topic一般“preferred replica”是leader。下图中Partition 0的broker 2就是preferred replica”，默认会成为该分区的leader。

集群leader平衡：

bin/kafka-preferred-replica-election.sh –zookeeper zookeeper_address
auto.leader.rebalance.enable=true

四、集群分区日志迁移

迁移topic数据到其他broker，请遵循下面四步：

1、写json文件,

件格式如下：

cat topics-to-move.json
{"topics": [{"topic": "foo1"},
            {"topic": "foo2"}],
 "version":1
}

2 使用–generate生成迁移计划

（下面的操作是将topic: foo1和foo2移动到broker 5,6）:

bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --topics-to-move-json-file topics-to-move.json --broker-list "5,6" –generate

这一步只是生成计划，并没有执行数据迁移；

使用–execute执行计划：

bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file expand-cluster-reassignment.json –execute

执行前最好保存当前的分配情况，以防出错回滚

3 使用–verify验证是否已经迁移完成

迁移某个topic的某些特定的partition数据到其他broker，步骤与上面一样，但是json文件如下面所示:

cat custom-reassignment.json
{"version":1,"partitions":[{"topic":"foo1","partition":0,"replicas":[5,6]},{"topic":"foo2","partition":1,"replicas":[2,3]}]}

可以指定到topic的分区编号

4

kafka-reassign-partitions.sh工具会复制磁盘上的日志文件，只有当完全复制完成，才会删除迁移前磁盘上的日志文件。执行分区日志迁移需要注意：

• kafka-reassign-partitions.sh 工具的粒度只能到broker，不能到broker的目录(如果broker上面配置了多个目录，是按照磁盘上面已驻留的分区数来均匀分配的)，所以，如果topic之间的数据，或者topic的partition之间的数据本身就不均匀，很有可能造成磁盘数据的不均匀:

• 对于分区数据较多的分区迁移数据会花大量的时间，所以建议在topic数据量较少或磁盘有效数据较少的情况下执行数据迁移操作；

• 进行分区迁移时最好先保留一个分区在原来的磁盘，这样不会影响正常的消费和生产，如果目的是将分区5(brober1,5)迁移到borker2,3。可以先将5迁移到2,1，最后再迁移到2,3。而不是一次将1,5迁移到2,3。因为一次迁移所有的副本，无法正常消费和生产，部分迁移则可以正常消费和生产