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

答复: the best migrate solution of lower downtime

From: wangbin <cliffwb_at_163.com>
Date: Mon, 11 Jul 2011 21:38:04 +0800

I have root on both of hosts, have the same OS and svn version
They are in a Lan network.
A DNS service can switchover domain name to IP.
Use http access file to control access permission .
Svn provide service for thousands of users.
CPU usage is too high to service normally all day and all night, clients even lost connection always, so I need migrate svn to a new high performance HW server...

So I think virtualization would not a good choice.

I intend to
1) rsync repo involved all access and hooks files as file system between the 2 hosts, will spend around 30 hours
2) disable DNS <=> close svn service
3) rsync repo again, spend within 1 hour
4) rsync apache service.
5) verify 2 hosts' repo md5 value.
6) restart apache and svn service on new host
7) switchover DNS

so expect downtime be controlled within 2hour.

Thanks
Wang,bin

-----邮件原件-----
发件人: users-return-9721-cliffwb=163.com_at_subversion.apache.org [mailto:users-return-9721-cliffwb=163.com_at_subversion.apache.org] 代表 Stuempfig, Thomas
发送时间: 2011年7月11日 20:00
收件人: users_at_subversion.apache.org
主题: AW: the best migrate solution of lower downtime

Migration depends on a lot of infrastructural constraints.

a) do you have full access of the servers
b) do you have virtualized systems, or plan to use on the new server.
c) what is the network layout between the servers, lan/wan,etc.
d) what is the allowed downtime.
e) is there a need for "cleaning" the data

All of these and probably other constraints should carefully be checked before being able to guide into a specific direction.

Amongst solution elements:
As others stated, you can use svn specific tools like svnsync.
An other approach would be more independent of svn:

You can also use, filesystem or volume snapshots, if available. Stop the svn before taking the snapshot to be sure of a consistent snapshot. Then you can mount the repository snapshot to the new server. If everything is prepared upfront, then you should be able to migrate in just about seconds.
Keep in mind, that you have a huge snapshot volume, since the snapshot volume will become your working volume. This way you can probably drastically bring down the downtime.
Another way to minimize downtime is to run your server in a VM. In case you want just to migrate the server HW. You can use VM specific tools and means to easily migrate. I personally did even live migration of XEN VM in - fractions of a second - downtime.

Snapshot as well as VM Technology has to be thoroughly planned before use.

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: Nico Kadel-Garcia [mailto:nkadel_at_gmail.com]
Gesendet: Samstag, 9. Juli 2011 20:42
An: Les Mikesell
Cc: users_at_subversion.apache.org
Betreff: Re: the best migrate solution of lower downtime

On Sat, Jul 9, 2011 at 12:54 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On 7/9/11 11:30 AM, Nico Kadel-Garcia wrote:
>>
>> 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.
>
> You can use svnsync to do the copy, then change the uuid to match the old
> one as long as the final transaction matches - that is you do not do any
> commits during or after the last sync run. It is much slower than rsync'ing
> the underlying files (and doesn't take hooks), but might be worth doing if
> the original repo started with an old version of subversion.

I've used that. It's potentially more dangerous, especially because
svnsync can be used with repository splitting.
Received on 2011-07-11 15:38:57 CEST

This is an archived mail posted to the Subversion Users mailing list.