3. Technical Guide
3.1 Benefits of running with Git MultiSite
This guide runs through everything you need to know to get Git MultiSite deployed. First we'll cover all the things that you need to have in place before you install. We'll then cover a standard installation and setup. Finally we'll look at some possible problems you might experience with some troubleshooting tips.
LAN-speed Performance Dramatically Shortens Development Cycles and Reduces Cost
- WANdisco’s patented replication technology, Distributed Coordination Engine (DConE), fulfills Git’s distributed promise for developers at every location.
- Every developer pushes to a local master repository for maximum performance.
- Peer-to-peer architecture with no single point of failure eliminates the performance and scalability bottleneck of a central master repository server.
- Enables global collaboration – no geographic limitations.
- New nodes can be added on the fly to support new locations or increased load.
- Immediate active-active replication eliminates WAN latency and ensures repositories are always in sync, enabling fast conflict resolution.
- Developers at remote sites no longer hold back commits until the end of the day/week as they may have in the past due to poor network performance.
- Update conflicts and other problems are found and fixed as they occur, so less time is spent on QA and rework.
Zero Downtime and Zero Data Loss
- WANdisco's unique replication technology turns distributed repositories into replicated peers, providing continuous hot-backup by default.
- Every Git MultiSite node is fully replicated and writable, providing an out-of-the-box High Availability / Disaster Recovery (HA/DR) solution.
- Recovery is automatic after a server outage (planned or unplanned), eliminating lost productivity during maintenance or server crashes. In addition, the risk of human error from manual recovery procedures is completely eliminated.
Enables Continuous Availability for Global Software Development
- WANdisco's unique replication technology turns Git repositories distributed over a WAN into replicated peers, providing continuous hot-backup by default, as part of normal operation.
- Hot deploy features make it possible to add new Git repositories to a multi-site implementation, or take existing servers offline for maintenance without interrupting usage for other sites.
- When new repositories are added, or existing servers are brought back online they automatically sync with others.
Easy to Administer
- All sites can be administered from a single location.
- New replicated and fully readable and writeable Git nodes can be quickly set up with no custom coding.
- Built-in self-healing capabilities make disaster recovery automatic without any administrator involvement.
No Retraining Required
- Git functionality does not change with Git MultiSite – no proprietary back-ends.
- No retraining required – developers and administrators continue using the tools they're familiar with.
3.2 How Git MultiSite Works
Git MultiSite provides a toolset for replicating Git 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.
Replication Model
Per-Repository Replication
Git 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.
Dynamic Membership Evolution
No need for a synchronized stop - Git MultiSite 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, sites can be added or deleted without the need to pause all replication (with a synchronized stop)
Git MultiSite 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.3 Limitations of the current version of Git MultiSite
-bare repositories
When setting up a repo to share it must to use the "--bare" option, this means there is no local working set associated with the repo. This limits the number of ways in which the repo can be modified.
3.4 Available Node Types
Each replication group consists of a number of sites and a selection of repositories that will be replicated.
Here are the different types of nodes:
Active- An Active node has users who are actively committing to 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.
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.
Passive- A node on which repositories receive updates from other nodes, but doesn't permit any changes to its replicas from clients - effectively making its repositories read-only. Passive nodes are ideal for use in providing hot-backup.
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.
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.
A disabled node can be re-enabled without the need to interupt the replication group. 
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.
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.
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.
Copyright © 2010-2013 WANdisco plc.
All Rights Reserved
This product is protected by copyright and distributed under licenses restricting copying, distribution and decompilation.