This does look brittle to me (race conditions causing sync to fail). See https://www.gitlab.com/high-availability/ for supported options.
On Wed, Apr 30, 2014 at 11:15 PM, Harri Kwok <[email protected]> wrote: > To elaborate: I've set up 2 instances of GitLab. The DB's will be working > in Master / Slave mode where site 1 will be the master, site 2 is the slave > The home/git/repositories directories will be mirrored in "real time" > ssh keys will be rsynced > public folders (attachments / etc) rsynced > > For administration (sshkeys/group/repo creation), users would use site 1. > > Issues: > What's happening is that site 2's Gitlab UI is very slow when we configure > it to site 1's gitlab DB. > I'm thinking it's the roundtrip time that's causing the delay > > GitLab UI stats (commits, branches) are off but when clicked you're able to > see the right amount of commits and branches. > The stats data doesn't appear to be coming from GitLab DB. > > -Harri > > > On Friday, April 25, 2014 1:53:25 PM UTC-4, Harri Kwok wrote: >> >> Would there be any issue pointing 2 git instances that are replicated (git >> repos and ssh keys) to a single remote MySQL DB? >> >> -H > > -- > You received this message because you are subscribed to the Google Groups > "GitLab" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "GitLab" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
