On Sat, Jul 9, 2011 at 12:00 PM, wangbin <cliffwb_at_163.com> wrote:
> Hi,
> I will migrate a svn service from a old host a.com to another new host
> b.com, the repository is more than 600G.
> What's the best solution of lower downtime?
>
> Thanks a lot!
> Wang,bin
There are numerous approaches, with tradeoffs.
* Buy Wandisco's "MultiSite" software. Allow it to synchronize both
sites, or preferably 3 sites, then turn off the old site. Costs money,
but supports future migrations and failover, and does a very
thoughtful job of keeping them in sync according to my discussions
with them.
* If both systems run the same version of subversion on similar
architectures, and you're not doing a version update in the process,
consider doing rsync between host 1 and host 2. You can pre-stage
that, set host 1 to be "read-only" with a pre-commit.hook, do a final
rsync, then activate the other host by re-enabling your pre-commit
hooks. Polnt your users to the new repo, they can use "svn switch
--relocate" comands to reset their working copies to the new repo, and
the changeovers are minimal. If you can do a CNAME or DNS switchover
with the same overall URL's, even better.
Scheduling the switchover time is left to the reader. If you do this,
your old host must NEVER, NEVER, NEVER be used again in write-mode.
There are numerous others, such as pre-staging with "svnsync" to
switch arachitures or refactoring of projects into different
repositories, or finally getting things under $URL/project/trunk
instead of $URL/trunk/project.. In that case, the UUID's of the
repositories would be distinct, and switchover for clients is
trickier. But that leaves you the opportunity to dump old ISO's and
spurious branches and tags that contained passwords and things like
that. Consider it an opportunity rather than a burden, if you've been
hoping to do that.
Received on 2011-07-09 18:31:13 CEST