Apache kafka 即使在设置log.retention.ms=-1之后，Kafka日志也会被删除

我正在运行一个hyperledger fabric 1.2.0网络，有5个卡夫卡和3个动物园管理员

我面临的问题是，即使设置了

log.retention.ms=-1

，卡夫卡还是删除了一些初始日志。据我所知，将上述值设置为-1后，可以保证日志的永久持久性

我在

docker compose.yaml

中为卡夫卡设置了以下配置

kafka0:
    image: hyperledger/fabric-kafka:amd64-0.4.13
    container_name: kafka0
    environment:
        - KAFKA_LOG_RETENTION_MS=-1
        - KAFKA_MESSAGE_MAX_BYTES=103809024
        - KAFKA_REPLICA_FETCH_MAX_BYTES=103809024
        - KAFKA_BROKER_ID=0
        - KAFKA_ZOOKEEPER_CONNECT=zookeeper0:2181,zookeeper1:2181,zookeeper2:2181
        - KAFKA_UNCLEAN_LEADER_ELECTION_ENABLE=false
        - KAFKA_DEFAULT_REPLICATION_FACTOR=3
        - KAFKA_MIN_INSYNC_REPLICAS=2
    ports:
        - 9000:9092
    networks:
      - byfn

其他Kafka容器的类似配置。下面是我重新启动任何Kafka容器时得到的配置

    background.threads = 10
    broker.id = 3
    broker.id.generation.enable = true
    compression.type = producer
    connections.max.idle.ms = 600000
    controlled.shutdown.enable = true
    controlled.shutdown.max.retries = 3
    controlled.shutdown.retry.backoff.ms = 5000
    controller.socket.timeout.ms = 30000
    create.topic.policy.class.name = null
    default.replication.factor = 3
    delete.records.purgatory.purge.interval.requests = 1
    delete.topic.enable = true
    fetch.purgatory.purge.interval.requests = 1000
    group.initial.rebalance.delay.ms = 0
    group.max.session.timeout.ms = 300000
    group.min.session.timeout.ms = 6000
    host.name =
    inter.broker.listener.name = null
    inter.broker.protocol.version = 1.0-IV0
    leader.imbalance.check.interval.seconds = 300
    leader.imbalance.per.broker.percentage = 10
    listener.security.protocol.map = PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
    listeners = null
    log.cleaner.backoff.ms = 15000
    log.cleaner.dedupe.buffer.size = 134217728
    log.cleaner.delete.retention.ms = 86400000
    log.cleaner.enable = true
    log.cleaner.io.buffer.load.factor = 0.9
    log.cleaner.io.buffer.size = 524288
    log.cleaner.io.max.bytes.per.second = 1.7976931348623157E308
    log.cleaner.min.cleanable.ratio = 0.5
    log.cleaner.min.compaction.lag.ms = 0
    log.cleaner.threads = 1
    log.cleanup.policy = [delete]
    log.dir = /tmp/kafka-logs
    log.dirs = /tmp/kafka-logs
    log.flush.interval.messages = 9223372036854775807
    log.flush.interval.ms = null
    log.flush.offset.checkpoint.interval.ms = 60000
    log.flush.scheduler.interval.ms = 9223372036854775807
    log.flush.start.offset.checkpoint.interval.ms = 60000
    log.index.interval.bytes = 4096
    log.index.size.max.bytes = 10485760
    log.message.format.version = 1.0-IV0
    log.message.timestamp.difference.max.ms = 9223372036854775807
    log.message.timestamp.type = CreateTime
    log.preallocate = false
    log.retention.bytes = -1
    log.retention.check.interval.ms = 300000
    log.retention.hours = 168
    log.retention.minutes = null
    log.retention.ms = -1
    log.roll.hours = 168
    log.roll.jitter.hours = 0
    log.roll.jitter.ms = null
    log.roll.ms = null
    log.segment.bytes = 1073741824
    log.segment.delete.delay.ms = 60000
    max.connections.per.ip = 2147483647
    max.connections.per.ip.overrides =
    message.max.bytes = 103809024
    metric.reporters = []
    metrics.num.samples = 2
    metrics.recording.level = INFO
    metrics.sample.window.ms = 30000
    min.insync.replicas = 2
    num.io.threads = 8
    num.network.threads = 3
    num.partitions = 1
    num.recovery.threads.per.data.dir = 1
    num.replica.fetchers = 1
    offset.metadata.max.bytes = 4096
    offsets.commit.required.acks = -1
    offsets.commit.timeout.ms = 5000
    offsets.load.buffer.size = 5242880
    offsets.retention.check.interval.ms = 600000
    offsets.retention.minutes = 1440
    offsets.topic.compression.codec = 0
    offsets.topic.num.partitions = 50
    offsets.topic.replication.factor = 1
    offsets.topic.segment.bytes = 104857600
    port = 9092
    principal.builder.class = null
    producer.purgatory.purge.interval.requests = 1000
    queued.max.request.bytes = -1
    queued.max.requests = 500
    quota.consumer.default = 9223372036854775807
    quota.producer.default = 9223372036854775807
    quota.window.num = 11
    quota.window.size.seconds = 1
    replica.fetch.backoff.ms = 1000
    replica.fetch.max.bytes = 103809024
    replica.fetch.min.bytes = 1
    replica.fetch.response.max.bytes = 10485760
    replica.fetch.wait.max.ms = 500
    replica.high.watermark.checkpoint.interval.ms = 5000
    replica.lag.time.max.ms = 10000
    replica.socket.receive.buffer.bytes = 65536
    replica.socket.timeout.ms = 30000
    replication.quota.window.num = 11
    replication.quota.window.size.seconds = 1
    request.timeout.ms = 30000
    reserved.broker.max.id = 1000
    security.inter.broker.protocol = PLAINTEXT
    socket.receive.buffer.bytes = 102400
    socket.request.max.bytes = 104857600
    socket.send.buffer.bytes = 102400
    transaction.abort.timed.out.transaction.cleanup.interval.ms = 60000
    transaction.max.timeout.ms = 900000
    transaction.remove.expired.transaction.cleanup.interval.ms = 3600000
    transaction.state.log.load.buffer.size = 5242880
    transaction.state.log.min.isr = 1
    transaction.state.log.num.partitions = 50
    transaction.state.log.replication.factor = 1
    transaction.state.log.segment.bytes = 104857600
    transactional.id.expiration.ms = 604800000
    unclean.leader.election.enable = false
    zookeeper.connect = zookeeper0:2181,zookeeper1:2181,zookeeper2:2181
    zookeeper.connection.timeout.ms = 6000
    zookeeper.session.timeout.ms = 6000
    zookeeper.set.acl = false
    zookeeper.sync.time.ms = 2000

