Блог

мы обновили Kafka с 2.2 до 2.6 и добавили 4 новых брокера к существующим 4 брокерам. Все прошло нормально.

После этого мы начали переназначать данные темы новым брокерам. Большинство тем прошло нормально, но в одном из 50 разделов __consumer_смещений переназначение зависает. 49 разделов были успешно перемещены со старых брокеров (id 3,4,5,6) на новые (идентификаторы 10,11,12,13).

Но на __consumer_offsets-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 только после того, как он успешно работал во всех тестовых средах.

РЕДАКТИРОВАТЬ: мы действительно обнаружили, что в огромном списке смещений сообщений в списке исключения на самом деле есть дескрипция. Соответствующая часть этого списка

 ... 1545271418, 1545271419, 1, 1, 1545271422, 1545271423,
  

Очевидно, что две записи ‘1’ там выглядят действительно неправильно! Они должны быть 1545271420/1545271421. Может ли быть так, что у лидера действительно есть какое-то повреждение данных?

В конечном итоге мы смогли решить эту проблему — в основном, сидя и ожидая

Проблема действительно заключалась в том, что когда-то, каким-то образом, данные о лидере этого раздела __consumer_offset-18 были повреждены. Вероятно, это произошло во время обновления с Kafka 2.2 -> 2.6. Как мы теперь знаем, мы делали это довольно опасным способом: мы просто остановили всех брокеров, обновили SW для всех и перезапустили их. Мы подумали, что, поскольку мы можем позволить себе это отключение в выходные, это будет безопасный способ. Но мы, конечно, никогда больше этого не сделаем. По крайней мере, если мы не знаем на 100%, что все производители и все потребители действительно остановлены. Это было НЕ так во время этого обновления, мы пропустили одного потребителя и оставили его запущенным, и этот потребитель (группа) сохранял свои смещения в разделе __consumer_offset-18 . Таким образом, это действие — удаление всех брокеров и их обновление — пока потребители / производители все еще работают, вероятно, вызвало повреждение

Извлеченный урок: никогда не делайте этого снова, всегда выполняйте текущие обновления, даже если они занимают намного больше времени.

Затем проблема была фактически решена благодаря характеру темы уплотнения. Настройки по умолчанию для уплотнения должны выполняться каждую неделю (или когда сегмент становится больше 1 ГБ, чего в нашем случае не произойдет). Вчера вечером началось уплотнение этого раздела __consumer_offset-18. И тем самым 2 поврежденных смещения были удалены. После этого все пошло в гору, переназначение этого раздела новым брокерам сработало как по маслу.

Мы, безусловно, могли бы ускорить это восстановление, установив параметры темы таким образом, чтобы сжатие началось раньше. Но только в среду мы пришли к пониманию, что проблема действительно может быть решена таким образом. Мы решили оставить все как было и подождать еще один день.