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
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:
> 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?