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

时间:2019-05-23 14:25:58

标签: apache-kafka hyperledger-fabric

我正在运行具有5个Kafkas和3个Zookeeper的Hyperledger Fabric 1.2.0网络。

即使设置了PIPESTATUS,我仍然面临的问题是,Kafka删除了一些初始日志。据我所知,将上述值设置为-1后,将确保日志的永久持久性。

我在log.retention.ms = -1中为Kafkas设置了以下配置。

docker-compose.yaml

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

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版本是 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

1 个答案:

答案 0 :(得分:0)

根据Kafka Docs

  

log.cleaner.enable 启用日志清除器进程以在服务器上运行。如果将任何主题与   cleanup.policy = compact包括内部偏移量主题。如果   禁用这些主题将不会被压缩,并且会持续增长   大小。

我建议设置

log.cleaner.enable=false

并重新启动您的Kafka集群。

但是,这甚至会影响内部的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无效的原因。