Mailing-List: contact jira-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@kafka.apache.org
Date: Sun, 5 Nov 2017 14:31:00 +0000 (UTC)
From: "Kostas Christidis (JIRA)" <jira@apache.org>
To: jira@kafka.apache.org
Message-ID: <JIRA.13116256.1509891918000.153781.1509892260029@Atlassian.JIRA>
In-Reply-To: <JIRA.13116256.1509891918000@Atlassian.JIRA>
References: <JIRA.13116256.1509891918000@Atlassian.JIRA> <JIRA.13116256.1509891918142@jira-lw-us.apache.org>
Subject: [jira] [Updated] (KAFKA-6173) Leader should stop accepting requests
 when disconnected from ZK
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sun, 05 Nov 2017 14:31:06 -0000


     [ 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, 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.


> 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)