3 ms·
> 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
by 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 agoPerhaps 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.