Yes, that’s correct. While a broker is down: all topic partitions assigned to that broker will be under-replicated topic partitions with an unmet minimum ISR count will be offline leadership of partitions meeting the minimum ISR count will move to the next in-sync replica in the replica list if no in-sync replica exists for a topic-partitions, it will be offline Setting unclean.leader.election.enable=true will allow an out-of-sync replica to become a leader. If topic partition availability is more important to you than data integrity, you should allow unclean leader election.
> On Mar 11, 2020, at 6:11 AM, 张祥 <xiangzhang1...@gmail.com> wrote: > > Hi, Peter, following what we talked about before, I want to understand what > will happen when one broker goes down, I would say it will be very similar > to what happens under disk failure, except that the rules apply to all the > partitions on that broker instead of only one malfunctioned disk. Am I > right? Thanks. > > 张祥 <xiangzhang1...@gmail.com> 于2020年3月5日周四 上午9:25写道： > >> Thanks Peter, really appreciate it. >> >> Peter Bukowinski <pmb...@gmail.com> 于2020年3月4日周三 下午11:50写道： >> >>> Yes, you should restart the broker. I don’t believe there’s any code to >>> check if a Log directory previously marked as failed has returned to >>> healthy. >>> >>> I always restart the broker after a hardware repair. I treat broker >>> restarts as a normal, non-disruptive operation in my clusters. I use a >>> minimum of 3x replication. >>> >>> -- Peter (from phone) >>> >>>> On Mar 4, 2020, at 12:46 AM, 张祥 <xiangzhang1...@gmail.com> wrote: >>>> >>>> Another question, according to my memory, the broker needs to be >>> restarted >>>> after replacing disk to recover this. Is that correct? If so, I take >>> that >>>> Kafka cannot know by itself that the disk has been replaced, manually >>>> restart is necessary. >>>> >>>> 张祥 <xiangzhang1...@gmail.com> 于2020年3月4日周三 下午2:48写道： >>>> >>>>> Thanks Peter, it makes a lot of sense. >>>>> >>>>> Peter Bukowinski <pmb...@gmail.com> 于2020年3月3日周二 上午11:56写道： >>>>> >>>>>> Whether your brokers have a single data directory or multiple data >>>>>> directories on separate disks, when a disk fails, the topic partitions >>>>>> located on that disk become unavailable. What happens next depends on >>> how >>>>>> your cluster and topics are configured. >>>>>> >>>>>> If the topics on the affected broker have replicas and the minimum ISR >>>>>> (in-sync replicas) count is met, then all topic partitions will remain >>>>>> online and leaders will move to another broker. Producers and >>> consumers >>>>>> will continue to operate as usual. >>>>>> >>>>>> If the topics don’t have replicas or the minimum ISR count is not met, >>>>>> then the topic partitions on the failed disk will be offline. >>> Producers can >>>>>> still send data to the affected topics — it will just go to the online >>>>>> partitions. Consumers can still consume data from the online >>> partitions. >>>>>> >>>>>> -- Peter >>>>>> >>>>>>>> On Mar 2, 2020, at 7:00 PM, 张祥 <xiangzhang1...@gmail.com> wrote: >>>>>>>> >>>>>>>> Hi community， >>>>>>>> >>>>>>>> I ran into disk failure when using Kafka, and fortunately it did not >>>>>> crash >>>>>>> the entire cluster. So I am wondering how Kafka handles multiple >>> disks >>>>>> and >>>>>>> it manages to work in case of single disk failure. The more detailed, >>>>>> the >>>>>>> better. Thanks ! >>>>>> >>>>> >>> >>
