Остановка Kafka, потому что усечение журнала не разрешено из-за ошибки темы, закрывающей узлы Kafka

Question

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

 Halting because log truncation is not allowed for topic __consumer_offsets, 
Current leader 11's latest offset 123 is less than replica 13's latest offset 234 . 

Каждый раз, когда в журнале ошибок упоминается новая тема,У нас есть 3 узла Кафки с 3 узлами зоопарка.Не могли бы вы объяснить, что вызывает эту проблему и как ее можно исправить.

Это код, который проверяет эту ошибку

 /**
 * Unclean leader election: A follower goes down, in the meanwhile the leader keeps appending messages. The follower comes back up
 * and before it has completely caught up with the leader's logs, all replicas in the ISR go down. The follower is now uncleanly
 * elected as the new leader, and it starts appending messages from the client. The old leader comes back up, becomes a follower
 * and it may discover that the current leader's end offset is behind its own end offset.
 *
 * In such a case, truncate the current follower's log to the current leader's end offset and continue fetching.
 *
 * There is a potential for a mismatch between the logs of the two replicas here. We don't fix this mismatch as of now.
 */
val leaderEndOffset: Long = earliestOrLatestOffset(topicPartition, ListOffsetRequest.LATEST_TIMESTAMP)

if (leaderEndOffset < replica.logEndOffset.messageOffset) {
  // Prior to truncating the follower's log, ensure that doing so is not disallowed by the configuration for unclean leader election.
  // This situation could only happen if the unclean election configuration for a topic changes while a replica is down. Otherwise,
  // we should never encounter this situation since a non-ISR leader cannot be elected if disallowed by the broker configuration.
  if (!LogConfig.fromProps(brokerConfig.originals, AdminUtils.fetchEntityConfig(replicaMgr.zkUtils,
    ConfigType.Topic, topicPartition.topic)).uncleanLeaderElectionEnable) {
    // Log a fatal error and shutdown the broker to ensure that data loss does not occur unexpectedly.
    fatal(s"Exiting because log truncation is not allowed for partition $topicPartition, current leader " +
      s"${sourceBroker.id}'s latest offset $leaderEndOffset is less than replica ${brokerConfig.brokerId}'s latest " +
      s"offset ${replica.logEndOffset.messageOffset}")
    throw new FatalExitError
  }

Спасибо

Answer 1

Это происходит с 0.10.0 и происходит даже с min.insync.replicas=2.

Лидер раздела записывает подписчикам перед тем, как его совершить (особенно для тем с acks=all, таких как __consumer_offsets). Когда происходит короткое прерывание сети, последователь может быстро восстановиться и до того, как сообщения будут записаны лидеру, и, следовательно, реплика остановится из-за нечистого выбора лидера. Это была известная проблема , которая была исправлена ​​на 0.11.0.

Одним из возможных решений было бы установить unclean.leader.election.enable=true для таких тем, как __consumer_offsets, а затем перезапустить брокеров. Согласно Кафка документов ,

unclean.leader.election.enable: Указывает, следует ли включить реплики, не входящие в состав ISR, для выбора в качестве лидера в качестве последнего средства, даже если это может привести к потере данных.

Когда происходит сбой брокера, раздел лидера будет переключаться контроллером, который также выберет одну реплику в ISR в качестве лидера раздела. Если реплика недоступна, вы не сможете писать или читать из этого раздела. Если установить для unlcean.leader.election.enable значение true, первая доступная реплика будет выбрана в качестве лидера раздела, даже если ее нет в ISR, и, следовательно, некоторые сообщения могут быть потеряны!

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