ОБНОВЛЕНИЕ
Обнаружено, что это происходит каждый раз, когда новый топи c создается в исходном кластере.
Проблема устранена путем обновления to Confluent Kafka 5.5.1
Я пытаюсь перенести данные из одного кластера в другой с помощью Replicator. Все темы созданы с исходной конфигурацией и данные успешно реплицированы, но я столкнулся со странным поведением. Каждые ~ 15 минут все данные из исходного кластера снова реплицируются в целевой кластер. Я предполагаю, что это неправильная конфигурация (конфигурации потребителя, производителя и репликатора прилагаются ниже)
Журналы: Следующие журналы печатаются каждый раз, когда происходит дублирование (прилагается только 1 строка, но для всех существующих тем):
[2020-07-14 08:18:15,003] INFO [Consumer clientId=replicator-0, groupId=replicator] Resetting offset for partition testTopic-0 to offset 0. (org.apache.kafka.clients.consumer.internals.Fetcher:601)
Конфигурация потребителя:
bootstrap.servers=sourceKafkaEndpoint:9092
Конфигурация производителя:
bootstrap.servers=destKafkaEndpoint:9092
Конфигурация репликатора:
confluent.topic.bootstrap.servers=sourceKafkaEndpoint:9092
offset.start=consumer
topic.config.sync=false
Исполняемая команда:
replicator --consumer.config consumer.properties --producer.config producer.properties --replication.config replication.properties --topic.regex ".*" --cluster.id replicator
Информация о Kafka:
- Исходный кластер Версия Kafka: 2.0.1-cp4
- Целевой кластер Версия Kafka: 2.4.1
Исходный кластер:
- 3 брокера
- 3 Zookeepers
- ~ 700 тем
Целевой кластер:
- 3 Брокеры
- 3 Zookeepers
- Это новый кластер, содержащий только одну вершину c (__consumer_offsets)
Значения конфигурации потребителя:
auto.commit.interval.ms = 5000
auto.offset.reset = none
bootstrap.servers = [destKafkaEndpoint:9092]
check.crcs = true
client.id = replicator-0
connections.max.idle.ms = 540000
default.api.timeout.ms = 60000
enable.auto.commit = false
exclude.internal.topics = true
fetch.max.bytes = 52428800
fetch.max.wait.ms = 500
fetch.min.bytes = 1
group.id = replicator
heartbeat.interval.ms = 3000
interceptor.classes = []
internal.leave.group.on.close = true
isolation.level = read_uncommitted
key.deserializer = class org.apache.kafka.common.serialization.ByteArrayDeserializer
max.partition.fetch.bytes = 1048576
max.poll.interval.ms = 300000
max.poll.records = 500
metadata.max.age.ms = 300000
metric.reporters = []
metrics.num.samples = 2
metrics.recording.level = INFO
metrics.sample.window.ms = 30000
partition.assignment.strategy = [class org.apache.kafka.clients.consumer.RangeAssignor]
receive.buffer.bytes = 65536
reconnect.backoff.max.ms = 1000
reconnect.backoff.ms = 50
request.timeout.ms = 30000
retry.backoff.ms = 100
sasl.client.callback.handler.class = null
sasl.jaas.config = null
sasl.kerberos.kinit.cmd = /usr/bin/kinit
sasl.kerberos.min.time.before.relogin = 60000
sasl.kerberos.service.name = null
sasl.kerberos.ticket.renew.jitter = 0.05
sasl.kerberos.ticket.renew.window.factor = 0.8
sasl.login.callback.handler.class = null
sasl.login.class = null
sasl.login.refresh.buffer.seconds = 300
sasl.login.refresh.min.period.seconds = 60
sasl.login.refresh.window.factor = 0.8
sasl.login.refresh.window.jitter = 0.05
sasl.mechanism = GSSAPI
security.protocol = PLAINTEXT
send.buffer.bytes = 131072
session.timeout.ms = 10000
ssl.cipher.suites = null
ssl.enabled.protocols = [TLSv1.2, TLSv1.1, TLSv1]
ssl.endpoint.identification.algorithm = https
ssl.key.password = null
ssl.keymanager.algorithm = SunX509
ssl.keystore.location = null
ssl.keystore.password = null
ssl.keystore.type = JKS
ssl.protocol = TLS
ssl.provider = null
ssl.secure.random.implementation = null
ssl.trustmanager.algorithm = PKIX
ssl.truststore.location = null
ssl.truststore.password = null
ssl.truststore.type = JKS
value.deserializer = class org.apache.kafka.common.serialization.ByteArrayDeserializer
(org.apache.kafka.clients.consumer.ConsumerConfig:279)
Есть идеи, почему это происходит?