我的卡夫卡版本是

1.13.0

。以下是您可能会发现与问题相关的有用日志

INFO Incrementing log start offset of partition mychannel-0 to 30457 in dir /tmp/kafka-logs (kafka.log.Log)
INFO Cleared earliest 0 entries from epoch cache based on passed offset 30457 leaving 6 in EpochFile for partition mychannel-0 (kafka.server.epoch.LeaderEpochFileCache)
INFO Updated PartitionLeaderEpoch. New: {epoch:13, offset:8621}, Current: {epoch:12, offset8618} for Partition: mychannel1-0. Cache now contains 5 entries. (kafka.server.epoch.LeaderEpochFileCache)
INFO [GroupMetadataManager brokerId=1] Removed 0 expired offsets in 0 milliseconds. (kafka.coordinator.group.GroupMetadataManager)
INFO Found deletable segments with base offsets [0,4883,7464,22368,25071,26892] due to log start offset 30457 breach (kafka.log.Log)
INFO Scheduling log segment 0 for log mychannel-0 for deletion. (kafka.log.Log)
INFO Scheduling log segment 4883 for log mychannel-0 for deletion. (kafka.log.Log)
INFO Scheduling log segment 7464 for log mychannel-0 for deletion. (kafka.log.Log)
INFO Scheduling log segment 22368 for log mychannel-0 for deletion. (kafka.log.Log)
INFO Scheduling log segment 25071 for log mychannel-0 for deletion. (kafka.log.Log)
INFO Scheduling log segment 26892 for log mychannel-0 for deletion. (kafka.log.Log)
INFO Deleting segment 0 from log mychannel-0. (kafka.log.Log)
INFO Deleting segment 4883 from log mychannel-0. (kafka.log.Log)
INFO Deleting segment 7464 from log mychannel-0. (kafka.log.Log)
INFO Deleting segment 22368 from log mychannel-0. (kafka.log.Log)
INFO Deleting segment 25071 from log mychannel-0. (kafka.log.Log)
INFO Deleting segment 26892 from log mychannel-0. (kafka.log.Log)
INFO Deleting index /tmp/kafka-logs/mychannel-0/00000000000000026892.index.deleted (kafka.log.OffsetIndex)
INFO Deleting index /tmp/kafka-logs/mychannel-0/00000000000000022368.index.deleted (kafka.log.OffsetIndex)
INFO Deleting index /tmp/kafka-logs/mychannel-0/00000000000000026892.timeindex.deleted (kafka.log.TimeIndex)
INFO Deleting index /tmp/kafka-logs/mychannel-0/00000000000000022368.timeindex.deleted (kafka.log.TimeIndex)
INFO Deleting index /tmp/kafka-logs/mychannel-0/00000000000000025071.index.deleted (kafka.log.OffsetIndex)
INFO Deleting index /tmp/kafka-logs/mychannel-0/00000000000000000000.index.deleted (kafka.log.OffsetIndex)
INFO Deleting index /tmp/kafka-logs/mychannel-0/00000000000000007464.index.deleted (kafka.log.OffsetIndex)
INFO Deleting index /tmp/kafka-logs/mychannel-0/00000000000000004883.index.deleted (kafka.log.OffsetIndex)
INFO Deleting index /tmp/kafka-logs/mychannel-0/00000000000000025071.timeindex.deleted (kafka.log.TimeIndex)
INFO Deleting index /tmp/kafka-logs/mychannel-0/00000000000000000000.timeindex.deleted (kafka.log.TimeIndex)
INFO Deleting index /tmp/kafka-logs/mychannel-0/00000000000000007464.timeindex.deleted (kafka.log.TimeIndex)
INFO Deleting index /tmp/kafka-logs/mychannel-0/00000000000000004883.timeindex.deleted (kafka.log.TimeIndex)

