[jira] [Commented] (KAFKA-50) kafka intra-cluster replication support

["Jun Rao (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269821#comment-13269821 ] 

Jun Rao commented on KAFKA-50:
------------------------------

I have updated the replication V3 design wiki: https://cwiki.apache.org/confluence/display/KAFKA/kafka+Detailed+Replication+Design+V3 by incorporating the content from V2. We plan to do the implementation based on the V3 design. If there are concerns, please add your commend to the design wiki.

The following is a list of open jiras, roughly in order of dependency and importance.

Phase 2 (Basic message replication, with testing and tools and minimum fancy features)
KAFKA-335: Embedded controller (1w)

KAFKA-336: Admin RPC between controller and broker (1.5w)

KAFKA-337: Upgrade ZKClient to allow conditional updates through ZK (0.5w)

KAFKA-301: Broker startup (revisit based on v3.E design, 1.5w)

KAFKA-302: Leader election, become leader, become follower (v3. A,C; 2.5w)
   Depends on KAFKA-301

KAFKA-329: Create topic support (revisit based on v3 design, 1w)

KAFKA-46:  Replica fetch, leader commit (v3.G design, 2.5w)
  Depends on KAFKA-301
  Depends on KAFKA-302

KAFKA-338: controller failover (V3. D 2w)

KAFKA-339: Multifetch for follower (1.5w)

KAFKA-306: Fix broker failure test on 0.8 branch (1w)

KAFKA-330: Delete topic support (1w)
  Depends on KAFKA-301

KAFKA-327 Monitoring and tooling support (2w)

Phase 3 (System tests and more advanced features like preferred replica leadership transfer, online partition reassignment)
KAFKA-174 Performance suite for Kafka (2w)
KAFKA-42 Online partition reassignment (3w)
KAFKA-43 Preferred replica leadership transfer (1w)

                
> 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
>
>
> 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)
> Here is a complete design proposal for Kafka replication - https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Replication

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