[
https://issues.apache.org/jira/browse/ZOOKEEPER-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13657685#comment-13657685
]
Alexander Shraer commented on ZOOKEEPER-892:
--------------------------------------------
Hi Flavio,
So the main advantage of this scheme over simply using observers is that the
proposed feature can replicate only a portion of the data, correct ? In that
case, and if such a functionality is still needed, maybe its worth to consider
a simpler alternative - a static or dynamic way for an observer to specify the
subtree(s) in which it is interested. The leader can then inform the observer
only about things in which it is interested.
> Remote replication of Zookeeper data
> ------------------------------------
>
> Key: ZOOKEEPER-892
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-892
> Project: ZooKeeper
> Issue Type: New Feature
> Components: server
> 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.5.0
>
> Attachments: zoorepl.patch, zoorepl.patch, zoorepl.pdf
>
> Original Estimate: 2,688h
> Remaining Estimate: 2,688h
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
