我们已经将Kafka从2.2升级到2.6，并在现有的4个经纪人的基础上增加了4个新经纪人。一切顺利。
之后，我们开始将主题数据重新分配给新的代理。大多数主题都正常，但是在消费偏移量的50个分区中的一个上，重新分配挂起。49个分区已成功地从旧代理（id 3、4、5、6）移动到新代理（id 10、11、12、13）。
但是在uu consumer u offset-18上，我们始终会得到这个错误（在新代理的server.log中）
[2020-10-24 15:04:54,528] ERROR [ReplicaFetcher replicaId=10, leaderId=3, fetcherId=0] Unexpected error occurred while processing data for partition __consumer_offsets-18 at offset 1545264631 (kafka.server.ReplicaFetcherThread)
kafka.common.OffsetsOutOfOrderException: Out of order offsets found in append to __consumer_offsets-18: ArrayBuffer(1545264631, 1545264632,
... thousands of other ids
1545272005, 1545272006, 1545272007)
at kafka.log.Log.$anonfun$append$2(Log.scala:1126)
at kafka.log.Log.append(Log.scala:2340)
at kafka.log.Log.appendAsFollower(Log.scala:1036)
at kafka.cluster.Partition.doAppendRecordsToFollowerOrFutureReplica(Partition.scala:939)
at kafka.cluster.Partition.appendRecordsToFollowerOrFutureReplica(Partition.scala:946)
at kafka.server.ReplicaFetcherThread.processPartitionData(ReplicaFetcherThread.scala:168)
at kafka.server.AbstractFetcherThread.$anonfun$processFetchRequest$7(AbstractFetcherThread.scala:332)
at kafka.server.AbstractFetcherThread.$anonfun$processFetchRequest$6(AbstractFetcherThread.scala:320)
at kafka.server.AbstractFetcherThread.$anonfun$processFetchRequest$6$adapted(AbstractFetcherThread.scala:319)
at scala.collection.IterableOnceOps.foreach(IterableOnce.scala:553)
at scala.collection.IterableOnceOps.foreach$(IterableOnce.scala:551)
at scala.collection.AbstractIterable.foreach(Iterable.scala:920)
at kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:319)
at kafka.server.AbstractFetcherThread.$anonfun$maybeFetch$3(AbstractFetcherThread.scala:135)
at kafka.server.AbstractFetcherThread.maybeFetch(AbstractFetcherThread.scala:134)
at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:117)
at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:96)
[2020-10-24 15:04:54,534] INFO [ReplicaFetcher replicaId=10, leaderId=4, fetcherId=0] Truncating partition __consumer_offsets-31 to local high watermark 0 (kafka.server.ReplicaFetcherThread)
[2020-10-24 15:04:54,547] WARN [ReplicaFetcher replicaId=10, leaderId=3, fetcherId=0] Partition __consumer_offsets-18 marked as failed (kafka.server.ReplicaFetcherThread)你知道这里怎么了吗？整个集群似乎可以很好地处理数据。只是我们不能越过这个特定的分区。我们尝试了各种方法（取消重新分配、使用所有分区重新启动、仅使用分区18重新启动、重新启动所有代理）但都没有成功
非常感谢您的帮助，只有在prod在所有测试环境中成功运行之后，才会在prod中发生这种情况。
edit：我们实际上发现，在异常列表中巨大的消息偏移量列表中，实际上有一个descrepance。这份清单的相关部分是
... 1545271418, 1545271419, 1, 1, 1545271422, 1545271423,很明显，那两个“1”条目看起来真的不对！它们应该是1545271420/1545271421。难道领导真的有某种数据腐败吗？
1条答案
按热度按时间ztigrdn81#
我们最终解决了这个问题——主要是坐以待毙
问题确实是，不知何故，这个uu consumer\u offset-18分区的负责人的数据被破坏了。这可能发生在Kafka2.2->2.6的升级过程中。我们以一种相当危险的方式来做这件事，正如我们现在所知：我们只是停止了所有代理，更新了所有代理上的软件，然后重新启动它们。我们认为，既然我们能够承受周末的停电，这将是一种安全的方式。但我们绝对不会再这样做了。至少不能，除非我们100%地知道所有的生产者和消费者真的被叫停了。在升级过程中不是这样的，我们忽略了一个消费者并让它继续运行，而该消费者（组）将其偏移量存储在\uu consumer\u offset-18分区中。因此，在消费者/生产商仍在运营的情况下，采取行动——关闭所有经纪人并对其进行升级——很可能导致了腐败
经验教训：永远不要再这样做了，总是做滚动升级，即使他们需要更长的时间。
这个问题实际上是通过主题的性质来解决的。压缩的默认设置是每周运行一次（或者当一个段大于1gb时，在本例中不会发生这种情况）。昨天晚上开始对18号分区进行压缩。到那时，两个损坏的偏移量被清除了。在那之后，它是上坡，重新分配的分区，以新的经纪人，然后像一个魅力。
我们当然可以通过设置主题参数来加快恢复速度，而压缩会更早地开始。但直到周三，我们才达成共识，认为这个问题实际上可以通过这种方式解决。我们决定一切都保持原样，改天再等。