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

RE: Re: Subversion in Cluster mode tips?

From: Edelson, Justin <Justin.Edelson_at_mtvn.com>
Date: 2006-10-05 00:22:50 CEST

> Now what about a FSFS power repository? You can install it on a NFS,
> but the svn book says you shouldn't.
Where does it say that? All I see is "better yet, set up a real server
process..." (in the warning note about not using BDB on NFS). But this
is a far cry from telling you that you shouldn't do use FSFS on an NFS
mount.

-----Original Message-----
From: Johnathan Gifford [mailto:jgifford@wernervas.com]
Sent: Wednesday, October 04, 2006 5:42 PM
To: users@subversion.tigris.org
Subject: Re: Subversion in Cluster mode tips?

Okay, a bit of refinement: You cannot cluster a Subversion
repository.

There can only be one copy of the repository. So you cannot have two
(or more) Subversion 'servers' with there own active copy of the
repository that are synchronized automatically among all servers. So
clustering in the sense of a web application server like ColdFusion,
Java, or .NET doesn't exist. These types of cluster are generally
accessed through a single point of reference and all requests are
balanced across all available servers.

You can have one active repository and multiple mirrored (read-only)
repositories with Subversion 1.4.0 and the snvsync functionality. But,
this keeps you from committing changes back to the mirrored repository.
And there is not a single point of access to the repository because
there are multiple copies of the repository, but only one point of
access is writable. Since there are not multiple access points, this is
not clustering.

Now, if you consider a fail-over system as a 'cluster', this can be
done. This is because both servers have Subversion installed, but only
one has control of the repository. When the primary server fails to
respond, the second server can gain control of the repository and then
act upon requests to the repository. The problem here is that you
cannot balance the load (requests) between multiple servers because all
secondary servers are only lying in wait for their primary server to not
respond so it can take over. So, I do not consider fail-over system as
a true cluster.

But the real question about 'clustering' is, can you have multiple
Apache/Subversion servers that all have access to the same repository?
That is each Apache/Subversion server would mount a drive through NFS to
the repository. Now, you cannot do this with a Berkely DB power
repository because it cannot exist on a remote file system such NFS.
Now what about a FSFS power repository? You can install it on a NFS,
but the svn book says you shouldn't. And it does not say anything about
having multiple Apache/Subversion services accessing a single repository
over NFS. If you can do that, then you could cluster the 'services'
part of Subversion on separate servers with Apache as the cluster point
providing the single point of access. This is the setup that has me the
most curious if it would work. Anyone doing this without any problems?

Johnathan

>>> On Wed, Oct 4, 2006 at 2:58 PM, in message
<C5113BEB-2738-4A3F-B423-18AF03C29648@infomania.com>, Tom Mornini
<tmornini@infomania.com> wrote:
> On Oct 4, 2006, at 12:09 PM, Johnathan Gifford wrote:
>
>> You can't cluster Subversion.
>
> What do you mean by this?
>
> I think that may be too broad a statement in and of itself.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 5 00:23:33 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.