Question

请注意，我已经阅读了很多以下文章，并试图在不同的论坛上找到相关信息，但没有成功： https://medium.com/@anishekagarwal/kafka-log-cleaner-issues-80a05e253b8a 希望您能理解我的问题并提供一些线索=）

这是故事：

几天前，我们在kafka集群上部署了重复数据删除服务。由于使用了该服务，因此我们注意到__consumer_offsets主题开始增长。原因是日志清理器（用于压缩本主题等）的确崩溃了，并显示以下错误： java.lang.IllegalStateException：此日志包含一条消息，该消息大于最大允许大小1000012

根据我们的了解，我们首先认为这是消息大小问题，因此我们增加了max.messsage.bytes（直到20 MB以上）值，但随后又遇到了同样的问题（错误消息已正确更新为新值）。

因此我们开始认为这可能是某种“损坏的”邮件大小值或“误解的段”（例如kafka日志清理器版本无法正确处理该邮件）

我们能够隔离导致问题的细分的偏移量。之所以如此奇怪，是因为当我们用一个简单的使用者使用它时，记录约为4K字节，但是使用者仅用了7或8分钟就消耗了该记录（在此轮询期间，tcpdump清楚地显示了许多> 1000字节的数据包即将到来来自经纪人）。

因此，我们开始使用dumpSegment类查看该段，它看起来像这样（我替换了一些值以进行匿名化）：

Dumping 00000000004293321003.log

Starting offset: 4293321003

baseOffset: 4310760245 lastOffset: 4310760245 count: 1 baseSequence: -1 lastSequence: -1 producerId: 66007 producerEpoch: 2 partitionLeaderEpoch: 50 isTransactional: true isControl: true position: 0 CreateTime: 1556544968606 size: 78 magic: 2 compresscodec: NONE crc: 2072858171 isvalid: true

| offset: 4310760245 CreateTime: 1556544968606 keysize: 4 valuesize: 6 sequence: -1 headerKeys: [] endTxnMarker: COMMIT coordinatorEpoch: 0

baseOffset: 4310760295 lastOffset: 4310760295 count: 1 baseSequence: -1 lastSequence: -1 producerId: 65010 producerEpoch: 2 partitionLeaderEpoch: 50 isTransactional: true isControl: true position: 78 CreateTime: 1556544968767 size: 78 magic: 2 compresscodec: NONE crc: 2830498104 isvalid: true

| offset: 4310760295 CreateTime: 1556544968767 keysize: 4 valuesize: 6 sequence: -1 headerKeys: [] endTxnMarker: COMMIT coordinatorEpoch: 0

baseOffset: 4310760731 lastOffset: 4310760731 count: 1 baseSequence: -1 lastSequence: -1 producerId: 64005 producerEpoch: 2 partitionLeaderEpoch: 50 isTransactional: true isControl: true position: 156 CreateTime: 1556544969525 size: 78 magic: 2 compresscodec: NONE crc: 3044687360 isvalid: true

| offset: 4310760731 CreateTime: 1556544969525 keysize: 4 valuesize: 6 sequence: -1 headerKeys: [] endTxnMarker: COMMIT coordinatorEpoch: 0

baseOffset: 4310760732 lastOffset: 4310760732 count: 1 baseSequence: -1 lastSequence: -1 producerId: 66009 producerEpoch: 2 partitionLeaderEpoch: 50 isTransactional: true isControl: true position: 234 CreateTime: 1556544969539 size: 78 magic: 2 compresscodec: NONE crc: 1011583163 isvalid: true

| offset: 4310760732 CreateTime: 1556544969539 keysize: 4 valuesize: 6 sequence: -1 headerKeys: [] endTxnMarker: COMMIT coordinatorEpoch: 0

所以我们看到了很多像上面的束

然后是导致日志清理器崩溃的错误偏移量：

baseOffset: 4740626096 lastOffset: 4740626096 count: 1 baseSequence: -1 lastSequence: -1 producerId: -1 producerEpoch: -1 partitionLeaderEpoch: 50 isTransactional: false isControl: false position: 50471272 CreateTime: 1557322162912 size: 4447 magic: 2 compresscodec: NONE crc: 3030806995 isvalid: true

| offset: 4740626096 CreateTime: 1557322162912 keysize: 25 valuesize: 4352 sequence: -1 headerKeys: [] key: {"metadata":"MYGROUPID"} payload: {"protocolType":"consumer","protocol":"range","generationId":32,"assignment":"{CLIENTID=[TOPICA-0, TOPICA-1, TOPICA-2, TOPICA-3, TOPICA-4, TOPICA-5, TOPICA-6, TOPICA-7, TOPICA-8, TOPICA-9, TOPICA-10, TOPICA-11], AND THIS FOR ABOUT 10 OTHER TOPICS}"}  ==> approximative 4K bytes

这看起来不像标准的__consumer_offsets数据架构（[groupId，topicName，partitionNumber] :: offset架构），我认为这是因为新服务使用了kafka事务。

我们认为此崩溃可能是由于我们的kafka群集为0.9.11（或可能为1.0.1）并且我们的重复数据删除服务正在使用kafka 2.0.0 API（并使用事务）造成的。

所以在这里我有一些疑问：

在处理kafka事务时，__consumer_offsets主题如何处理已提交的偏移量？我根本没有结构。似乎有多个COMMIT标记消息（但不知道它是什么主题或分区。所以，这是怎么工作的：/？）总是跟在此非transactionnnal记录之后，包括元数据标签。有关此结构的任何文档吗？
0.9.11（或1.0.1）kafka集群的日志清理器版本是否可能无法正确处理__consumer_offsets（由2.0.0 API提供）中的那种事务性消息？

在这里欢迎任何提示/纠正。

Regads

Yannick

Answer 1

经过一些研究，我找到了为什么会有这种行为并找到了解决方法。

这是一个众所周知的kafka错误，至少会影响1.1.0版本的Kafka：https://issues.apache.org/jira/browse/KAFKA-6854

解决方案：简单的方法是升级到版本2（或在Jira中看到的1.1.1版本）。

这是因为段中充满了事务标记，并且在达到删除保留时间以摆脱这些标记的同时，压缩期间LogCleaner崩溃了（尝试将其缓冲区多次加倍）

如果您想进一步了解细分结构以及LogCleaner崩溃的确切方式，请参见本文的更多信息和研究：

https://medium.com/@ylambrus/youve-got-a-friend-logcleaner-1fac1d7ec04f

Yannick

卡夫卡原木清洁器崩溃

1 个答案: