我们正在Linux机器版本RHEL 7.9上安装新的Apache Kafka-version 2.7集群中的Kafka机器总数为-5台
现在安装已经完成，但我们注意到并非所有ISR都处于同步中
我想分享所有的原因，也许可以解释是什么原因导致副本不在同步
慢速复制副本：在一段时间内始终无法赶上前导上的写入的跟随复制副本。最常见的原因之一是跟随复制副本上的I/O瓶颈，导致它以低于从引导复制副本消耗的速率附加复制的消息。
卡住的副本：在一段时间内停止从引导者获取的跟随者副本。复制副本可能由于GC暂停或失败或死亡而被卡住。
引导复制副本：当用户增加主题的复制因子时，新的跟随者复制副本将不同步，直到它们完全赶上领导者的日志。
但是，由于我们正在处理新的scratch Kafka集群，我想知道ISR不同步的问题是否与Kafka server.properties中的一些参数有关，这些参数没有设置好
这是关于__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.properties的例子
但经过一段时间的谷歌搜索，我们没有发现什么可以避免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代理，每个Kafka一步一步
通过
rm -rf删除non in SYNC replica，例如rm -rf TEST_TOPIC_1，并希望Kafka将创建此副本，结果它将在SYNC 中尝试使用kafka重新分配分区
也许ISR会在一段时间后同步？
将
replica.lag.time.max.ms增加到更高的值作为1天，并重新启动代理同步的定义取决于主题配置，但默认情况下，这意味着复制副本在过去10秒内已经或已经与领导者完全同步。此时间段的设置为：replica.lag.time.max.ms，并且具有服务器默认值，每个主题都可以覆盖该值
什么是ISR
ISR只是一个分区的所有副本；"同步"；和领导在一起。"；"同步"；取决于主题配置，但默认情况下，这意味着复制副本在过去10秒内完全赶上或已经赶上领先者。此时间段的设置为：replica.lag.time.max.ms，并且具有服务器默认值，可以根据每个主题进行覆盖。ISR至少由前导副本和任何其他被视为同步的跟随副本组成。追随者通过定期发送Fetch Request将数据从领导者复制到自己身上，默认情况下每500ms发送一次。如果追随者失败，那么它将停止发送获取请求，在默认情况下，10秒将从ISR中删除。同样，如果跟随者速度减慢，可能是网络相关问题或服务器资源受限，那么一旦它落后于领先者超过10秒，它就会被从ISR中删除。
其他一些需要配置的重要相关参数包括：
min.insync.re副本：指定必须确认写入才能认为写入成功的最小副本数。offsets.retention.check.interval.ms：检查过时偏移的频率。
offsets.topic.segment.bytes:为了加快日志压缩和缓存加载，应该保持相对较小的偏移量。replica.llag.time.max.ms:如果跟随者没有消耗Leaders日志或发送获取请求，至少在这段时间内，它将从ISR中删除。
replica.fetch.wait.max.ms：跟随副本发出的每个回迁请求的最大等待时间必须小于replica.lag.time.max.ms，以避免ISR收缩。
transaction.max.timeout.ms:如果客户端请求的超时值大于此值，则不允许这样做，以免拖延其他消费者。zookeeper.session.timeout.ms:zookeeper会话超时。
zookeeper.sync.time.ms:跟随者可以落后于领导者多远，设置得太高可能会导致ISR有许多不同步的节点。
time相关设置不是您想要的；如果你增加了这些，这只意味着卡夫卡需要更长的时间来向你展示问题，同时你的数据实际上会越来越落后。对于全新的集群，在开始添加负载之前，您应该有no不同步的ISR。。。
增加num.replica.fetchers和num.network.threads将允许代理更快地通过网络读取副本。最多，您可以尝试将这些设置为计算机上的CPU核数。
较小的分段字节可以用于增加复制，但最好按主题设置，仅用于压缩，而不是在集群范围内调整复制。