>>> On Mon, Jan 29, 2007 at 3:31 PM, in message
<94a776e70701291331m27712230l547fc1670fa74579@mail.gmail.com>, "Justin Johnson"
<justinjohnson@gmail.com> wrote:
> On 1/29/07, Johnathan Gifford <jgifford@wernervas.com> 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
> boxes identical.
>
>> 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.
>
It's been explained to me that the with FSFS format, the file locking with the Subversion binaries the transaction files in the FSFS directories keep things in check. But this means putting a set of Subversion binaries on each server and not the NFS mount. However, the binaries don't require much configuration. As you said, hooks scripts and other stuff involving the repositories themselves is where all the configuration occurs.
>
>>
>> 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.
>
Hooks scripts are not to bad. You could write a shell script to send them over and cron the script. Afterall, they should hardly ever change after they're setup. You could do the same with your config files.
As far as the backup on a FSFS repository, you would be correct. But I think the svnsync would do a better job in that there is little or no lag time between syncs. This is because the remote repository can be configured to be a live mirror. I'm waiting to upgrade our primary server in two weeks from 1.3.x to 1.4.x. This will be the first feature I'll start testing with for use with our DR site. But the info about svnsync looks very promising.
>
> Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 29 22:51:53 2007