[
https://issues.apache.org/jira/browse/ZOOKEEPER-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13657716#comment-13657716
]
Flavio Junqueira commented on ZOOKEEPER-892:
--------------------------------------------
Right, I haven't looked at this issue in a while. If I remember correctly, one
nice property is that it builds on ZooKeeper and doesn't require changes. If we
filter directly in ZooKeeper, we either do it on the leader or on the observer.
If we choose the leader, then it is more work and configuration for the leader.
If we choose the observer, then we are sending cross-colo messages
unnecessarily.
Overall it sounds like a reasonable design, but the question is if anyone is
interested in using this feature. It is ok with me to have it in, but I'd like
to have a champion for it.
> 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
