У меня есть 3-узловый кластер Zookeeper версии 3.4.11 и 2-узловый кластер Kafka версии 0.11.3.Мы написали продюсера, который отправляет сообщения в определенную тему и разделы кластера Kafka (я делал это раньше, и продюсер тестируется).Вот конфиги брокеров:
broker.id=1
listeners=PLAINTEXT://node1:9092
num.partitions=24
delete.topic.enable=true
default.replication.factor=2
log.dirs=/data
zookeeper.connect=zoo1:2181,zoo2:2181,zoo3:2181
log.retention.hours=168
zookeeper.session.timeout.ms=40000
zookeeper.connection.timeout.ms=10000
offsets.topic.replication.factor=2
transaction.state.log.replication.factor=2
transaction.state.log.min.isr=2
Вначале нет темы о брокерах, и они будут созданы автоматически.Когда я запускаю продюсера, кластер Kafka демонстрирует странное поведение:
1 - создает все темы, но при этом скорость создания данных составляет 10 КБ в секунду, при менее одной минуты журналкаталог каждого брокера идет от нулевых данных до 9,0 гигабайт данных !и все брокеры отключены (из-за недостатка емкости log-dir)
2 - Просто при создании данных я пытаюсь использовать данные с помощью консоли-потребителя, и это просто ошибки
WARN Error while fetching metadata with correlation id 2 : {Topic1=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
3- Вот ошибка, которая неоднократно появляется в журнале брокеров:
INFO Updated PartitionLeaderEpoch. New: {epoch:0, offset:0}, Current: {epoch:-1, offset-1} for Partition: Topic6-6. Cache now contains 0 entries. (kafka.server.epoch.LeaderEpochFileCache)
WARN Newly rolled segment file 00000000000000000000.log already exists; deleting it first (kafka.log.Log)
WARN Newly rolled segment file 00000000000000000000.index already exists; deleting it first (kafka.log.Log)
WARN Newly rolled segment file 00000000000000000000.timeindex already exists; deleting it first (kafka.log.Log)
ERROR [Replica Manager on Broker 1]: Error processing append operation on partition Topic6-6 (kafka.server.ReplicaManager)
kafka.common.KafkaException: Trying to roll a new log segment for topic partition Topic6-6 with start offset 0 while it already exists.
После многократного повторения вышеуказанного журнала мы имеем:
ERROR [ReplicaManager broker=1] Error processing append operation on partition Topic24-10 (kafka.server.ReplicaManager)
org.apache.kafka.common.errors.InvalidOffsetException: Attempt to append an offset (402) to position 5 no larger than the last offset appended (402)
И, наконец, (когда естьв log-dir нет места) это ошибки:
FATAL [Replica Manager on Broker 1]: Error writing to highwatermark file: (kafka.server.ReplicaManager)
java.io.FileNotFoundException: /data/replication-offset-checkpoint.tmp (No space left on device)
и завершение работы!
4 - Я установил новый одноузловой Kafka версии 0.11.3 друг на друга, и он хорошо работает, используятот же производитель и использующий тот же кластер Zookeeper.
5- Я отключил одного из двух брокеров Kafka и, просто используя одного брокера (кластера), он ведет себя так же, как и при использовании двухузлового кластера Kafka.
В чем проблема?
UPDATE1: Я пробовал Kafka версии 2.1.0, но тот же результат!
UPDATE2: Я обнаружил, что корень проблемы.При создании я создаю 25 тем, каждая из которых имеет 24 раздела.Удивительно, но каждая тема сразу после создания (с помощью команды kafka-topic.sh и когда данные не сохраняются) занимают 481 МБ!Например, в каталоге журналов темы «20» для каждого каталога разделов у меня есть следующие файлы с общим объемом 21 МБ:
00000000000000000000.index (10MB) 00000000000000000000.log(0MB) 00000000000000000000.timeindex(10MB) leader-epoch-checkpoint(4KB)
, и Кафка записывает следующие строки для каждого раздела-раздела в файле server.log.файл:
[2019-02-05 10:10:54,957] INFO [Log partition=topic20-14, dir=/data] Loading producer state till offset 0 with message format version 2 (kafka.log.Log)
[2019-02-05 10:10:54,957] INFO [Log partition=topic20-14, dir=/data] Completed load of log with 1 segments, log start offset 0 and log end offset 0 in 1 ms (kafka.log.Log)
[2019-02-05 10:10:54,958] INFO Created log for partition topic20-14 in /data with properties {compression.type -> producer, message.format.version -> 2.1-IV2, file.delete.delay.ms -> 60000, max.message.bytes -> 1000012, min.compaction.lag.ms -> 0, message.timestamp.type -> CreateTime, message.downconversion.enable -> true, min.insync.replicas -> 1, segment.jitter.ms -> 0, preallocate -> false, min.cleanable.dirty.ratio -> 0.5, index.interval.bytes -> 4096, unclean.leader.election.enable -> false, retention.bytes -> -1, delete.retention.ms -> 86400000, cleanup.policy -> [delete], flush.ms -> 9223372036854775807, segment.ms -> 604800000, segment.bytes -> 1073741824, retention.ms -> 604800000, message.timestamp.difference.max.ms -> 9223372036854775807, segment.index.bytes -> 10485760, flush.messages -> 9223372036854775807}. (kafka.log.LogManager)
[2019-02-05 10:10:54,958] INFO [Partition topic20-14 broker=0] No checkpointed highwatermark is found for partition topic20-14 (kafka.cluster.Partition)
[2019-02-05 10:10:54,958] INFO Replica loaded for partition topic20-14 with initial high watermark 0 (kafka.cluster.Replica)
[2019-02-05 10:10:54,958] INFO [Partition topic20-14 broker=0] topic20-14 starts at Leader Epoch 0 from offset 0. Previous Leader Epoch was: -1 (kafka.cluster.Partition)
В журнале сервера нет ошибок.Я даже могу потреблять данные, если я создаю данные по теме.Поскольку общее пространство каталога журнала составляет 10 ГБ, Kafka требуется 12025 МБ для 25 тем в моем сценарии, что превышает общее пространство каталога, и Kafka выдаст ошибку и завершит работу!
Просто для теста я настроил другого брокера Kafka (а именно broker2) используя тот же кластер Zookeeper и создав новую тему с 24 разделами, они занимают 100 КБ для всех пустых разделов!
Так что я действительно запутался!Broker1 и Broker2, одна и та же версия Kafka (0.11.3) работает и отличается только ОС и системный файл:
В случае Broker1 (занимают 481 МБ данных для новой темы):
- ОС CentOS 7 и XFS как системный файл
В случае Broker2 (занимают 100 КБ данных для новой темы):
- ОС Ubuntu 16.04 и ext4 какСистемный файл