Home / server / Questions / 511289
Accepted
Jevgeni Smirnov
Asked: 2013-05-28 23:25:21 +0800 CST

Moving linux server to another hoster

  • 772

I have a task to move linux server from 1 dedicated server to another.

In general my plan following:

  1. night time - turn off httpd and mysql. RSYNC via SSH.
  2. day time - turn on http and mysql.
  3. night time turn off httpd and mysql. RSYNC via SSH.
  4. night time. turn on httpd and mysql on both servers. Change DNS entries.
  5. day time. monitoring server status.

So mostly both for syncing mysql and httpd I would use rsync(no mysqldump).

Sounds good? Any caveats?

linux

1 Answers

  1. Best Answer

    I suggest two solutions. Personally, I prefer the Logical Clone method because it can be done with less downtime, and database replication is a versatile capability to acquire for other reasons. However, the Exact Clone method, which is similar to what you proposed, is a generic brute-force approach to migrating any server.

    Exact Clone

    1. Reduce the TTL of your DNS entries to make your life easier.
    2. rsync source to target. You don't even have to shut down services on the source; any inconsistencies will get fixed in steps (4) and (7).
    3. Optionally, you can run some tests the new server. Figure out what configuration changes you need to make on the target server to make things work. You might even want to reboot the target machine to make sure everything comes up cleanly.
    4. rsync source to target again, to undo whatever "damage" to the new server you introduced in (3), to pick up some more differences, and to get a feel for how much time it takes to run an incremental rsync (which is an indicator for how much downtime to expect).
    5. Shut down all services on both machines. Make sure services on the source machine stay off; you don't want a "split brain" with diverging data on the old and new machines.
    6. Make changes to your DNS entries. You can use a normal TTL for the new entries, assuming you don't plan to roll back.
    7. rsync source to target again.
    8. Apply any configuration changes you need on the target machine, as discovered in step (3).
    9. Start services on the target machine.

    Logical Clone

    Look into setting up MySQL replication. If you don't already have binary logging enabled on your MySQL server, you'll have to briefly bounce your database to enable it. In any case, I highly recommend enabling binary logging anyway because it is handy for doing future operations like upgrading MySQL with nearly zero downtime.

    If you set up circular replication, you might even be able to run both the old and new webservers simultaneously, if MySQL is your application's only data store.

    • 3