I do those migrations regularly. No downtime is hard, but low or allmost un-noticeable downtime is possible. The general idea is :
- Do a hot backup of the origin server to the new one; that's a complete working copy while your origin is still working (on a LAMP server: run mysqldump on the origin then transfer the whole filesystem via rsync onto the target)
- Either 1/ put the origin in read-only mode (
shell> mount -remount o,ro /path/to/fs +
mysql> flush tables with read lock) if the app handles it well, or 2/ display a maintenance page
- Do a cold incremental backup, ie. re-dump your SQL and only transfer what was modified since the hot backup. With rsync, the cost merely depends on the number of inodes (files) on your target because they must all be tested for modification; it's rarely a bandwidth problem. On 1 - 10 GB sites with 100 - 500k inodes this incremental backup takes 1 sec to 1 min in my experience.
- Setup a reverse proxy on the origin that redirects all trafic to the new target. You're done, and you can rollback in a few seconds if there's a problem (drop the reverse proxy part on the origin server). Obviously you have prepared the configuration in order a simple call to
apachectl graceful is sufficient to apply it.
- If everything went smoothly, you may finalize the migration and update your DNS (I usually do this 24h later). Then wait for the trafic to stop flowing from your origin server (usually another 24-48h).
Details are more tricky, but when it's your job and you're used to it it's actually easy. Besides knowing how to run 'rsync', 'mysqldump' and setting up a reverse proxy with a few lines in Apache, you're done.
Quite often you have to adjust a few things which are different from the origin and target server (like the hostname). In this case I write a small script that automates the backup part and the 'fixes' (using sed, perl, etc.). With
rsync -a --delete you can use the same script for hot and cold backups.
The nice thing about this is that you don't depend on the DNS. In my experience DNS hosting is always awful or barely in control of the site owner. DNS updates from many DNS providers are unpredictable and un-debuggable. The TTL is ignored or mangled by most caching DNS servers. You run into this funny time window where many people don't see the same server using the same name, and it makes for very bad client relationships. Putting DNS out of the equation is a big win for me (unless I can directly host the DNS zone and then I'm 100% in control, but that's another story).