zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anirban Roy (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ZOOKEEPER-892) Remote replication of Zookeeper data
Date Mon, 09 May 2011 04:26:03 GMT

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

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

    Attachment:     (was: zoorepl.patch)

> 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
>
>         Attachments: zoorepl.patch, zoorepl.pdf
>
>   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

Mime
View raw message