Replication Groups are units of organization that we use to manage replication of certain repositories between certain sites. In order to replicate a Subversion repository between two or more nodes, you would need to associate by adding them to a replication group:
An organization with developers working in Chengdu and San Fransisco need to collaborate on projects stored in two SVN repositories, Repo1 and Repo3. An administrator in the Chengdu office creates a replication group called "DragonGroup". The SVN MultiSite Plus nodes corresponding with each of the two sites are added to the group.
Replication Group Example 1
The Chengdu office is the location of largest development team, where most repository changes occur. For this reason the node is assigned the role of Tie-breaker. In the event that there is disagreement between the nodes in the group over transaction ordering, NodeChengdu will carry the deciding vote.
The node in San Fransisco hosts a standard active node. Changes to the local repository are replicated to NodeChengdu, changes made on the Chengdu node are replicated back to San Fransisco.
In addition to the two active nodes, a third node, NodeParis is added, located at a management site that plays no active part in development. However, the node has been added to the group as a "pure voter". This means that NodeParis takes part in the vote for transaction ordering, even though the payload of those transactions are not written to repository replicas stored at the Paris office. The purpose of NodeParis is simply to add resilience to the replication system, in the event of a short-term disruption to traffic from one of the other two nodes, agreement can still be reached and replication could continue.
The organization might choose to make the Paris node "Passive" instead. With ParisNode running a passive node, replicas of Repo1 and Repo3 would also be stored in Paris, although these copies could only be changed by updates from the other (active) repository copies, they wouldn't be accessible to SVN clients.
There's another element controlled by replication groups, the role that each repository replica plays the replication system, where each replica may be casting a vote in order to determine the correct order in which proposals are played out. See more about Types of Sites.
You can create a replication group providing that you have at least two sites connected.
Replication Groups
Group names
Add some sites - you need a minimum of two
The local node is automatically made the first member
It's not possible to create a replication group remotely, the initiating node is alsways added automatically.
Replication groups
You can view and partly edit a replication groups by clicking on the button.
You can configure a replication group by clicking the Configure button that appears on the group's "Quick View" screen.
It's possible to add additonal nodes to a replication group. Click on the Add Nodes button to start the procedure, you can read about it in the Admin Guide - 13. Adding a node to a replication group
The Schedule screen lets you set the roles of sites to change over time, specifically changing according to a schedule.
At the heart of WANdisco's DConE2 replication technology is an agreement engine that ensures that Subversion operations are performed in exactly the same order on each replica, on each node. Any node that has the role of voter becomes part of the agreement engine and together with other voters determine the correct ordering. If there's high latency between any voters this may adversely affect replication performance. Fortunately it isn't a requirement that every site takes part in forming agreement. An Active site can still create proposals (i.e. instigate repository changes) but the agreement engine doesn't need to wait for its vote. Read more about how replication works in the Reference Section.
So in order to optimize replication performance it's common for administrators to remove voter status from node after their staff leave for the day - a practice commonly known as "Follow The Sun" where far-flung organisations transfer roles and privileges between locations so that they are always held by an active, manned site.
To see how to setup a schedule, see the SVN MultiSite Plus Admin Guide - How to configure a schedule
Copyright © 2010-2013 WANdisco plc.
All Rights Reserved
This product is protected by copyright and distributed under
licenses restricting copying, distribution and decompilation.
SVN MultiSite Plus
Last doc build: 12:51 - 20th June 2013