A 5-node quorum doesn't make a lot of sense in a setting where those nodes
are also Kafka brokers. When they're ZooKeeper voters, a quorum* of 5
makes a lot of sense, because you can take an unscheduled voter failure
during a rolling-reboot scheduled maintenance without significant service
impact.
recovery times, so from your
> mail I understand you wouldn't expect an improvement on latencies as well.
>
> On Thu, 1 Feb 2024 at 22:53, Michael K. Edwards
> wrote:
>
> > The interesting numbers are the recovery times after 1) the Kafka broker
> > currently acting
The interesting numbers are the recovery times after 1) the Kafka broker
currently acting as the "active" controller (or the sole controller in a
ZooKeeper-based deployment) goes away; 2) the Kafka broker currently acting
as the consumer group coordinator for a consumer group with many partitions
a
org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum#KIP-500:ReplaceZooKeeperwithaSelf-ManagedMetadataQuorum-Motivation
>
> Ron
>
> > On May 10, 2020, at 1:35 PM, Michael K. Edwards
> wrote:
> >
> > What is the actual goa
What is the actual goal of removing the ZooKeeper dependency? In my
experience, if ZooKeeper is properly provisioned and deployed, it's largely
trouble-free. (You do need to know how to use observers properly.) There
are some subtleties about timeouts and leadership changes, but they're
pretty s
gt; Jamie
>
> -----Original Message-
> From: Michael K. Edwards
> To: dev@kafka.apache.org
> Sent: Tue, 14 Apr 2020 20:50
> Subject: Re: Preferred Partition Leaders
>
> I have clients with a similar need relating to disaster recovery. (Three
> replicas per partitio
I have clients with a similar need relating to disaster recovery. (Three
replicas per partition within a data center / AWS AZ/region, fourth replica
elsewhere, ineligible to become the partition leader without manual
intervention.)
On Tue, Apr 14, 2020 at 12:31 PM Łukasz Antoniak
wrote:
> Hi Ev
