Closed thusfar7 closed 5 years ago
As per the README the broker-ids are generated automatically. So if you restart the container when it registers with zookeeper it will get the next auto-generated ID. This should be evident in the logs (you'll see an initial broker ID of 1001, then 1002, 1003 etc). However, any topics you have already created will be assigned to now non-existing broker IDs, so the leader will be unavailable.
@sscaling Thanks a bunch. This helped.
@sscaling i'm dealing with this issue right now and looking for a little insight if you have it. I have 2 brokers up, a topic is created (auto create topics = true) then 1 broker goes down which causes the producers to constantly fail when sending a message on that topic until that broker comes back up. Is this a config issue or am I missing something in my setup?
So what can I do to fix this problem? I get this problem also with KafkaJS on AWS MSK (and locally with this image).
I'm having the same issue. Currently, I manually resolve it by completely removing zookeeper and restarting docker-compose.
Any assistance is welcome!
A solution I found was to follow these instructions: Because of how cluster state is stored in zookeeper you should either configure a consistent broker ID, use the —no-recreate option if restarting kafka or make sure the zookeeper and kafka containers are torn down by running docker-compose rm -vfs.
docker-compose rm kafka-container-name
does the job, thanks @Alqio
docker-compose down
docker rm -f $(docker ps -a -q)
docker volume rm $(docker volume ls -q
didn't help me💁🏼
Removing the volume is not an option on our end as it would blow away all of our critical streams. What is the underlying issue causing no leader to be elected?
Alqio recommended an appropriate solution to prevent eternal and unresolved leadership elections:
A solution I found was to follow these instructions: Because of how cluster state is stored in zookeeper you should either configure a consistent broker ID, use the —no-recreate option if restarting kafka or make sure the zookeeper and kafka containers are torn down by running docker-compose rm -vfs.
Alternatively, a quick fix for us was to stop docker-compose, remove zookeeper completely (and also kafka-docker if that wouldn't help) and restart docker-compose.
I'm using kafka with KafkaJS. When I do
docker-compose up
everything works fine. But if I change any of the kafka configs or better to say, when kafka container restarts, my kafkajs nodejs code cannot send messages to topic nor listen from it and it throws the following error.But if I do
docker-compose down
and thendocker-compose up
then it works. Or more importantly, if I just dodocker rm -f project-name_zookeeper_1
anddocker-compose up
which recreates the zookeeper container then everything works fine again.I also use kafkahq, which also works when my kafkajs/nodejs code works, and doesnt work when my kafkajs/nodejs code doesnt work. So I'd say the problem is not within that part of my app.
You could try to reproduce it yourself. Kafkahq password is password.
I searched through other people issues but haven't found a solution to this.
Any idea?