1. Install directory Structure

drwxr-xr-x 2 wandisco wandisco 4096 Dec  5 01:16 bin

        -rwxr-xr-x 1 wandisco wandisco 6258 Mar 13 18:34
        -rwxr-xr-x 1 wandisco wandisco  552 Mar 13 18:34
        -rwxr-xr-x 1 wandisco wandisco  595 Mar 13 18:34
        -rwxr-xr-x 1 wandisco wandisco  378 Mar 13 18:34
        -rwxr-xr-x 1 wandisco wandisco  400 Mar 13 18:34
        -rwxr-xr-x 1 wandisco wandisco 5480 Mar 13 18:34
        -rwxr-xr-x 1 wandisco wandisco 3689 Mar 13 18:34
        -rwxr-xr-x 1 wandisco wandisco  357 Mar 13 18:34
        -rwxr-xr-x 1 wandisco wandisco  379 Mar 13 18:34
        -rwxr-xr-x 1 wandisco wandisco  524 Mar 13 18:34
        -rwxr-xr-x 1 wandisco wandisco  725 Mar 13 18:34

drwxrwxr-x 2 wandisco wandisco 4096 Dec  5 13:21 config
        -rw-rw-r-- 1 wandisco wandisco 5 Dec  5 13:53

-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

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

2. Properties Files

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.

file contains settings for the replicator and affects how MultiSite performs. [view sample]
handles properties that apply to how logging is handled. [view sample]
handles properties that are used for managing remote access through the API. [view sample]
contains settings concerning the graphical user interface such as widget settings and timeout values. [view sample]

3. Replication Strategy

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.

3.1 Replication Model

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. ** This is history **

Subversion MultiSite Enterprise edition differs from earlier WANdisco replication products on a number of levels.

Limitations of the old model

** This is history **

Subversion MultiSite Enterprise edition differs from earlier versions in that it replicates at the file system level.

3.1.1 Per-Repository Replication

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.
** Alert! **

3.1.2 Dynamic Membership Evolution

** evolution without stopping work **

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.

3.2 Creating resilient Replication Groups

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:

Rule 1: Understand Learners and Acceptors

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:

Rule 2: Replication groups should have a minimum membership of three learner nodes

Two-node replication groups are not fault tolerant, you should strive to replicate according to the following guideline:

Rule 3: Learner Population - resilience vs rightness

Rule 4: 2 nodes per site provides resilience and performance benefits

Running with two nodes per site provides two important advantages.

4. Guide to Node Types

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:

** node **Active
An Active node has users who are actively committing to Subversion repositories, which results in the generation of proposals that are replicated to the other nodes. However, it plays no part in getting agreement on the ordering of transactions.
** node **Active Voter
An Active Voter is an Active node that also votes on the order in which transactions are played out. In a replication group with a single Active Voter, it alone decides on ordering. If there's an even number of Active Voters, a Tiebreaker will have to be specified.
** node **Passive
A node on which repositories receive updates from other nodes, but doesn't permit any changes to its replicas from Subversion clients - effectively making its repositories read-only. Passive nodes are ideal for use in providing hot-backup.
** node **Passive Voter
A passive node that also takes part in the vote for transaction ordering agreement.

Use for:
  • Dedicated servers for Continuous Integration servers
  • Sharing code with partners or sites that won't be allowed to commit changes back
  • In addition, these nodes could help with HA as they add another voter to a site.

  • ** node **Voter (only)
    A Voter-only node doesn't store any repository data, it's only purpose is to accept transactions and cast a vote on transaction ordering. Voter-only nodes add resilience to a replication group as they increase the likelyhood that enough nodes are available to make agreement on ordering.

    The Voter-only node's lack of replication payload means that it can be disabled from a replication group, without being removed. ** node **
    A disabled node can be re-enabled without the need to interupt the replication group.
    ** node **Tiebreaker
    In the event of even number of voters in the Replication Group the Tiebreaker gets the casting vote. The Tiebreaker can be applied any type of voter: Active Voter, Passive Voter or Voter.
    ** node **Helper
    When adding a new site to an existing replication group you will select an existing site from which you will manually copy or rsync the applicable repository data. This existing site enters the 'helper' mode in which the same relevant repositories will be read-only until they have been synced with the new site. By relevant we mean that they are replicated in the replication group in which the new site is being added.
    ** node **New
    When a site is added to an existing replication group it enters an 'on-hold' state until repository data has been copied across. Until the process of adding the repository data is complete, New nodes will be read-only. Should you leave the Add a Node process before it has completed you will need to manually remove the read-only state from the repository.