我们正在Linux机器上安装新的Apache Kafka-＜code＞2.7版本集群中的Kafka机器总数为-5台
现在安装完成，但我们注意到并非所有ISR都在同步中
我想分享所有原因，也许可以解释导致副本不同步的原因
慢副本：跟随者副本在一段时间内始终无法赶上前导文件上的写入。最常见的原因之一是跟随者副本上的I/O瓶颈，导致它附加复制消息的速度低于从前导文件消耗的速度。
卡住的副本：在一段时间内停止从首领那里获取的跟随者副本。复制副本可能由于GC暂停或失败或失效而被卡住。
自举副本:当用户增加主题的复制因子时，新的追随者副本不同步，直到它们完全赶上领导者的日志。
但由于我们正在处理新的scratch Kafka集群，所以我想知道不同步的ISR问题是否与Kafka服务器中的一些参数有关。属性也没有设置
以下是关于< code>__consumer_offsets主题的示例，我们可以看到许多ISR的缺失
Topic:__consumer_offsets PartitionCount:50 ReplicationFactor:3 Configs:segment.bytes=104857600,cleanup.policy=compact,compression.type=producer
Topic: __consumer_offsets Partition: 0 Leader: 1003 Replicas: 1003,1001,1002 Isr: 1003,1001,1002
Topic: __consumer_offsets Partition: 1 Leader: 1001 Replicas: 1001,1002,1003 Isr: 1001,1003,1002
Topic: __consumer_offsets Partition: 2 Leader: 1003 Replicas: 1002,1003,1001 Isr: 1003,1001
Topic: __consumer_offsets Partition: 3 Leader: 1003 Replicas: 1003,1002,1001 Isr: 1003,1001
Topic: __consumer_offsets Partition: 4 Leader: 1001 Replicas: 1001,1003,1002 Isr: 1001,1003
Topic: __consumer_offsets Partition: 5 Leader: 1001 Replicas: 1002,1001,1003 Isr: 1003,1001,1002
Topic: __consumer_offsets Partition: 6 Leader: 1003 Replicas: 1003,1001,1002 Isr: 1003,1001,1002
Topic: __consumer_offsets Partition: 7 Leader: 1001 Replicas: 1001,1002,1003 Isr: 1001,1003,1002
Topic: __consumer_offsets Partition: 8 Leader: 1003 Replicas: 1002,1003,1001 Isr: 1003,1001
Topic: __consumer_offsets Partition: 9 Leader: 1003 Replicas: 1003,1002,1001 Isr: 1003,1001
Topic: __consumer_offsets Partition: 10 Leader: 1001 Replicas: 1001,1003,1002 Isr: 1001,1003
Topic: __consumer_offsets Partition: 11 Leader: 1001 Replicas: 1002,1001,1003 Isr: 1003
下面是server中的示例。财产
但是在谷歌搜索了一段时间后，我们没有找到可以避免不同步的ISR问题的方法
auto.create.topics.enable=false
auto.leader.rebalance.enable=true
background.threads=10
log.retention.bytes=-1
log.retention.hours=12
delete.topic.enable=true
leader.imbalance.check.interval.seconds=300
leader.imbalance.per.broker.percentage=10
log.dir=/var/kafka/kafka-data
log.flush.interval.messages=9223372036854775807
log.flush.interval.ms=1000
log.flush.offset.checkpoint.interval.ms=60000
log.flush.scheduler.interval.ms=9223372036854775807
log.flush.start.offset.checkpoint.interval.ms=60000
compression.type=producer
log.roll.jitter.hours=0
log.segment.bytes=1073741824
log.segment.delete.delay.ms=60000
message.max.bytes=1000012
min.insync.replicas=1
num.io.threads=8
num.network.threads=3
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=10080
offsets.topic.compression.codec=0
offsets.topic.num.partitions=50
offsets.topic.replication.factor=3
offsets.topic.segment.bytes=104857600
queued.max.requests=500
quota.consumer.default=9223372036854775807
quota.producer.default=9223372036854775807
replica.fetch.min.bytes=1
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
request.timeout.ms=30000
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
socket.send.buffer.bytes=102400
transaction.max.timeout.ms=900000
transaction.state.log.load.buffer.size=5242880
transaction.state.log.min.isr=2
transaction.state.log.num.partitions=50
transaction.state.log.replication.factor=3
transaction.state.log.segment.bytes=104857600
transactional.id.expiration.ms=604800000
unclean.leader.election.enable=false
zookeeper.connection.timeout.ms=600000
zookeeper.max.in.flight.requests=10
zookeeper.session.timeout.ms=600000
zookeeper.set.acl=false
broker.id.generation.enable=true
connections.max.idle.ms=600000
connections.max.reauth.ms=0
controlled.shutdown.enable=true
controlled.shutdown.max.retries=3
controlled.shutdown.retry.backoff.ms=5000
controller.socket.timeout.ms=30000
default.replication.factor=2
delegation.token.expiry.time.ms=86400000
delegation.token.max.lifetime.ms=604800000
delete.records.purgatory.purge.interval.requests=1
fetch.purgatory.purge.interval.requests=1000
group.initial.rebalance.delay.ms=3000
group.max.session.timeout.ms=1800000
group.max.size=2147483647
group.min.session.timeout.ms=6000
log.213`1234cleaner.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.max.compaction.lag.ms=9223372036854775807
log.cleaner.min.cleanable.ratio=0.5
log.cleaner.min.compaction.lag.ms=0
log.cleaner.threads=1
log.cleanup.policy=delete
log.index.interval.bytes=4096
log.index.size.max.bytes=10485760
log.message.timestamp.difference.max.ms=9223372036854775807
log.message.timestamp.type=CreateTime
log.preallocate=false
log.retention.check.interval.ms=300000
max.connections=2147483647
max.connections.per.ip=2147483647
max.incremental.fetch.session.cache.slots=1000
num.partitions=1
producer.purgatory.purge.interval.requests=1000
queued.max.request.bytes=-1
replica.fetch.backoff.ms=1000
replica.fetch.max.bytes=1048576
replica.fetch.response.max.bytes=10485760
reserved.broker.max.id=1500
transaction.abort.timed.out.transaction.cleanup.interval.ms=60000
transaction.remove.expired.transaction.cleanup.interval.ms=3600000
zookeeper.sync.time.ms=2000
broker.rack=/default-rack
我们将不胜感激，以获得有关如何改进副本以保持同步的建议
链接
修复kafka中复制分区不足的问题
https://emilywibberley.com/blog/kafka-how-to-fix-out-of-sync-replicas/
什么是适合 replica.lag.time.max.ms 的价值？
https://strimzi.io/blog/2021/06/08/broker-tuning/
https://community.cloudera.com/t5/Support-Questions/Kafka-Replica-out-of-sync-for-over-24-hrs/m-p/82922
https://hevodata.com/learn/kafka-replication/
以下是我们考虑做的选项（但仅作为建议而不是解决方案）
>
逐个重启Kafka代理
通过< code>rm -rf移除< code >非同步副本，例如< code>rm -rf TEST_TOPIC_1，并希望Kafka将创建此副本，结果它将同步
尝试使用 Kafka-reassign-partitions
也许ISR会在一段时间后同步？
将 replica.lag.time.max.ms 增加到更高的值为 1 天并重新启动代理
同步的定义取决于主题配置，但默认情况下，这意味着副本在过去 10 秒内已经或已经与领导者完全同步。此时间段的设置为：replica.lag.time.max.ms，并具有服务器默认值，每个主题都可以覆盖该值。
什么是ISR？
ISR只是一个分区的所有副本，这些副本与领导者“同步”。“同步”的定义取决于主题配置，但默认情况下，它意味着一个副本在过去10秒内完全赶上了领导者。此时间段的设置是：replica.lag.time.max.ms并具有服务器默认值，可以在每个主题的基础上覆盖。ISR至少由领导者副本和任何其他被认为是同步的关注者副本组成。追随者通过定期发送获取请求将数据从领导者复制到自己，默认情况下每500毫秒发送一次。如果追随者失败，那么它将停止发送获取请求，默认后，10秒将从ISR中删除。同样，如果追随者变慢，可能是网络相关问题或服务器资源受限，那么一旦它落后于领导者超过10秒，它就会从ISR中删除。
要配置的其他一些重要相关参数有:
min.insync.replicas：指定必须确认写入才能将写入视为成功的最小副本数。offsets.retention.check.interval.ms：检查过时偏移的频率。
这应该保持相对较小，以促进更快的日志压缩和缓存加载。replica.lag.time.max.ms：如果追随者没有使用领导者日志或发送获取请求，至少在这么长的时间内，它将从ISR中删除。
replica.fetch.wait.max.ms:从副本发出的每个提取器请求的最大等待时间必须小于replica.lag.time.max.ms，以避免ISR收缩。
如果一个客户端请求的超时时间大于这个值，那么这个值是不允许的，这样可以避免其他用户的延迟。Zookeeper . session . time out . ms:Zookeeper会话超时。
zookeeper.sync.time.ms：追随者可以落后领导者多远，将其设置得太高可能会导致ISR具有潜在的许多不同步节点。
time-相关的设置不是你想要的；如果你增加这些，这只是意味着Kafka需要更长的时间来向你展示问题，同时你的数据实际上变得更落后了。对于一个全新的集群，你应该没有不同步的ISR，直到你开始添加负载…
增加num.replica.fetcher和num.network.threads将使代理能够更快地通过网络读取副本。最多，您可以尝试将这些设置为计算机上的CPU内核数。
较小的段字节可用于增加复制，但最好基于每个主题进行设置，仅用于压缩，而不是在群集范围内调整复制。
