Re: multiple svn front-ends, single SAN repo volume
From: Bruce Lysik <blysik_at_yahoo.com>
Date: Fri, 10 Feb 2012 21:29:45 -0800 (PST)
We have a single server installation which is currently not fast enough.
The LB pair + 3 svn front-ends + SAN storage is not strictly for performance, but also for reliability. Scaling vertically would probably solve performance problems in the short term, but still wouldn't address single points of failure.
Thanks for all the responses to this thread, it's very educational.
Bruce Z. Lysik <blysik_at_yahoo.com>
From: Stefan Sperling <stsp_at_elego.de>
To: Ryan Schmidt <subversion-2012a_at_ryandesign.com>
Cc: Nico Kadel-Garcia <nkadel_at_gmail.com>; Bruce Lysik <blysik_at_yahoo.com>; "users_at_subversion.apache.org" <users_at_subversion.apache.org>
Sent: Friday, February 10, 2012 2:16 PM
Subject: Re: multiple svn front-ends, single SAN repo volume
On Fri, Feb 10, 2012 at 04:09:45PM -0600, Ryan Schmidt wrote:
> Have you verified that a single server will not be fast enough?
Good point. It might very well be fast enough.
> If so, you could consider having any
> number of read-only slave servers, which would each proxy their write
> requests back to the single master server that Subversion supports.
> This way read operations would be accelerated, while write operations
> would be securely limited to just the single master. The slave servers
> could keep individual copies of the repository(ies) synchronized with
> the master using svnsync
This is misleading. A write-through proxy setup does not eliminate
write operations on slave servers.
While replicating commits, svnsync performs the exact same kinds of
write operations against the slave servers that happen on the master
repository when a client makes a commit.
In fact, in the corrupted rep-cache.db case I mentioned earlier,
the write operation to the CIFS share was performed by svnsync
(luckily, only the slave was storing its repositories on CIFS :)
This is an archived mail posted to the Subversion Users mailing list.