views:

73

answers:

2

Hi,

We are looking at database replication for rolling deploys. It gets complicated as our deploys involve data migrations too. What would be a good replication scheme.

I guess my question is on how to setup the replication.

Supposing we have 4 webservers and 2 database servers, how do I make the update so that all the writes are replicated properly.

  1. Take down half of webservers, update code
  2. Take down first database server, migrate it up to use the new code base
  3. Bring back up the first databse server, then the 2 webservers

  4. Do the same with the other half.

But the problem with this scenario is how do you transfer the non-migrated database data to the migrated database.

Thanks

Note: Apologize my question wasn't clearer earlier

A: 

There are tools that perform migrations for you. Some frameworks have specific tools which do a lot of the work for you, like South for Django. Migrate4j is a more generic solution.

John Paulett
A: 

Do you have all of your code in version control? If so, you could use a deployment tool such as Capistrano to deploy the same codebase to a numbers of servers: Deploying to multiple servers. This way you could revert back to any point (read: revision number) in the repository fairly quickly should anything go wrong. It will also speed up deployment of large codebases as only the changed/new files are uploaded to the server rather than everything.

As for the database, how exactly are you deploying it? Are you just updating structures or the core data as well? Are the two DB servers used for load-balanced? If they are on the same switch/LAN you could potentially setup something like NDB Cluster:

  1. http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-overview.html
  2. http://en.wikipedia.org/wiki/MySQL%5FCluster
KushalP