Aim : do the migration for N cubicweb instances hosted on a server to another with no downtime.
Prerequisites : have an explicit definition of the database host (not default or localhost). In our case, the database is hosted on another host. You are not migrating your pyro server. You are not using multisource (more documentation on that soon).
Steps :
on new machine : install your environment (pseudocode)
apt-get install cubicweb cubicweb-applications apache2
on old machine : copy your cubicweb and apache configuration to the new machine
scp /etc/cubicweb.d/ newmachine:/etc/cubicweb.d/ scp /etc/apache2/sites-available/ newmachine:/etc/apache2/sites-available/
on new machine : give new ids to pyro registration so the new instances can register
cd /etc/cubicweb.d/ ; sed -i.bck 's/^pyro-instance-id=.*$/\02/' */all-in-one.conf
on new machine : start your instances
cubicweb start
on new machine : enable sites and modules for apache and start it, test it using by modifying your /etc/host file.
change dns entry from your oldmachine to newmachine
shutdown your old machine (if it doesn't host other services or your database)
That's it.
Possible enhancements : use right from the start a pound server behind your apache, that way you can add backends and smoothily migrate by shuting down backends that pound will take into account.
- cubicweb #473794 when an entity type is renamed, physical db index should be renamed as well
- cubicweb #1768109 [migration] add_cube will create missing entities from unrelated cubes
- cubicweb #2167873 ease static data/ directory handling
- cubicweb #890167 [win32/service] ctl migrate does not handle service mode
- cubicweb #1113844 Migration script function to reindex a given entity
Comments
Hi Arthur, and thanks for this interesting post. How does your migration handle running user sessions? Florent.
I don't really know how the internals of user sessions work... if they are in RAM, then I guess that they will be lost which beats the "no downtime" for logged in user.
Reading http://www.cubicweb.org/ticket/635587 which deals with a restart, it seems that cubicweb doesn't handle that. Maybe we should add a ticket for such a feature (dump & restore of session info - then we would have to integrate that to the migration)