views:

1063

answers:

3

I have a test server that uses data from a test database. When I'm done testing, it gets moved to the live database.

The problem is, I have other projects that rely on the data now in production, so I have to run a script that grabs the data from the tables I need, deletes the data in the test DB and inserts the data from the live DB.

I have been trying to figure out a way to improve this model. The problem isn't so much in the migration, since the data only gets updated once or twice a week (without any action on my part). The problem is having the migration take place only when it needs to. I would like to have my migration script include a quick check against the live tables and the test tables and, if need be, make the move. If there haven't been updates, the script quits.

This way, I can include the update script in my other scripts and not have to worry if the data is in sync.

I can't use time stamps. For one, I have no control over the tables on the live side once it goes live, and also because it seems a bit silly to bulk up the tables more for conviencience.

I tried doing a "SHOW TABLE STATUS FROM livedb" but because the tables are all InnoDB, there is no "Update Time", plus, it appears that the "Create Time" was this morning, leading me to believe that the database is backed up and re-created daily.

Is there any other property in the table that would show which of the two is newer? A "Newest Row Date" perhaps?

A: 

If you have an autoincrement in your tables, you could compare the maximum autoincrement values to see if they're different.

But which version of mysql are you using?

John Fiala
The problem isn't just in if the data is there, but if the data matches, unfortunatley. This is what really got me worried about it. Even though it's a test site, some of the tests involve real world situations (one being a timesheet that needs to have the right data, etc). So it's crucial that the data be as up to date as possible, without me getting caught with my pants down saying, "Oops, let me run the updater." The version is 5.0.76 Enterprise GPL
Anthony
A: 

Rather than rolling your own, you could use a preexisting solution for keeping databases in sync. I've heard good things about SQLYog's SJA (see here). I've never used it myself, but I've been very impressed with their other programs.

Todd Gardner
+2  A: 

In short: Make the development-live updating first-class in your application. Instead of depending on the database engine to supply you with the necessary information to enable you to make a decision (to update or not to update ... that is the question), just implement it as part of your application. Otherwise, you're trying to fit a round peg into a square hole.

Without knowing what your data model is, and without understanding at all what your synchronization model is, you have a few options:

  1. Match primary keys against live database vs. the test database. When test > live IDs, do an update.
  2. Use timestamps in a table to determine if it needs to be updated
  3. Use the md5 hash of a database table and modification date (UTC) to determine if a table has changed.

Long story short: Database synchronization is very hard. Implement a solution which is specific to your application. There is no "generic" solution which will work ideally.

razzed