从磁盘已满错误中恢复 Kafka 集群

Recovering Kafka Cluster from a disk full error

我们有一个 3 节点的 Kafka 集群。对于数据存储,我们在每个 3 节点中安装了 2 个磁盘 - /data/disk1/data/disk2kafka.properties中的log.dirs设置为:

log.dirs=/data/disk1/kafka-logs,/data/disk2/kafka-logs

碰巧在其中一个节点 Node1 中,磁盘分区 /data/disk2/kafka-logs100% 已满。

发生这种情况的原因是 - 我们正在将数据从 filebeat 重播到 kafka 主题,并且在很短的时间内推送了大量数据。我已将该主题的保留时间从 7 days 暂时更改为 1 day,因此主题大小已变为正常。

问题是 - 在 Node1/data/disk2/kafka-logs 100% 已满,kafka 进程无法启动并发出错误:

Jul 08 12:03:29 broker01 kafka[23949]: [2019-07-08 12:03:29,093] INFO Recovering unflushed segment 0 in log my-topic-0. (kafka.log.Log)
Jul 08 12:03:29 broker01 kafka[23949]: [2019-07-08 12:03:29,094] INFO Completed load of log my-topic-0 with 1 log segments and log end offset 0 in 2 ms (kafka.log.Log)
Jul 08 12:03:29 broker01 kafka[23949]: [2019-07-08 12:03:29,095] ERROR There was an error in one of the threads during logs loading: java.lang.InternalError: a fault occurred in a recent unsafe memory access operation in compiled Java code (kafka.log.LogManager)
Jul 08 12:03:29 broker01 kafka[23949]: [2019-07-08 12:03:29,101] FATAL [Kafka Server 1], Fatal error during KafkaServer startup. Prepare to shutdown (kafka.server.KafkaServer)
Jul 08 12:03:29 broker01 kafka[23949]: java.lang.InternalError: a fault occurred in a recent unsafe memory access operation in compiled Java code
Jul 08 12:03:29 broker01 kafka[23949]: at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:57)
Jul 08 12:03:29 broker01 kafka[23949]: at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
Jul 08 12:03:29 broker01 kafka[23949]: at org.apache.kafka.common.record.FileLogInputStream$FileChannelLogEntry.loadRecord(FileLogInputStream.java:135)
Jul 08 12:03:29 broker01 kafka[23949]: at org.apache.kafka.common.record.FileLogInputStream$FileChannelLogEntry.record(FileLogInputStream.java:149)
Jul 08 12:03:29 broker01 kafka[23949]: at kafka.log.LogSegment.$anonfun$recover(LogSegment.scala:22

大多数主题的复制因子是 23。所以,我想知道我是否可以执行以下操作:

  1. 将所有主题的复制因子更改为 2(节点 2 和节点 3 运行 很好)
  2. delete 来自 Node1 的一些东西。
  3. 重启Node 1
  4. 将复制因子改回 23,与最初的情况一样。

有谁知道更好的方法或更好的建议吗?

更新:需要步骤 1 和 4 not。如果您有副本,只需 23 就足够了。

您的问题(以及相应的解决方案)类似于此问题中描述的问题:kafka 0.9.0.1 fails to start with fatal exception

最简单快捷的方法是删除部分数据。当代理启动时,将使用新的保留复制数据。

So, I'm wondering if I can do the following...

具体回答您的问题 - 是的,您可以按顺序执行您描述的步骤,这将有助于 return 集群达到一致状态。

为防止以后再发生这种情况,您可以尝试使用参数log.retention.bytes代替log.retention.hours,虽然我认为对日志使用size-based保留策略不是最好的选择,因为正如我的实践表明在大多数情况下需要知道主题至少存储在哪个时间集群。