svn-multisite-plus drwxr-xr-x 2 wandisco wandisco 4096 Dec 5 01:16 bin -rwxr-xr-x 1 wandisco wandisco 6258 Mar 13 18:34 common.sh -rwxr-xr-x 1 wandisco wandisco 552 Mar 13 18:34 multisite_enterprise_shutdown.sh -rwxr-xr-x 1 wandisco wandisco 595 Mar 13 18:34 multisite_enterprise_start.sh -rwxr-xr-x 1 wandisco wandisco 378 Mar 13 18:34 replicator_shutdown.sh -rwxr-xr-x 1 wandisco wandisco 400 Mar 13 18:34 replicator_start.sh -rwxr-xr-x 1 wandisco wandisco 5480 Mar 13 18:34 start_install.sh -rwxr-xr-x 1 wandisco wandisco 3689 Mar 13 18:34 start_upgrade.sh -rwxr-xr-x 1 wandisco wandisco 357 Mar 13 18:34 ui_shutdown.sh -rwxr-xr-x 1 wandisco wandisco 379 Mar 13 18:34 ui_start.sh -rwxr-xr-x 1 wandisco wandisco 524 Mar 13 18:34 wdog_rep.sh -rwxr-xr-x 1 wandisco wandisco 725 Mar 13 18:34 wdog_ui.sh drwxrwxr-x 2 wandisco wandisco 4096 Dec 5 13:21 config -rw-rw-r-- 1 wandisco wandisco 5 Dec 5 13:53 setup.pid -rw-rw-r-- 1 wandisco wandisco 256 Dec 5 13:56 license.key drwxrwxr-x 2 wandisco wandisco 4096 Dec 5 14:20 local-ui -rw-rw-r-- 1 wandisco wandisco 1020 Dec 5 14:35 ui.properties drwxrwxr-x 2 wandisco wandisco 4096 Dec 5 14:20 logs -rw-rw-r-- 1 wandisco wandisco 32647705 Dec 6 09:50 replicator.log.20121205-142035 -rw-rw-r-- 1 wandisco wandisco 775889 Dec 6 15:00 replicator.log.20121206-101206 -rw-r--r-- 1 wandisco wandisco 1185 Mar 14 09:40 start_install.20130314-094034 -rw-r--r-- 1 wandisco wandisco 18606 Mar 14 10:14 ui.log.20130314-094038.1960 -rw-r--r-- 1 wandisco wandisco 3506 Mar 15 11:50 ui.log.20130314-101437 -rw-r--r-- 1 wandisco wandisco 809 Mar 14 10:14 wdog_rep.20130314-101436 -rw-r--r-- 1 wandisco wandisco 1012 Mar 14 10:14 wdog_ui.20130314-094038 -rw-r--r-- 1 wandisco wandisco 807 Mar 14 10:14 wdog_ui.20130314-101436 drwxr-xr-x 8 wandisco wandisco 4096 Dec 5 14:20 replicator drwxr-xr-x 2 wandisco wandisco 4096 Mar 15 09:48 content drwxr-xr-x 5 wandisco wandisco 4096 Mar 14 10:14 database drwxr-xr-x 3 wandisco wandisco 4096 Mar 13 18:34 docs drwxr-xr-x 6 wandisco wandisco 4096 Mar 13 18:34 lib drwxr-xr-x 2 wandisco wandisco 4096 Mar 13 18:34 licenses drwxr-xr-x 4 wandisco wandisco 4096 Mar 15 14:24 logs -rw-r--r-- 1 wandisco wandisco 1079544 Mar 13 18:34 ms5-replicator.jar drwxr-xr-x 2 wandisco wandisco 4096 Mar 14 09:40 properties -rw-r--r-- 1 wandisco wandisco 1079560 Mar 13 18:34 upgrade.jar -rw-r--r-- 1 wandisco wandisco 26 Mar 13 18:34 VERSION drwxrwxr-x 2 wandisco wandisco 4096 Dec 5 13:21 systemdb drwxr-xr-x 3 wandisco wandisco 4096 Dec 5 01:16 ui
The following files store application settings and constants that may need to be referenced during troubleshooting. However, you shouldn't make any changes to these files without consulting WANdisco's support team.
Subversion MultiSite provides a toolset for replicating Subversion repository data in a manner that can maximise performance and efficiency whilst minimising network and hardware resources requirements. The following examples provide you with a starting point for deciding on the best means to enable replication across your development sites.
In contrast with earlier replication products, Subversion MultiSite: Enterprise Edition is no longer based upon a network proxy that handles file replication between replica. Now, replication is handled at the filesystem level, via FSFS.
Subversion MultiSite Enterprise edition differs from earlier WANdisco replication products on a number of levels.
Subversion MultiSite Enterprise edition differs from earlier versions in that it replicates at the file system level.
Subversion MultiSite is able to replicate on a per-repository basis. This way each site can host different sets of repositories and replicate repositories this means that you can have different repositories replicate as part of different replication groups.
No need for a synchronized stop - Subversion MultiSite Enterprise allows replication groups to change their membership on-the-fly.
A repository can only replicate to a single replication group at any one time, although it is possible to move between replication groups as required - this can now be done on-the-fly, nodes can be added or deleted without the need to pause all replication (with a synchronized stop)
Subversion MultiSite Enterprise offers a great deal of flexibility in how repository data is replicated. Before you get started it's a good idea to map out which repositories at which locations you want to replicate.
SVN MultiSite Plus is able to maintain Subversion repository replication (and availability) even after the loss of nodes from a replication group. However, there are some configuration rules that are worth considering:
The unique Active-Active replication technology used by SVN MultiSite Plus is an evolution of the Paxos algorithm, as such we use some Paxos concepts which are useful to understand:
Learners:
Learners are the nodes that are involved in the actual replication of Subversion repository data. When changes are made on the local repository copy these nodes raise a proposal for the changes to be made on all the other copies.
Learner Nodes are required for the actual storage and replication of repository data. You need a learner node at any location where Subversion users are working or where you wish to store hot-backups of repositories
Types of Nodes that are learners: Active, Passive
Acceptors:
All changes being made on each repository in exactly the same order is a crucial requirement for maintaining syncronization. Acceptors are nodes that take part in the vote for the order in which proposals are played out.
Acceptor Nodes are required for keeping replication going. You need enough Acceptors to ensure that agreement over proposal ordering can always be met, even accounting for possible node loss. For configurations where there are a an even number of voters it is possible that voting could become tied. For this reason it is possible to make a voter node into a tie-breaker which has slightly more voting power so that it can outvote another single voter node.
Types of nodes that are Acceptors: Voter Only
Nodes that are both an Acceptor and Learner: Active Voter, Passive Voter
Two-node replication groups are not fault tolerant, you should strive to replicate according to the following guideline:
The number of learner nodes required to survive population loss of N nodes = 2N+1
where N is your number of nodes.
So in order to survive the loss of a single node you need to have a minium of 2x1+1= 3 nodes
In order to keep on replicating after losing a second node you need 5 nodes.
During the installation of each of your nodes you are asked to provide a Content Node Count number, this is the number of other learner nodes in the replication group that need to receive the content for a proposal before the proposal can be submitted for agreement.
Setting this number to 1 ensures that replication won't halt if some nodes are behind and have not received replicated content yet. This strategy reduces the chance that a temporary outage or heavily loaded node will stop replication, however, it also increases the risk that repositories will go out of sync (requiring admin-intervention) in the event of an outage.
Running with two nodes per site provides two important advantages.
Each replication group consists of a number of nodes and a selection of repositories that will be replicated.
There are now some different types of site:
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: 16:12 - Tuesday 29nd January 2013