On 12/11/06, Rob van Oostrum <rob.vanoostrum@blastradius.com> wrote:
[snip]
> I did a prototype a little while ago
> using one writable repository with any number of read-only mirrors
> that would reverse-proxy any attempt to write to the repository to
> the single back-end writable repository. This seemed to work just
> fine, and it gives you the single point of transactional scope needed
> to prevent conflicts and collisions in the absence of a distributed
> transaction capability. I used rsync to run the synchronization back
> to the mirrors, but there's no reason why svnsync couldn't come in
> handy here.
[snip]
How did you implement the reverse-proxy? I have been looking for a
solutions for multi-homing the svn repository, for read-only type
operations (update) via svnsync, and using a reverse-proxy for write
operations (commit). I've looked into Pound, but it's not clear to me
how to separate the HTTP request operations from HTTP DAV write
operations, especially if I want Pound instances to run on the same
servers as the svn mirrors, so that each client can just target their
geographically preferred mirror. I also need everything to go through
HTTPS/SSL tunnels, end-to-end, so that complicates proxy setup a bit.
Did you use Apache2 mod_proxy? If you did, is it possible to
configure read requests through a local mod_svn instance, and route
only DAV writes through mod_proxy?
Someone mentioned it might be possible to hack svnsync mirror
instances, to operate as primary repositories via config files, as
long as some arbitrator is careful about insuring that only one
primary is enabled at any point in time, to act as a sort of split HA
cluster. I would then like to allow the proxy target to change along
with the primary repository move, probably via the same arbitrator
system. Right now, I suppose I just need some way to separate the
reverse-proxy writes from the local reads. I suppose in the worse
case, the arbitrator would just have to shut down all active servers,
edit configuration files, and then restart all servers when the new
configuration is complete. This would introduce some down time, but
not nearly as much as a primary repository server outage.
Thanks!
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Dec 12 08:01:18 2006