IR
и сделать полноценный backpressure, но тогда не будет механизма определения зависших консюмеров
Size: a a a
2020 January 17
IR
а хотя тут еще вариант предлагали делать poll в /dev/null пока принимающая стороная не может обработать сообщения
IR
ну и не комиттить ничего соответственно
RI
ну и не комиттить ничего соответственно
Прощай автокомит
RI
Да. Это по сути реактивное программирование и заставить бы приемник далее сделать обратное давление. Но там черный ящик
FV
гуру, прости за возможно ламерский вопрос: почему broker не стал leader, после того как текущий leader (node01) вышел из строя ? :(
Topic:events PartitionCount:1 ReplicationFactor:1 Configs:
Topic: events Partition: 0 Leader: 1 Replicas: 1 Isr: 1
Metadata for all topics (from broker -1: 10.49.69.30:9092/bootstrap):
1 brokers:
broker 2 at node02:9092
1 topics:
topic "events" with 1 partitions:
partition 0, leader -1, replicas: 1, isrs: , Broker: Leader not available
FV
в логах на node01:
[2020-01-17 12:09:49,560] INFO Kafka commitId: 18a913733fb71c01 (org.apache.kafka.common.utils.AppInfoParser)
[2020-01-17 12:09:49,560] INFO Kafka startTimeMs: 1579259389553 (org.apache.kafka.common.utils.AppInfoParser)
[2020-01-17 12:09:49,562] INFO [KafkaServer id=1] started (kafka.server.KafkaServer)
[2020-01-17 12:09:49,733] INFO Replica loaded for partition events-0 with initial high watermark 632 (kafka.cluster.Replica)
[2020-01-17 12:09:49,780] INFO [ReplicaFetcherManager on broker 1] Removed fetcher for partitions Set(events-0) (kafka.server.ReplicaFetcherManager)
[2020-01-17 12:09:49,797] INFO [Partition events-0 broker=1] events-0 starts at Leader Epoch 2 from offset 632. Previous Leader Epoch was: -1 (kafka.cluster.Partition)
[2020-01-17 12:19:49,368] INFO [GroupMetadataManager brokerId=1] Removed 0 expired offsets in 0 milliseconds. (kafka.coordinator.group.GroupMetadataManager)
MU
в isr один хост прописан
MU
только на него эта партиция и может встать
MU
нужно больше реплик
MU
они будут в isr как засинкаются и тогда возможно переключение