Apache kafka 由于文件损坏，Kafka broker无法重新启动

如何从卡夫卡中损坏的文件中恢复

我们正在运行一个复制因子为2且ISR=1的三节点群集。最近我们几乎同时失败，所有经纪人都是同一时间。这导致了一种情况，即代理id 102已关闭，而其他两个代理已恢复。不幸的是，一个主题中至少有一个分区有102个作为领导者，isr也只有102个。这意味着其他代理缺少来自该分区的一些（未知）数据量，因此它们拒绝接收/发送来自该主题的数据

因为我想恢复我的集群和数据，所以我正在尝试重新启动broker 102。但它在使用此mesage的未知文件上失败

[2018-07-18 14:44:44806]错误加载日志期间，其中一个线程中出现错误：org.apache.kafka.common.KafkaException:java.io.eofeexception:未能从文件通道'sun.nio'读取'log header'。
中国。FileChannelImpl@375a9d12`. 应读取17个字节，但在读取0个字节后到达文件末尾。从位置2147483631开始读取。（kafka.log.LogManager）
[2018-07-18 14:44:44809]错误[KafkaServer id=102]KafkaServer启动期间出现致命错误。准备关闭（kafka.server.KafkaServer）
org.apache.kafka.common.KafkaException:java.io.eofeexception:未能从文件通道'sun.nio.ch'读取'log header'。FileChannelImpl@375a9d12`. 应读取17个字节，但在读取后到达文件末尾
0字节。从位置2147483631开始读取。

不幸的是，这并没有告诉我哪个文件坏了。我反复尝试重新启动broker 102，希望它所做的所有重新索引都能以某种方式恢复文件，但没有成功

我的猜测是，有问题的文件是而不是来自102为其死前导的分区。所以我在想

a） 我可以删除102上的所有日志文件吗？对于102不是主要分区的分区，当它重新联机时，它将简单地重新同步而没有问题

b） 如果我找到了正确的文件并将其删除，是否可以重新启动102

---

c） 有没有办法确定卡夫卡阻塞了哪个文件？

在一个3节点群集上使用RF=2和ISR=1可能会导致分区收缩到1节点时出现不一致的状态，而在此期间更改前导可能会导致2个节点接受作为前导的写入。因此，您可能会获得两个版本的历史。
为了保证一致性，您可能更希望在未来RF=3和ISR=2，acks=all

您可以尝试使用

DumpLogSegments

实用程序检查

102

日志文件的有效性，并从中转储数据：

bin/kafka-run-class.sh kafka.tools.DumpLogSegments --files 000000000000000xxx.log

解析日志文件并将其内容转储到控制台，这对于调试看似损坏的日志段非常有用

---

您需要向当前的分区领导代理检查哪些消息不存在，然后重新发布它们

我们使用DumpLogSegments成功地做到了这一点，但困难的部分是找出需要检查的数千个日志文件中的哪一个。Kafka会简单地失败，但不会指定是哪个文件导致了问题。对于数十TB的分区，这可能需要很长时间。我同意我们需要RF=3、ISR=2和acks=all。我们没有启用不干净的领导人选举，因此我们没有获得多个历史记录，但我们确实有几个小时的停机时间……DumpLogSegments解决方案帮助确定哪些日志文件已损坏，但Kafka现在正在永久恢复。