Any tips on how move Django apps to NEW SERVER w/o much downtime?

Using Django Deployment
1

I’m trying to move Django apps to a new server. The “problem” is that my Django apps
have gotten successful so it isn’t possible to suffer lots of downtime while I slowly
move things over and check everything.

Anyone have any clever advice on how to minimize the downtime when doing this?

Chris

2

Upload the project to the new server, make sure it works properly, and then update the IP connected to the domain.

Isn’t that the best approach?

3

Yes but puzzle is how to do it w/o much downtime.

4

The biggest issue is identifying how much time is necessary to copy the database.

If you follow a procedure like:

  • Install system on new server
  • Copy existing data for testing.
  • Bring up the new server and test under a different DNS entry
  • Once you’ve verified that the new system works:
    • Stop the existing system
    • Copy the current data to the new system
    • Restart the new system and verify functionality
    • Change the DNS entry for the current system to the new server.

This limits your down-time to the window of time necessary to copy the data and change the DNS entry.

(There are ways of making the down time even shorter, but requires more time up front for configuration, including creating your database on the new server as a database replica of the existing server.)

5

Wouldn’t it be enough to keep the old server running until the IP that the domain points to is updated?

What exactly do you mean by “downtime”?

6

At some point you need to stop the old database being updated (e.g. don’t allow new sign-ups, or logins, or purchases, etc) so you can copy the data to the new database. And then you need to change the DNS. There will be some “downtime” – when people can’t do much on the old site – while the DNS change propagates.

7

This comes down mostly to the Db unless you have lots of media files as well.

You have a couple of approaches, but most will follow the broad steps that Ken outlined.
You then have couple of approaches.

  1. Take the old system down while shipping the data between the two servers.
  2. Put the old system in read-only mode (if possible) while shipping the data across. Obviously you’ll need a read-only mode to make this achievable.
  3. Some DB engines provide replication ability, so you could make a backup with a known log location and import that onto the new db server; then set up replication between the two servers, so changes on the old are then shipped to the new (and vice versa). Once everyone is moved across, you can disable replication.

Also you can reduce the DNS propagation windows by reducing TTL on your entries when you start the migration. You could also, at the end of the migration, effectively disable the old server by making it redirect to the new on it’s setup alias .