views:

40

answers:

3

For a bit fall cleaning, I am moving 25 tables between MySQL databases (different pieces of hardware). This is not the WHOLE database, just 25 tables out of a few hundred... These tables don't really belong in there, I won't go into why for NDA reasons.

Now, this is going to break a lot of code and sql queries.

What is the best way to go about doing this?

  1. Move them all over at once.

  2. Move them over 1 by 1

--

Moving them over all at once, is kind of nice. Might be some outages and broken code that I missed, but moving them as a block is much faster, less time spent in pushing code out.

Moving them over one by one is kind of nice, less chance of big stuff breaking, but a LOT more time will be spent micromanaging the work, redundant work, and deploying.

Is it possible for me to mirror the tables between two databases for a while? A federated table perhaps?

--

Misc info: There are 25 tables are all related by content to each other.

I cannot shutdown the databases for hours at a time, about 5 minutes of downtime would be acceptable.

--

What is the best way to go about moving all of this data and keeping the code, sql, and me in great shape?

Could I federate the tables as a way of replicating the tables to a new database?

-daniel

+1  A: 

It seems like moving them over one at a time would be the way to go. That way you have a bunch of easy little problems instead of a big hard problem. I hope you have your system under a lot of automated tests to make sure all this shuffling doesn't break anything.

Another thing: you talk about shutting down the database. If you're making the changes in a development environment and only making the changes live when you're sure everything works, why would you need to have any downtime in production? I hope you're not thinking about making these changes in production without doing it in development first.

Jason Swett
The test coverage isn't as good as it could be, then I wouldn't worry too much about it. However, there are lots of little ity bity programs running around and talk to the database, and I'm sure I won't be find the code everywhere and get 100% coverage. Which would be the cause of production downtime.
Daniel
In addition, I can't deploy everything at once. There are various bits of code here and there. Which is why I'm interested in having the same table in both places. (Federated mysql tables)
Daniel
A: 

Been there, done that, and actually in the middle of a similar project right now. With our projects, we inherited a few that we don't know what they are or where everything is, but here is the general flow:

  • On new server, set up any appropriate accounts
  • Find where to change the server and username/passwords if necessary in the application config
  • Shut down the web application so there aren't any writes while moving
  • Move the DB
  • Reconfigure the app
  • Fire it back up
  • Repeat for each DB/application

For small stuff, this only takes a few seconds. SQLyog is a great help here. If you have large databases or decide you don't want any downtime, then you need to consider replication.

Brad
Moving the tables and data is easy! It's trying to manage all of the code/sql changes!
Daniel
In the past, we have resorted to doing a text search through all of the code, looking for the username of the MySQL account. That helps.
Brad
A: 

You can use SQLYog (mysql front end) to do it.

Meny option is Powertools -> Database Synchronization wizard

You must be able to open both database remotely (host % should be there)

gajendra.bang