views:

19

answers:

2

I need a local copy of our production database, and I need to refresh it every few days so testing and development is not working with terribly stale data. A few days old is just fine. Here is the pseudo plan:

  1. Write a script on the Production server that mysqldump's + gzip the database.
  2. Add a cron process to run the script every other day during non-peak hours.
  3. Write a script on the workstation that rsync's that gzipped dump and loads it up.

Is there any better, cleaner, or safer way of doing this?

EDIT: Just to add clarity. We still have in place Test Data that is known, along with our test library (test driven development). Once THOSE tests pass, its on to the (more) real stuff.

A: 

You may wish to consider MySQL replication. It isn't a thing to be trifled with but may be what you are looking for. More information here... http://dev.mysql.com/doc/refman/5.0/en/replication-features.html (I don't personally know anything about it other than that it can be done).

Brian Hooper
When you replicate it is possible to accidentally replicated updates from the test environment to the production environment.
John
No. Replication works from the 'master' to the 'slave'; by defining the production database as the master, updates will only flow away from it.
Brian Hooper
A: 

Testing should be working with "known" data; not production data. You should have scripts to load "Test" data into the system to achieve this. Test/Dev shouldn't have to deal with a moving target of data. Besides, if you have any sensitive data in production (doesn't everyone"); your dev/test teams shouldn't have access to it.

Some suggestions for creating test data: 1) Excel spreadsheets with VBA behind them to create sql to run against the DB 2) Raw sql scripts 3) Data creation programs that generate data in a known pattern.

DancesWithBamboo
I can't say that I'm in complete agreement with this. The object of testing is to ensure that the system works in the way the customers desire, and a very convenient way to do this is to test on the data they are using. A modest database of extreme cases might be handy, but it's generally best to concentrate your testing on the way the system is actually used.
Brian Hooper