On 1/29/07, Johnathan Gifford <firstname.lastname@example.org> wrote:
> For a failover setup like the one you mention below, if Apache's IP address and port it is serving on doesn't respond, then failover. Since your using Apache as your access method to Subversion, Subversion itself is not affected by communication issues. You may want to install the Subversion binaries on the NFS mount though.
Good idea. That takes away much of the hassle of keeping the two
> I'm not a Solaris expert, but you may be able to have both servers NFS mount the repository drive at the same time and the Apache instances on both servers running at the same time. If you have a load balancer, you could utilize both servers at the same time. That way all resources are always active instead of one waiting to take over. There were some issues with NFS in versions earlier than Subversion 1.3.x, but that may have been taken care of now if you use the FSFS repository format (which is default).
I am using FSFS. I was planning on having the filesystem mounted on
two systems at the same time, but only so we can quickly fail over if
one goes down. Won't the repository be corrupted if two servers are
actively writing to the same repository at the same time? If not, I
am confused as to how.
> For your DR site. Consider using the svnsync feature from Subversion 1.4.x. This will create a mirror that is synchronized immediately with your primary site server. In the event of a disaster, you'll only need to modify revision 0 of each repository mirrored to make it writable on the server at the DR site.
svnsync is on my list of things to look into. I wanted to make sure
hooks and config files in the repository are synced as well and didn't
think svnsync handled that. I read in the book "Practical Subversion"
that rsync can be used to backup an FSFS repository as long as the
file db/current is copied first.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Jan 29 22:32:32 2007