一、Kafka Controller简介
kafka集群会选举出一个称为Controller的节点,主要有以下几种作用:
- 主题管理:创建、删除主题等等
- 重分区:前面脚本执行分区就是靠控制器实现的
- 集群成员管理:broker新增、关闭、宕机
- 数据管理:元数据管理。
目前对Controller的了解不多,我们在进行prometheus监控的时候发现,只有controller节点才可以获取partition的数据,也许就和controller的功能有关。
二、节点宕机变化过程
1、查看controller节点
进入zookeeper机器,进入bin,启动./zkCli.sh
$ ls /
$ get /controller
可以得到zookeeper上注册的kafka controller信息:
{"version":1, "brokerid":1, "timestamp":"1578635987138"}
2、查看当前主题分区情况
./kafka-topics.sh --describe --zookeeper zookeeper1.tplinknbu.com |grep subsub
例如一个主题tpc.subunsub:
分区数量12个,副本因子3,列出了每个分区中的Leader(可以看出是轮换的)。分区中的所有副本称为AR(Assigned Repllicas, AR),Follower副本总是去同步Leader副本,且有一定滞后。所有与Leader副本保持一定程度同步的副本都称为同步副本(In-Sync Replicas, ISR),而同步程度滞后过多的副本称为失步副本(Out-Sync Replicas)。只有ISR有资格被选举为Leader。可以看出,这里都是同步副本。
3、停止节点2(非Controller节点)
我们停止节点2,现象:
(1)Controller没有变化
(2)kafka仍然可用,且使用Spring kafka的业务不会抛出异常
(3)节点2从ISR中被剔除,且没有资格再成为Leader
Leader: 3 Replicas: 2,3,1 Isr: 3,1
4、再次启动节点2
(1)刚启动的时候,节点2立刻同步到ISR状态,但Leader没有变化
Leader: 3 Replicas: 2,3,1 Isr: 3,1,2
Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
……
(2)过一段时间,自动均匀分布Leader。
Leader: 2 Replicas: 2,3,1 Isr: 3,1,2
Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
……
5、Controller节点宕机
我们停止Controller节点1,现象:
(1)zookeeper上的controller值立刻变为3,但version没有变化(version固定为1,controller_epoch才会随着每次控制器变化而+1)
{"version":1, "brokerid":3, "timestamp":"1582545775134"}
(2)Isr有一些残留,但Leader全部剔除1
Leader: 2 Replicas: 2,3,1 Isr: 3,1,2
Leader: 3 Replicas: 3,1,2 Isr: 2,3
……
(3)一段时间后,Isr仍然残留有1(应该是对于没有太大变化的partition,仍然认为是同步的)
6、Controller节点恢复
类似节点2启动,只是此时节点1已经是普通节点。
(1)刚启动时,迅速同步到ISR中
(2)过一段时间,均匀分布Leader。
三、不停机磁盘扩容
这里以AWS的EC2机器为例:
1、修改卷大小
(1)点击EC2下面的详细信息的跟设备的EBS ID,跳转到卷列表
(2)点击修改卷,修改为想要的大小,例如50GB
2、主机内扩容
修改完毕后,进入主机,根据官方文档《Extending a Linux File System After Resizing a Volume》找到具体扩容命令,例如m5.large的为:
sudo growpart /dev/nvme0n1 1
sudo resize2fs /dev/nvme0n1p1
磁盘的名称可以通过:
$ lsblk
来查看。
3、确认修改完成
$ df -lh
四、停机修改实例规模
修改实例规模必须要停机,好在kafka集群可以提供高可用,需要注意不要在波峰的时候去停机,多观察消费情况,避免停机一台造成另外两台收到大量请求宕机导致整个集群都宕机…
可以采取"创建1台、再停机1台"的方式,尽量避免“停机1台,扩容,再启动”的方式。
EC2修改很简单,只需要点右键修改实例规模即可。
五、有关kafka磁盘估算
kafka的磁盘收到3个因素影响:
(1)每个patition最大大小
(2)删除策略
(3)主题数量及patition个数
对于第1个,通常设置1GB没问题;
对于第2个,通常设置都是24小时或者默认7天进行清理,清理方式通常都是删除(也可以设置为压缩,但建议删除)
对于第3个,很关键,一定要注意最后的最大磁盘使用量是(所有主题对应partition个数之和)×每个partition最大大小。
我最开始误以为是partition个数×每个partition最大大小,于是给了50GB,性能测试很快就满了。
仔细想一想也可以知道,partition个数是可以每个主题不同的,所以最后应该是所有主题的partition个数加起来再乘以partition最大大小。