We've two nodes running heartbeat/drbd, and one of the services we're using is subversion. What I want to know is: is it safe to run svnserve on both nodes all the time, or should it only run on the active node?

Does svnserve use file-level locking, or is it all in memory? What are the implications of running svnserve without its repositories accessible?

Please let me know if this isn't clear, and I'll try my best to rephrase/clarify. :)


I would presume that as you have heartbeat controlling failover, you are running an active/passive DRBD cluster. As such, at time of failover heartbeat on passive detects that it must promote itself to active. In this process it (usually) broadcasts the fact it's taking over the primary's VIP then mounts the DRBD disk. This makes the disk accessible to the filesystem, and finally heartbeat brings up the necessary software (MySQL, Apache etc) as per haresources.

You should add any extra services you require to start after failover to your /etc/ha.d/haresources file in the format:

#node1 Filesystem::/dev/sda1::/data1::ext2
db1 drbddisk::mysql Filesystem::/dev/drbd0::/drbd::ext3::defaults mysql

with the appropriate startup script in /etc/ha.d/resource.d/mysql (or named relative to the script's function!) - further details in Configuring haresources, the drbd manual and OpenVZ wiki

The crux of the matter is that there is effectively no disk for svnserve to read your repositories from until it's taken over as active, as the drbd process locks it when in passive mode. It is possible to run DRBD active/active, but it's a relatively new feature and not something I've tried!

One gotcha that's not well documented: instead of using the hb_takeover scripts to test failover, simply terminate the heartbeat service on the primary and wait for the secondary to take over, watching on both servers with tail -f /var/log/ha-log. This has the added bonus of testing the deadtime, warntime and initdead parameters of ha.cf which are all important in a real world failover.

  • Thanks for the tips. If I'm reading your comments correctly, they summarise as: "mu; svnserve won't run without its repositories to read". I know how to configure multiple services to start/stop with a failover (or failback); I was hoping to keep it as simple as possible. I guess it's going to have to get complicated... :( – fredden Feb 9 '10 at 20:10
  • That's about it. What's the desired end result and why? – Andy Feb 10 '10 at 15:07
  • I'd like to keep the heartbeat failover/failback process as simple as possible. Starting/stopping lots of services will slow the process down, and there are more points of potential failure. At the moment, I've got a few things, with manual failover for the rest; but I was hoping I could just run svnserve on both hosts, and forget about it. – fredden Feb 10 '10 at 20:29
  • Simplicity is always preferable, but in the case of failover (when you've already got heartbeat in place) I'd just order the services by precedence - the most important will come up first, and svnserve will eventually come up (at most a couple of minutes after secondary is escalated to primary) and you may avoid having to get up in the middle of the night :) – Andy Feb 11 '10 at 10:54

Yes, you can run 2 svnserve processes simultaneously as long as you're running on a cluster-aware filesystem that doesn't let them both write to the same file at the same time.

You can run svnserve and httpd on the same repo for example without problems.

The repository is locked by a file, when commit occur, the upload goes to a transaction directory, when its complete that txn is applied to the repo atomically. This section of the svn book details how multiple processes can serve svn data simultaneously over different protocols.

  • In our set-up, the file-system is only mounted in one place, and drbd does block-level synchronisation. – fredden Jun 11 '10 at 5:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.