3 ms·

Unfortunately "it's CURRENT_YEAR" and "downtime means you're poorly designed" are very poor, circular arguments. The only thing you said back which I can trace

• 0xbadcafebee 5y ago
  Would you rather a change 1) depend on two people doing a series of precarious steps and recovery which could possibly lead to a large amount of downtime, or 2) depend on one person doing a series of predictable small steps through automation which won't lead to any downtime? I prefer #2. Also I don't want to stay late.
  • slver 5y ago
    Planned downtime means only one thing: you have an atomic update, that needs some downtime. It doesn't inform you that the steps are "precarious" vs. "predictable" or that you have have or don't have quick way of recovery, or how small or big the update is. You can just as easily screw up your application state without downtime. You gotta be careful thinking purely by association. It's natural and intuitive, but often causes you to group unrelated characteristics together. Maybe my update is as simple as adding a column to a table. If I have millions of rows, that won't be instant, it can take say half an hour. In InnoDB for example it'll do a full table copy to add a column. But it's not precarious or fragile, or dangerous. It's just what it says on the can. It'll either do the copy or it won't.