Re: multiple svn front-ends, single SAN repo volume

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 :)
Received on 2012-02-11 06:30:48 CET