据报道,

log.cleaner.enable

在服务器上运行日志清理程序。如果使用具有 cleanup.policy=compact，包括内部偏移主题。如果 禁用这些主题将不会被压缩并在中不断增长 尺寸

我建议你去

log.cleaner.enable=false

然后重新启动Kafka群集

然而，这甚至会对卡夫卡内部的话题产生影响。或者，您可以尝试仅对感兴趣的主题禁用保留：

$ bin/kafka-topics.sh --zookeeper zookeeperHost:2181 --alter --topic mytopic --config retention.ms=-1
$ bin/kafka-topics.sh --zookeeper zookeeperHost:2181 --alter --topic mytopic --config retention.hours=-1
$ bin/kafka-topics.sh --zookeeper zookeeperHost:2181 --alter --topic mytopic --config retention.bytes=-1

PS：在您的日志中，我可以看到

log.retention.hours

设置为

168

，可能这就是

log.retention.ms=-1

无效的原因。

根据

log.cleaner.enable

在服务器上运行日志清理程序。如果使用具有 cleanup.policy=compact，包括内部偏移主题。如果 禁用这些主题将不会被压缩并在中不断增长 尺寸

我建议你去

log.cleaner.enable=false

然后重新启动Kafka群集

然而，这甚至会对卡夫卡内部的话题产生影响。或者，您可以尝试仅对感兴趣的主题禁用保留：

$ bin/kafka-topics.sh --zookeeper zookeeperHost:2181 --alter --topic mytopic --config retention.ms=-1
$ bin/kafka-topics.sh --zookeeper zookeeperHost:2181 --alter --topic mytopic --config retention.hours=-1
$ bin/kafka-topics.sh --zookeeper zookeeperHost:2181 --alter --topic mytopic --config retention.bytes=-1

---

PS：在您的日志中，我可以看到

log.retention.hours

设置为

168

，这可能就是

log.retention.ms=-1

无效的原因。

设置log.retention.ms=-1是否会覆盖log.retention.hours？log.retention.hours=168是默认值，但我已将其覆盖。另外，容器是在2个月前生成的，日志清理是在几天前开始的。168小时意味着7天。显然，情况并非如此。你能解释一下log.cleaner.enable=false吗。它的作用以及它将如何影响容器？现在我们知道retention.hours=168不是这样，log.cleaner.enable=false是否与问题相关？@KartikChauhan是的，

log.cleaner.enable

与日志压缩相关。但是我的retention.policy设置为“delete”。将其设置为compact可能是未来的正确步骤，但当前的情况如何？我不明白卡夫卡为什么要删减以前的日志？你能描述一下主题并分享输出吗？设置log.retention.ms=-1是否会覆盖log.retention.hours？log.retention.hours=168是默认值，但我已将其覆盖。另外，容器是在2个月前生成的，日志清理是在几天前开始的。168小时意味着7天。显然，情况并非如此。你能解释一下log.cleaner.enable=false吗。它的作用以及它将如何影响容器？现在我们知道retention.hours=168不是这样，log.cleaner.enable=false是否与问题相关？@KartikChauhan是的，

log.cleaner.enable

与日志压缩相关。但是我的retention.policy设置为“delete”。将其设置为compact可能是未来的正确步骤，但当前的情况如何？我不明白卡夫卡为什么要删掉以前的日志？你能描述一下主题并分享结果吗？