基于Kafka->Hudi数据抽取引发的一系列问题排查
在消费Kafka的时候,有如下报错:
Caused by: org.apache.kafka.clients.consumer.OffsetOutOfRangeExecption: Offset out of range with no configured reset policy for partitions: {topicName-partitionNum=offset}
无论是写入新Hoodie表还是旧表,均会产生此报错,也只是某些topic有这个问题
观察Kafka的Manager Web页面我们发现,存在问题的topic某些分区对应的ISR序列有缺失,初步怀疑是leader副本与ISR其他副本通信超时导致HW较低,于是决定修改Kafka核心配置参数:replica.lag.time.max.ms,其默认值为10000ms,我们改为20000ms
重启Kafka集群之后,发现slave17的硬盘坏了,但数据并没有丢失,紧接着slave16重启失败,报错某些topic的副本同步leader副本消息时,offset大于leader副本offset
所以我们怀疑是Kafka集群中某leader副本节点宕机,即slave16宕机,导致leader副本被Controller从ISR队列中移除,并选择另外两个副本其中一个作为leader参与生产与消费
但是在所有follower副本完全同步leader副本的情况下,不会存在offset相差的问题
进一步排查,发现kafka的ack机制设置为1,即folldwer副本不会同步leader副本
验证了我们的猜想
leader副本在退出ISR序列之后,之前未同步leader的副本被选为leader,即该副本的offset小于之前在__consumer_offset主题中记录的偏移量,并且该节点宕机数天,Kafka已经堆积了数亿条数据,按照线上每次抽取500万的情况来看,需要数次,该副本的offset才会追赶上之前记录的offset值
另外,怀疑节点宕机可能会引发的controlled unclean shutdown 导致leader选举问题,有待验证