[LRUG] Destructive Migrations - best practices

Matthew Rudy Jacobs matthewrudyjacobs at gmail.com
Fri Mar 16 04:02:09 PDT 2012


>
> In one of my current projects, the implementation of one of the models is
> changing a reasonable amount. There will be a batch of new fields and a
> couple that are no longer required.


The first thing I'd consider is do you really want to remove the data?
If you don't, then just keep it there.

Secondly, what is the real chance that you are going to want to revert this
migration?

If its just a "in case of disaster" then I suggest before you run the
migration,
take the site down, do a db dump, and then migrate
(this is my usual process anyway)

If your database is too big to dump and rebuild,
then I suggest you take down the app
stop replication
and leave the replica ready to failover in the case of disaster.

If you just want to keep the data for archiving purposes
(maybe there's a 10% chance that in the future someone will ask you to
query it)
then take a dump before you do the migration and archive it.

I guess it depends on what this data is
and why you're removing it.

The simple answer would be
"if you are afraid of losing it, then don't remove it"

A few extra columns aren't going to do too much harm
after a week or so when you're happy you could remove them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20120316/0f157b0f/attachment-0003.html>


More information about the Chat mailing list