[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Keeping a hot/live FSFS repo for failover

From: Jared Hardy <jaredhardy_at_gmail.com>
Date: 2006-10-21 05:34:30 CEST

On 10/17/06, Mark <mark@mitsein.net> wrote:
> as far as svnsync creating a 'read-only' mirror of the repository,
> that is only the recommended setup :). svnsync stores the metadata
> that it needs in the revprops for rev 0 on the target repository. In
> a failover situation, just set the revprops on the new target
> manually, and put the triggers in place on the new source.

That's an interesting fail-over clustering option for Subversion
repository commit access. One possibility I'm interested in, that this
option brings to mind, would be a Subversion cluster proxy front-end,
that just redirects requests to several back-end Subversion servers
from any given client.
    At any point in time, the front-end would know the current active
Commit server, but any read-only actions like Update or Checkout could
just be directed to any available mirror, in a load-balancing fashion.
The front-end servers could be fail-over clustered as well, to
maximize availability. They could even serve as arbitrators to help
determine the best current Commit server.
    Perhaps every user site could host their own front-end/proxy
servers, and each front-end could factor latency into its load-balance
choices, so available LAN mirrors would usually be chosen over remote
mirrors for any read-only actions. Commit server responsibility could
even be shifted on a schedule, based on predictable geographical usage
pattern changes. Just imagine -- each developer site could have its
own clustered mirror and front-end set (possibly in the same boxes),
so all read-only operations would behave at LAN speed, where only
Commits would depend on primary server WAN connection speeds. Each
site could have the current Commit server moved closer to them during
their peak commit times. That would be awesome!

Does anyone know any current way to implement such a front-end?

:) Jared

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Oct 21 05:35:09 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.