3 ms·

There won't be general-purpose walkthroughs, because the general answer is "don't change the database structure of a database that's serving live traffic: You'l

There won't be general-purpose walkthroughs, because the general answer is "don't change the database structure of a database that's serving live traffic: You'll never enumerate all the things that could possibly go wrong." In most specific cases, there are alternatives to stopping the show during an upgrade. First, you check your backups! Then, there are various strategies. You can make many simple schema changes while the system is running. Or put the DB in read-only mode and still mostly manage to serve pages -- perhaps with an occasional HTTP 503, so hopefully that's okay -- during your upgrade. Or phase in changes over several releases, carefully architecting for backward compatibility. Or bring up a parallel system and gradually migrate active users to it. Depending on what you're doing, you may find yourself having to write a special upgrade script that migrates old formats to new formats, or even using database triggers to keep "old" and "new"-format tables in sync during the transition. A well-constrained database may help keep things sensible during the transition -- or, you may have to drop half of your supposedly-sensible constraints just to make the transition work. Moral: Even if you know exactly what you're doing, live updates are more work: More planning, more code, more infrastructure, and/or more stress. In many real-world cases, you should just take the system down for a minute. Focus your engineering effort on making sure that "minute" is as short as possible, and in making sure that you can detect problems and roll back as quickly as possible.

rorrr 15y ago
> the general answer is "don't change the database > structure of a database that's serving live traffic: > You'll never enumerate all the things that could > possibly go wrong." And what if you need to? Even adding an index on a large table can slow down the things tremendously. Let alone adding/deleting columns with indexes. "Don't do it" is not really an answer. > Or put the DB in read-only mode and still mostly > manage to serve pages Of yeah, let's put our credit card processing app in the read-only mode during the day. What can possibly go wrong, just those silly 503s.
- mechanical_fish 15y ago
  Perhaps I need to reiterate: The reason there aren't a lot of general-purpose walkthroughs is that there is no general case. The closest thing we have to a general-purpose solution is: Take the system down, do the upgrade, put the system back up. But, yes, this is often not a very good answer. It is often a lousy and expensive answer. In which case you hire engineers to build a better strategy. And I can't tell you, dear reader, what that better strategy is going to be, because it's different from case to case, and I don't know what your problem is. And, yes, of course you shouldn't use the sloppy strategies on your financial-transaction processing app. Just as you probably shouldn't spend three engineer-weeks designing a complex zero-uptime rollout strategy for your blog comment system.

rorrr 15y ago

> the general answer is "don't change the database > structure of a database that's serving live traffic: > You'll never enumerate all the things that could > possibly go wrong." And what if you need to? Even adding an index on a large table can slow down the things tremendously. Let alone adding/deleting columns with indexes. "Don't do it" is not really an answer. > Or put the DB in read-only mode and still mostly > manage to serve pages Of yeah, let's put our credit card processing app in the read-only mode during the day. What can possibly go wrong, just those silly 503s.

mechanical_fish 15y ago
Perhaps I need to reiterate: The reason there aren't a lot of general-purpose walkthroughs is that there is no general case. The closest thing we have to a general-purpose solution is: Take the system down, do the upgrade, put the system back up. But, yes, this is often not a very good answer. It is often a lousy and expensive answer. In which case you hire engineers to build a better strategy. And I can't tell you, dear reader, what that better strategy is going to be, because it's different from case to case, and I don't know what your problem is. And, yes, of course you shouldn't use the sloppy strategies on your financial-transaction processing app. Just as you probably shouldn't spend three engineer-weeks designing a complex zero-uptime rollout strategy for your blog comment system.