Setting up Git replication to help with backups and scalability may seem easy: just use a read-only mirror. In reality, setting up reliable Git replication, particularly in a large global deployment, is much more difficult than simply creating a mirror. That’s where Git MultiSite comes in.
Replication is Hard
Let’s look at a few of the challenges involved in managing a Git deployment. If you’re an enterprise Git administrator, I’ll wager that you’ve run into several of these problems:
-
Failures will happen – especially in a WAN environment. Network interruptions, hardware failures, user error: all of these factors interrupt the ‘golden path’ of simple master-mirror replication. Since Git doesn’t provide replication out of the box you need to either write your own tools or rely on a free mirror solution. In either case you won’t have a replication solution that stands up to every failure condition.
-
Replicas get out of sync. When a failure happens, it must be reliably detected and corrective action must be taken. Otherwise, a replica can be out of sync and contain old or incorrect data without your knowledge.
-
Replication should be the first tier in your High Availability / Disaster Recovery (HA/DR) plan. Your data is the most important thing you own and you want a multi-tiered strategy for keeping it safe. Unreliable replication takes away a vital part of that strategy. Plus, failover is hard. Even if you have a perfect backup, how quickly can you bring it online and redirect all of the connections to it? How do you fail back when the primary server is back online?
-
Security is essential. Every Git mirror should be subject to the same access control rules, yet there is almost no capability to enforce that in most systems.
-
The biggest sites need replication more than anyone. Are you running 50 Git mirrors to support a large distributed user base and build automation? How are you monitoring all of those mirrors?
Git MultiSite Solution
So how does Git MultiSite solve these problems?
All failure conditions are accounted for.
Git MultiSite uses a patented algorithm based on the Paxos design. That means that it accounts for all failure conditions in the algorithm itself. Dropped data, not enough nodes online to agree on a proposal – these are all accounted for in the design. It’s hard stuff, and that’s why we wrote a very long paper on it.
Easy monitoring and administration.
Git MultiSite monitors the consistency and availability of each replicated peer node. The administration console tells you at a glance if anything is out of sync.
Clik here to view.
MultiSite Dashboard
Zero down time.
If a node is out of sync it will go offline automatically while work continues on other peer nodes. Failover is accomplished instantly with a load balancer or manually by using a secondary Git remote. When a node recovers it will catch up automatically (failback) and start participating in new activity.
Consistent security across the deployment.
Access control is consistent across every node. Using flexible replication groups you can control where a repository is replicated and how it is used at a site.
Clik here to view.
Replication group
Guaranteed data safety.
Every commit is guaranteed to reach at least one other node before it is accepted, guaranteeing the safety of your data. The content delivery system has several parameters you can adjust to suit your deployment.
How Important is Your Data?
If you need a zero down time solution with guaranteed data safety, start a free trial of Git MultiSite’s reliable Git replication. Our team of Git experts can help you get started.
Clik here to view.
About Randy DeFauw
Randy DeFauw is Director of Product Marketing for WANdisco’s ALM products. He focuses on understanding in detail how WANdisco’s products help solve real world problems, and has deep background in development tools and processes. Prior to joining WANdisco he worked in product management, marketing, consulting, and development. He has several years of experience applying Subversion and Git workflows to modern development challenges.