2021-07-08

基于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选举问题，有待验证