KafKa集群节点启动失败的故障处理过程

IT那活儿 2023-06-28

1546

点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！

故障场景

因机房出现某种故障，主机出现磁盘只读情况，kafka集群受到影响，三台kafka节点中节点2因磁盘只读故障kafka节点挂掉，正常启动后，节点3挂掉无法启动。

故障分析

1. 启动kafka报错提示

通过上图报错提示‘Cannot allocate memory’，内存也足够，尝试修改启动内存，分别改为2G、256M启动kafka依旧存在相同的问题：

Kafka/bin/kafka-server-start.sh
export KAFKA_HEAP_OPTS="-Xmx2G -Xms2G"

export KAFKA_HEAP_OPTS="-Xmx256M -Xms256M"

排除内存原因，上图报错‘Error while flushing log for metric_values_transformed_err-0 in dir data/shsnc/snc_product/kafka/data with offset 7615179553’，排查kafka复制线程在加载topic metric_values_transformed_err的分区数据时失败。

2. 查看Kafka分区数

查看kafka的分区数是6，副本为1。

kafka./bin/kafka-topics.sh --describe --zookeeper 
localhost:2181 --topic metric_values_transformed_err

对比四个分区文件，没有出现缺失情况：

3. 尝试通过重新选举leader进行恢复

修改配置文件config/server.properties

##为true时,producer像未存在的topic发送消息会自动创建topic,一般建议是false,不允许自动创建topic。

auto.create.topics.enable=false

由于kafka节点挂掉时间过长，尝试重新选举leader，修改如下参数：

unclean.leader.election.enable=true

修改上述参数后，kafka节点3启动依旧失败，报错提示未发生变化。

4. 查看消费topic的服务日志

日志文件中报错提示在处理TOPIC分区metric_values_transformed_err-0的偏移位7615104188 消息时出错，无法消费此offset数据。

尝试启动kafka服务器失败，服务进程拉起后提示 loading data 异常，之后被shutdown, 可能的原因是metric_values_transformed_err-0 分区数据文件缺失或损坏。

无法跳过出错的offset。Spark程序无法消费topic metric_values_transformed_err主题数据。

通过分析可知，kafka复制线程在加载topic metric_values_transformed_err的分区数据时失败，metric_values_transformed_err-0分区数据损坏，并且对业务有影响。

只有两种解决方案：

针对metric_values_transformed_err主题进行重新分配分区。
删除topic：metric_values_transformed_err，并重构topic：metric_values_transformed_err。

针对本次的topic分区损坏问题，我们选择了方案A进行处理。

故障处理

1. 针对metric_values_transformed_err主题进行重新分配分区

Kafka共3个节点，先尝试分在节点1和节点2上。

1）创建一个reassign.json的文件

vi  reassign.json
{
        "topics":[
                {
                        "topic": "metric_values_transformed_err"
                }
        ],
        "version":1
}

2）根据JSON文件和指定所要分配的broker节点列表来生成一份候选的重分配方案

kafka/bin/kafka-reassign-partitions.sh --zookeeper 、localhost:2181 --generate --topics-to-move-json-file reassign.json --broker-list '0,1,2'

上面示例中打印处两个JSON内容，一个是当前分区分配情况，一个是重新分配的候选方案。这里只是生成方案，并没有执行。生成可行性方案的具体算法和创建主题时一样。

将生成的第二个json内容，保存到json文件中，project.json。

3）执行具体的分配动作

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

4）验证是否完成

kafka/bin/kafka-reassign-partitions.sh --zookeeper 
localhost:2181 --verify --reassignment-json-file project.json

分区文件正常更新，验证正常。

2. Kafka节点启动验证

1）Kafka启动正常

2）消费kafka的spark程序日志正常

通过上面的步骤我们修复 TOPIC metric_values_transformed_err 的分区数据，将业务流量切换到kafka Broker0和Broker1集群节点上。

待metric_values_transformed_err 分区数据迁移完成后 broker0、broker1节点后，检查此时生产者可往代理1、代理2节点生产数据。由于此时故障节点代理3节点相当于已剔除集群。

metric_values_transformed_err 主题的分区落到正常的代理1、代理2上。代理3为孤立节点。且可查看到正常节点的数据写入ok。

所以此时，我们需要将主题的 TOPIC metric_values_transformed_err 的分区数据进行再平衡，使其分区数均衡到 kafka集群三个节点。

END

本文作者：事业二部(上海新炬中北团队）

本文来源：“IT那活儿”公众号

文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。