7

We have no continuous integration setup(, yet). But want to deploy very frequently. Once a day or so.

We have a pretty standard Django application with a separate Postgres server. We use normal rented VMs (NO Amazon or Rackspace).

How can we minimize the downtime of our application? Best would be to zero downtime. We thought about a setup with two equal application and two database servers and deploy one app/db server pair after another.

The problem is keeping the data consistant. While one app/db server pair is updating the server pair with the old code can serve users. But if the users write to the db we would lose the data when switching to the updated pair. Especially when we push schema migrations.

How can we handle this? This must be a very common problem but I can't find good answers. How do you handle this problem?

j7nn7k
  • 17,995
  • 19
  • 78
  • 88

1 Answers1

2

In the case that you have no schema migrations, I'll give you a practical scenario:

Keep two versions of django processes ( A and B ), which you control with, let's say, supervisor. Keep an nginx process in front of your django processes, which forwards all requests to A. So, you upload version B to the server, start the django process B with supervisor, then change your nginx's conf file to point to B, then reload your nginx process..

In the case that you have schema migrations, things get complicated. Your options include:

  • You could consider using a NoSQL solution, like mongoDB (in this case you can keep a single DB instance).
  • Figure out how to manually record all write requests while uploading, as to push them later to your new database.
hymloth
  • 6,869
  • 5
  • 36
  • 47
  • 2
    I upvoted, but just because you have a schema migration isn't instant grounds for migrating to MongoDB. Simply write your schema migration(s) so you can do this: upgrade the schema, deploy new app, upgrade the schema again to add any constraints that would have been incompatible with the old version of the app. Now your biggest concern will be locking: you don't want the app to be non-responsive while your migration is running. Doing some testing will usually tell if this is a problem (long-running migration means it probably will be). If so, you need replication… – Hank Gay Jan 21 '13 at 15:11
  • And then you'd migrate the not-primary first, then promote it to primary and push the old primary to not-primary, then migrate it. The details of that would depend on your replication solution, but it should be feasible. – Hank Gay Jan 21 '13 at 15:15
  • Well noSQL is not an option. We're pretty happy with postgres. Can you recommend a good replication solution? – j7nn7k Jan 24 '13 at 17:47