2

My little team is just a few days from launching our web page. Its another user content type page so a lot of our data will be about user preferences and behavior. We decided to get it out of the door as soon as minimal functionality is ready and tested but have grand plans of more stuff to be implemented while its live.

These things will most likely include new columns in data tables and maybe even complete reinterpretations of existing ones. Those kinds of changes will likely take a long time to implement and we'd like to keep the downtime to a minimum. We think we have it figured out by

  1. creating a parallel database with the new structure
  2. swapping the software to a transitory one that would duplicate new user submissions to both the old and the new database while still using the old database
  3. simultaneously converting data from the old db to the new one
  4. swap the software to the final release that only uses the new db
  5. discard the old db

This would result in 2 very small downtimes (less than a second really) separated by whatever amount of time it takes to complete the transfer of old data (likely being throttled and done at low activity times to not disturb the response performance).

We have all our db access methods set up to make whipping up the transitory version as easy as possible, sounds like a good plan? How do the big guys(like google or facebook) do it?

We're using asp.net + MariaDB if that matters.

  • 1
    Adding columns and tables can be done on the existing db, it's called a migration. So at least for this use case there is no need to completely swap the database (not to mention the effort to write code that serves two databases at the same time). 'reinterpretation' of existing data may depend on what exactly that would mean and how much data needs to be processed and possibly changed. But still I would prefer to add a new table and limit the impact to this part of the db instead of moving around whole databases. – thorsten müller Sep 3 '15 at 13:45
  • 1
    Create a mirror environment of live copy (database included) and perform a mock update on that. If that turns out well, then plan the actual update the following day. If the update changes in the meantime, you perform another mock update with the changes. In short, you should already know if the update will go well, no exceptions. – Neil Sep 3 '15 at 13:52
1

For telecoms customers where downtime directly affects revenue and multicomponent migrations are often done in a one night process, we have used versioned table names and background scripts that replicate and convert the data prior to a cutover. That way testing can be done against the new version of the table which has a complete set of data against whict to test. At the same time, queues can drained and the software can bounced to immediately start using the new version of the table at the time of cutover.

It also allows a relatively easy backout if something was missed and the software needs to be reverted because the data is all there. Once the migration has been confirmed successful, the old table can be dropped.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.