[
https://issues.apache.org/jira/browse/KAFKA-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kostas Christidis updated KAFKA-6173:
-------------------------------------
Description:
h2. Setup
1 consumer (C1), 2 datacenters (DC1, DC2), a ZK ensemble located in DC1, and 3
brokers (B1, B2, B3), where:
* B1 is the cluster controller, located in DC1
* B2 is the leader for partition "foo", located in DC2
* B3 is a replica for partition "foo", located in DC1
h2. Condition
There is a network partition between DC1 and DC2
h2. Actual behavior
B2 will not relinquish leadership and will continue to serve C1. This
split-brain situation will go on until C1 refreshes its metadata and finds out
about the new leader.
h2. Expected behavior
B2 should stop accepting requests when it loses the ZK connection.
I am prioritizing this a "minor" bug because the multi-DC arrangement is not
optimal, and we'd be better off using a tool such as MirrorMaker.
was:
h2. Setup
1 consumer: C1
2 datacenters: DC1, DC2
A ZK ensemble located in DC1
3 brokers:
* B1 - the cluster controller, located in DC1
* B2 - the leader for partition "foo", located in DC2
* B3 - a replica for partition "foo", located in DC1
h2. Condition
There is a network partition between DC1 and DC2
h2. Actual behavior
B2 will not relinquish leadership and will continue to serve C1. This
split-brain situation will go on until C1 refreshes its metadata and finds out
about the new leader.
h2. Expected behavior
B2 should stop accepting requests when it loses the ZK connection.
I am prioritizing this a "minor" bug because the multi-DC arrangement is not
optimal, and we'd be better off using a tool such as MirrorMaker.
> Leader should stop accepting requests when disconnected from ZK
> ---------------------------------------------------------------
>
> Key: KAFKA-6173
> URL: https://issues.apache.org/jira/browse/KAFKA-6173
> Project: Kafka
> Issue Type: Bug
> Reporter: Kostas Christidis
> Priority: Minor
> Attachments: After.png, Before.png, Partition.png
>
>
> h2. Setup
> 1 consumer (C1), 2 datacenters (DC1, DC2), a ZK ensemble located in DC1, and
> 3 brokers (B1, B2, B3), where:
> * B1 is the cluster controller, located in DC1
> * B2 is the leader for partition "foo", located in DC2
> * B3 is a replica for partition "foo", located in DC1
> h2. Condition
> There is a network partition between DC1 and DC2
> h2. Actual behavior
> B2 will not relinquish leadership and will continue to serve C1. This
> split-brain situation will go on until C1 refreshes its metadata and finds
> out about the new leader.
> h2. Expected behavior
> B2 should stop accepting requests when it loses the ZK connection.
> I am prioritizing this a "minor" bug because the multi-DC arrangement is not
> optimal, and we'd be better off using a tool such as MirrorMaker.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
