[jira] [Updated] (ZOOKEEPER-892) Remote replication of Zookeeper data

["Anirban Roy (JIRA)" <ji...@apache.org>]

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

Anirban Roy updated ZOOKEEPER-892:
----------------------------------

       Due Date: 15/Apr/11  (was: 31/Jan/11)
    Description: ZooKeeper is a highly available and scalable system for distributed synchrony and is frequently used for cluster management. In its current incarnation it has issues with communication and data replication across extended geographic locations. Presently, the only way to distribute ZooKeeper across multiple data centers is to maintain a cross-colo Quorum using Observer members, leading to unnecessary consumption of bandwidth and performance impacts. As the title suggests, this work aims to to provide replication of ZooKeeper data from one site to others using a new type of ZooKeeper member called a Publisher. The broad idea is to have a complete instance of the current ZooKeeper at each geographic location in a master-slave setup. The Publisher will be a part of the Master ZooKeeper Site and will push changes to a FIFO queue and make it available to any interested client. The slave ZooKeeper runs client application called Replicator which receives and replays the changes to slave instance. Multiple slave Replicators can subscribes to the master Publisher and receive changes with guaranteed ordering. It will be asynchronous, non-intrusive, loosely-coupled and can be applied to a subset of the data. This scheme will bring about many of the benefits of database replication such as resilience to site failure and localized serving across data centers. In short, the goal is to provide remote (sub-tree) data replication with guaranteed ordering, without affecting the Master ZooKeeper performance.  (was: ZooKeeper is a highly available and scalable system for distributed synchrony and is used for cluster management. In its current incarnation it has issues with cross-colo communication and data replication. Presently, the only way to distribute ZooKeeper across multiple data centers is to maintain a cross-colo Quorum using Observer members, leading to huge bandwidth consumption and performance degradation. The idea behind the ZooKeeper replication feature is to provide replication of ZooKeeper data from one site to others using a new type of ZooKeeper member called a Replicator. The Replicator will be asynchronous, non-intrusive, and can be applied to a subset of the data. It will be a part of the Main ZooKeeper Site and will push changes to multiple data centers with guaranteed ordering of events. This will bring about many of the benefits of database replication such as resilience to site failure and localized serving across data centers. In short, the goal is to provide remote (sub) data replication with guaranteed ordering, without affecting the Main ZooKeeper performance.)
           Tags: zkrepl replication zoorepl  (was: zkrepl replication)

> Remote replication of Zookeeper data
> ------------------------------------
>
>                 Key: ZOOKEEPER-892
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-892
>             Project: ZooKeeper
>          Issue Type: New Feature
>          Components: quorum
>    Affects Versions: 3.4.0
>         Environment: [root@llf531123 Zookeeper]# uname -a
> Linux llf531123.crawl.yahoo.net 2.6.9-67.0.22.ELsmp #1 SMP Fri Jul 11 10:37:57 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
> [root@llf531123 Zookeeper]# java -version
> java version "1.6.0_03"
> Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode)
> [root@llf531123 Zookeeper]# 
>            Reporter: Anirban Roy
>            Assignee: Anirban Roy
>             Fix For: 3.4.0
>
>   Original Estimate: 2688h
>  Remaining Estimate: 2688h
>
> ZooKeeper is a highly available and scalable system for distributed synchrony and is frequently used for cluster management. In its current incarnation it has issues with communication and data replication across extended geographic locations. Presently, the only way to distribute ZooKeeper across multiple data centers is to maintain a cross-colo Quorum using Observer members, leading to unnecessary consumption of bandwidth and performance impacts. As the title suggests, this work aims to to provide replication of ZooKeeper data from one site to others using a new type of ZooKeeper member called a Publisher. The broad idea is to have a complete instance of the current ZooKeeper at each geographic location in a master-slave setup. The Publisher will be a part of the Master ZooKeeper Site and will push changes to a FIFO queue and make it available to any interested client. The slave ZooKeeper runs client application called Replicator which receives and replays the changes to slave instance. Multiple slave Replicators can subscribes to the master Publisher and receive changes with guaranteed ordering. It will be asynchronous, non-intrusive, loosely-coupled and can be applied to a subset of the data. This scheme will bring about many of the benefits of database replication such as resilience to site failure and localized serving across data centers. In short, the goal is to provide remote (sub-tree) data replication with guaranteed ordering, without affecting the Master ZooKeeper performance.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira