我们正在Linux机器上安装新的Apache Kafka -version 2.7版本RHEL 7.9集群中的Kafka机器总数为- 5台机器
现在安装完成，但我们注意到并非所有ISR都处于同步状态
我想分享所有的原因，也许解释是什么原因导致复制副本不同步
**慢速复制副本：**在一段时间内始终无法赶上领导者上的写入的跟随者复制副本。最常见的原因之一是跟随副本上的I/O瓶颈，导致它以比从领导副本消耗的速度更慢的速度追加复制的消息。
**Stuck replica：**停止从leader获取数据一段时间的follower replica。复制副本可能由于GC暂停或失败或死亡而卡住。
** Bootstrap 副本：**当用户增加主题的复制因子时，新的follower副本将不同步，直到它们完全赶上leader的日志。
但由于我们正在处理新的临时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中示例
但是在google了一段时间后，我们没有发现什么可以避免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我们将不胜感激，以获得建议，以如何改善复制副本同步
链接
Fixing under replicated partitions in kafka
https://emilywibberley.com/blog/kafka-how-to-fix-out-of-sync-replicas/
What is a right value for 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/
以下是我们考虑的选项（但仅作为建议而不是解决方案）
1.重启Kafka brokers，一步一步地重启每个Kafka
1.通过rm -rf删除non in SYNC replica，例如rm -rf TEST_TOPIC_1，并希望Kafka将创建此副本，结果它将处于SYNC状态
1.尝试使用kafka-reassign-partitions
1.也许ISR会在一段时间后同步？
1.将replica.lag.time.max.ms增加到1天的更高值，并重新启动代理
- 同步的定义取决于主题配置，但默认情况下，这意味着副本在最近10秒内已经或已经与领导者完全同步。此时间段的设置为：replica.lag.time.max.ms，并具有服务器默认值，可由每个主题覆盖。
什么是ISR？
ISR只是一个分区的所有副本，它们与领导者“同步”。“同步”的定义取决于主题配置，但默认情况下，它意味着副本在过去10秒内完全赶上了领导者。此时间段的设置为：replica.lag.time.max.ms，并且具有可以在每个主题的基础上被覆盖的服务器默认值。ISR至少将包括leader副本和任何其他也被视为同步的follower副本。Follower通过定期发送Fetch Request（默认为每500 ms）将数据从leader复制到自己。如果follower失败，则它将停止发送获取请求，并且在默认值之后，ISR将删除10秒。同样，如果跟随者慢下来，可能是网络相关的问题或受限的服务器资源，那么一旦它落后于领导者超过10秒，它就会从ISR中删除。
需要配置的其他一些重要相关参数包括：
**min.insync.replicas：**指定必须确认写入才能视为成功的最小副本数。offsets.retention.check.interval.ms：检查陈旧偏移的频率。
**offsets.topic.segment.bytes：**这应该保持相对较小，以促进更快的日志压缩和缓存加载。**replica.lag.time.max.ms：**如果follower没有使用Leaders日志或发送获取请求，至少在这段时间内，它将从ISR中删除。
replica.fetch.wait.max.ms：follower副本发出的每个fetcher请求的最大等待时间必须小于replica.lag.time.max.ms，以避免ISR收缩。
**transaction.max.timeout.ms：**如果客户端请求的超时时间大于此值，则不允许超时，以免拖延其他消费者。zookeeper.session.timeout.ms：Zookeeper会话超时。
**zookeeper.sync.time.ms：**follower可以落后Leader多远，设置太高会导致ISR可能有许多不同步节点。
1条答案
按热度按时间jjjwad0x1#
time-相关设置不是您想要的;如果你增加这些，这只是意味着Kafka需要更长的时间来向你展示问题，同时你的数据实际上会变得更落后。对于全新的群集，在开始添加负载之前，您应该没有**不同步ISR.增加
num.replica.fetchers和num.network.threads将允许代理通过网络更快地读取副本。最多，您可以尝试将这些设置为计算机上的CPU核心数量。可以使用较小的段字节来增加复制，但最好是在每个主题的基础上设置，仅用于压缩，而不是调整集群范围的复制。