Mailing-List: contact kafka-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: kafka-dev@incubator.apache.org
Date: Thu, 5 Jan 2012 17:52:39 +0000 (UTC)
From: "Jun Rao (Updated) (JIRA)" <jira@apache.org>
To: kafka-dev@incubator.apache.org
Message-ID: 
 <286709103.10481.1325785959723.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (KAFKA-50) kafka intra-cluster replication support
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/KAFKA-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jun Rao updated KAFKA-50:
-------------------------

    Attachment: kafka_replication_detailed_design_v2.pdf

Attach v2 of the detailed design doc. Made 2 minor changes:

1. V1 design has 2 separate ZK paths for a broker, one registered and one alive. Simplify it to have just 1 ZK path for live broker. The implication is that if a topic is created while a broker is down, no partition will be assigned to that broker. Since topic creation is infrequent, this is likely not a big issue.

2. Use broker id as replica id for each partition, instead of using an explicit replica id.

                
> kafka intra-cluster replication support
> ---------------------------------------
>
>                 Key: KAFKA-50
>                 URL: https://issues.apache.org/jira/browse/KAFKA-50
>             Project: Kafka
>          Issue Type: New Feature
>            Reporter: Jun Rao
>            Assignee: Jun Rao
>             Fix For: 0.8
>
>         Attachments: kafka_replication_detailed_design_v2.pdf, kafka_replication_highlevel_design.pdf, kafka_replication_lowlevel_design.pdf
>
>
> Currently, Kafka doesn't have replication. Each log segment is stored in a single broker. This limits both the availability and the durability of Kafka. If a broker goes down, all log segments stored on that broker become unavailable to consumers. If a broker dies permanently (e.g., disk failure), all unconsumed data on that node is lost forever. Our goal is to replicate every log segment to multiple broker nodes to improve both the availability and the durability. 
> We'd like to support the following in Kafka replication: 
> 1. Configurable synchronous and asynchronous replication 
> 2. Small unavailable window (e.g., less than 5 seconds) during broker failures 
> 3. Auto recovery when a failed broker rejoins 
> 4. Balanced load when a broker fails (i.e., the load on the failed broker is evenly spread among multiple surviving brokers)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira