Re: Keeping a hot/live FSFS repo for failover

[Kyle Kline <ky...@gmail.com>]

One more follow-up on this:

I notice the UUID of the backup repo is different than the live repo, which
would cause issues with commits if we had to failover.

Is the below approach sufficient:
    copied the *backup* UUID as UUID.backup
    copied the live UUID file into the *backup* as UUID.live

In the event of a failover, do a
     copy UUID.live UUID  (windows folks, sorry)

And when "failing back" to primary, to turn it back into the sync/backup
    copy UUID.backup UUID


(Same with revprop 0, have a 0.backup and a 0.live)

-Kyle

On 10/30/06, Kyle Kline <ky...@gmail.com> wrote:
>
> Thank you.  It wound up being a permission issue.  Post-commits are
> working 100%.
>
> I am using this for web content authoring in an HA scenario for authoring
> -- the final solution is as follos:
>
> Hardware load balancer pointing traffic of http://dav/ to SVN/Apache on
> BoxA.
>
> Web site served by both BoxA and BoxB, load balanced for HA.
>
> On each commit, a post-commit on BoxA:
>
>    - asynchronously fires an svnsync sync http://dav-backup/ to Box B
>    (no commits are allowed to dav-backup url save the svnsync stuff)
>    - asynchronously fires an "svn update" to a working copy on Box A
>    that serves a web site
>
> Post-commit hook on Box B (triggered by svnsync commits from Box A):
>
>    - same async "svn update" to working copies of on Box B (in
>    practice, working copy on Box B is updated less than 0.25 seconds
>    after commit to repo on BoxA)
>    - synchoronously does a dump file append to a back up dump file (hit
>    of appending is not taken by primary commits/user)
>
> In a failure scenario, repoints traffic of http://dav/ to BoxB.  One
> manual step to change the revprops file on rev 0 on Box B, but other than
> that, pretty seamless.
>
> In restoration, run an svnadmin hotcopy to restore repo to Box A, repoint
> http://dav/ to Box A, restore revprops:0, and everyone is on their happy
> way again.
>
> On 10/30/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> >
> > On 10/30/06, Kyle Kline <ky...@gmail.com> wrote:
> > > Thanks all for the responses.  SVNSync works well for this purpose.
> > >
> > > A quick Q though -- I notice that when locally run on the mirror side
> > > (backup repo server), the svnsync also seems to run the post-commit
> > script
> > > hook (desired behavior for me, I append to a dump file) -- ie
> > > svnsync sync file:///c:/svn/myrepo
> > >
> > > However, if I trigger the sync from the primary (like in a
> > post-commit), the
> > > post-commit script does not seem to be run on the remote mirror box --
> > ie
> > >   svnsync sync http://svnbackup.domain.com/myrepo
> > >
> > > Any thoughts?  Or is that for a separate thread?
> >
> > It should always be running post-commits on the destination
> > repository, svnsync uses exactly the same mechanism to do the commit
> > as svn does, there should be no difference.
> >
> > -garrett
> >
>
>

Re: Keeping a hot/live FSFS repo for failover

[Garrett Rooney <ro...@electricjellyfish.net>]

On 11/16/06, Kyle Kline <ky...@gmail.com> wrote:
> Gotcha.  So maybe just be easier to set the UUID of the backup to be the
> same UUID as the primary (using your method, seems a bit safer), and that
> won't mess up anything?

The only potential issue is that if the UUID is the same it means it's
easy for someone to switch --relocate a working copy to the backup and
accidentally commit changes to it.  If you're not worried about that
(say because the backups aren't generally accessible) then it's safe.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Keeping a hot/live FSFS repo for failover

[Kyle Kline <ky...@gmail.com>]

Gotcha.  So maybe just be easier to set the UUID of the backup to be the
same UUID as the primary (using your method, seems a bit safer), and that
won't mess up anything?

Appreciate it!
-Kyle

On 11/16/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
>
> On 11/16/06, Kyle Kline <ky...@gmail.com> wrote:
> > One more follow-up on this:
> >
> > I notice the UUID of the backup repo is different than the live repo,
> which
> > would cause issues with commits if we had to failover.
> >
> > Is the below approach sufficient:
> >     copied the *backup* UUID as UUID.backup
> >     copied the live UUID file into the *backup* as UUID.live
> >
> > In the event of a failover, do a
> >      copy UUID.live UUID  (windows folks, sorry)
> >
> > And when "failing back" to primary, to turn it back into the sync/backup
> >     copy UUID.backup UUID
> >
> >
> > (Same with revprop 0, have a 0.backup and a 0.live)
>
> There is a "nicer" way to do it via svnadmin described in
> http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt, but yeah,
> you've got the general idea.
>
> -garrett
>

Re: Keeping a hot/live FSFS repo for failover

[Garrett Rooney <ro...@electricjellyfish.net>]

On 11/16/06, Kyle Kline <ky...@gmail.com> wrote:
> One more follow-up on this:
>
> I notice the UUID of the backup repo is different than the live repo, which
> would cause issues with commits if we had to failover.
>
> Is the below approach sufficient:
>     copied the *backup* UUID as UUID.backup
>     copied the live UUID file into the *backup* as UUID.live
>
> In the event of a failover, do a
>      copy UUID.live UUID  (windows folks, sorry)
>
> And when "failing back" to primary, to turn it back into the sync/backup
>     copy UUID.backup UUID
>
>
> (Same with revprop 0, have a 0.backup and a 0.live)

There is a "nicer" way to do it via svnadmin described in
http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt, but yeah,
you've got the general idea.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org