kafka-jira mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kostas Christidis (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (KAFKA-6173) Leader should stop accepting requests when disconnected from ZK
Date Sun, 05 Nov 2017 14:31:00 GMT

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

Mime
View raw message