Question

I have two servers that share an original ancestor codebase, but which have changed during the past couple of months in terms of database schema (I’m using mysql). I’m about to use the second one as my new production server, but I have to update the data (there are new users, there’s new data related to those users, etc.). I want the data in the server that’s now live, but has the old schema to have the authority, yet I want the schema in the new one to be the final one. So it’s kind of a weird merge: I want data from the old server to be imported into a new server with a (not vastly) different schema.

I was thinking of simply making a dump of the server with the most up-to-date data, but then loading it wouldn’t work since the schema has changed quite a bit.

I was also thinking on dumping the schema of the new server, applying it to a copy of the old one, then dumping the data from the latter and loading it into the new one, but I’m not sure how to go about doing that and if it’s the safest option.

I develop on mac OS X and both of my servers are debian.

Answer 1

Applying the schema from the new server to the old and then migrating data is the safest option, largely because it forces you to evaluate what specifically has changed and what you want to do about that in terms of data (e.g., where a new column is added, what do you want to put in it)?

Since you mentioned the schemata are not massively different, simply doing a mysqldump without data (i.e., tables only) of each server and manually comparing (e.g., with diff) would tell you what columns are different. You can then apply those changes with ALTER on the old database.

It’s all a little kludgy, but then ultimately there isn’t really a non-kludgy way of doing this.