I agree with Thomas that this is not so much about git, per se, as it is 
having your host be "highly available". How you do this depends on what 
your host software is, such as Windows, Linux, *BSD, AIX, HPUX, Solaris, or 
something else.

In a nutshell, you basically need dynamic DNS so that somebody could go to 
"git.mycompany.com" and that would give out the current IP address of the 
"master copy". But you then need some why for one of the backup hosts to 
dynamically change that name to point to itself if it detects that the 
"master" goes down. In my limited experience, this is normally done by a 
"heartbeat" going out from the "master" to each of the "backup" hosts on a 
timed basis. When a backup detects that the heartbeat has stopped, it does 
recovery by reassigning the DNS to itself, after coordinating with the 
other "backup" host.

The other part is the git part and I don't know how to do it off the top of 
my head. Basically, as I understand it, you want someone to be able to push 
to the master git repository. The master git repository would then push out 
to the backup repositories. But the pushed data would not be available on 
the master or any backup until until all three repositories agree and are 
in sync. This may be possible by using a post-update hook to delay 
advancing the HEAD reference until all three repositories can do it 
"simultaneously". But I'm too ignorant of git to yet know of how to use a 
"hook" to do this.

On Sunday, November 18, 2012 11:33:40 PM UTC-6, Thomas Koch wrote:
> Hi,
> what would you call best practice for a highly available git hosting 
> setup? We have servers in 3 datacenters. At best a git push should only 
> complete if the data has been stored in at least two datacenters. The git 
> "master" should automatically switch if one datacenter isn't available.
> Thank you very much,
> Thomas Koch
> P.s. I hope google does not send this message as HTML?


Reply via email to