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

Re: Multi-master setup with Apache and NFS feasible ?

From: Tobias Gierke <Tobias.Gierke_at_freenet-ag.de>
Date: Tue, 18 Aug 2009 14:21:07 +0200

Hi,
> On Aug 18, 2009, at 06:22, Tobias Gierke wrote:
>
>>> You can add read-only mirrors if you need more performance. If you
>>> need everyone to be able to write too, then you can set up
>>> write-through proxying on those mirrors.
>>
>> Good point. This would probably be the easier solution (though this
>> whole 'svnadmin dump' stuff using a post-commit hook feels more like a
>> hack, not like a feature).
>
> That would be a hack. :) Perhaps you found outdated documentation.
> Since Subversion 1.4, there is an officially supported way to keep a
> read-only mirror: use the svnsync program. Though ideally you do call
> it from the post-commit (and post-revprop-change) hook(s), since you
> want it to synchronize as soon as any commit (or property change)
> happens.

This was actually taken from the SVN 1.5 documentation
(http://subversion.tigris.org/svn_1.5_releasenotes.html#webdav-proxy). I
probably should've read it more thoroughly though. It says " [...]An
example that does this using |svnadmin dump|/|svnadmin load| and ssh is
provided below. svnsync can probably do the same thing."

So the documentation seems to lack an updated example on how to do this
using svnsync.
>
>
>>> I have been told before that if you use a cluster filesystem like
>>> Apple's Xsan, you can have multiple master servers pointing at the
>>> same repositories and serving them simultaneously, which would help
>>> eliminate your Subversion server as a single point of failure (and
>>> instead make your NAS the single point of failure).
>>>
>>> AFAIK NFS by itself is not a cluster filesystem and thus couldn't be
>>> used in this manner.
>>
>> I can't see why you would need a cluster FS to do this. The main
>> difference between a network FS (NFS,CIFS etc.) and a cluster FS is the
>> fact that a cluster FS doesn't use a central server to manage data
>> access/locking. I think both solutions should work equally well
>> (although performance most likely is quite different).
>
> I don't have experience with these technologies myself, but I did
> participate in prior discussions of the topic on this list, e.g.:
>
> http://svn.haxx.se/users/archive-2007-05/0399.shtml
Thanks for the link , interesting food for thought ;-)

More than 2 years ago, someone
(http://svn.haxx.se/users/archive-2007-05/0381.shtml) stated:

>
> Subversion repositories can exist on NFS shares without problems,
> assuming your NFS implementation has working file locking
>
> However, until 1.5, there are some situations where multiple servers
> accessing the same NFS repository at the same time will cause some
> commits to fail due to the stale file handle issue of NFS.
> When i say multiple servers, i really mean multiple servers. There is
> no problem with a single server accessing an NFS share.
>
> This will not cause repository corruption, but is kind of annoying.

Unfortunately nobody replied to this (maybe a bold statement, given the
amount of people that complain about NFS locking issues) .

Regards,

Tobias

-- 
Tobias Gierke / Software Entwickler
tobias.gierke_at_freenet-ag.de
Tel.: +49 (0) 431-90-20566
Fax: +49 (0) 431-90-20570
freenet Cityline GmbH (Ein Unternehmen der freenet AG)
Am Germaniahafen 1-7
D-24143 Kiel
www.freenet.de / www.mobilcom.de / www.freenet.ag
Geschäftsführung: Christoph Vilanek, Stephan Esch, Andreas Jürgensen, Bodo Rebetge, Andreas Sand
Sitz: Kiel, Amtsgericht Kiel HRB 6202 KI
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2384726
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].

Received on 2009-08-18 14:22:09 CEST

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.