3 ms·
Do you prepare your rollback snippets in advance? If not, how do you deal with urgent rollbacks? If yes, how do you make sure those snippets work in advance?
by DenisM 5y ago
Do you prepare your rollback snippets in advance? If not, how do you deal with urgent rollbacks? If yes, how do you make sure those snippets work in advance?
- bob1029 5y agoThe SQLite usage is very tightly integrated with the software. Any urgent rollback is effectively a roll-forward fix of whatever broken software is in production.
- DenisM 5y agoWhen I say urgent rollback I mean rollback within 30 seconds of realizing something went wrong. Do you have this capability?
- megous 5y agoShouldn't you do DB updates in production in a way that N backend always works at least with N+1 schema? So you just rollback the backend...
- redis_mlc 5y agoThis is the correct answer in almost all cases for managing production databases. However, developers who use postgres never got the memo, and are trying to do mass rollback transactions of schema changes "cause it worked on my dev notebook." Source: DBA who manages tables with billions of rows.
- developuh 5y agoCan you please explain this like I'm 5. I am still learning and I would like to understand how to do upgrades in a better way.
- Gadiguibou 5y agoI'm not the original commenter, nor am I experienced with upgrading in general, but what I understand from the comment is that you always make sure that your current schema is compatible with the previous backend. For example, this could mean that you don't delete any column that were still in use in the previous backend version. This would have the advantage of letting you rollback your backend alone if anything wrong happens.
- DenisM 5y agoYou could do it that way, but I don't have the need, so my way leads to faster dev cycle: https://news.ycombinator.com/item?id=29566574 https://news.ycombinator.com/item?id=29566574 Doing as you say requires two deployment for each change with a pause in between, and likely two separate merges (does it?). This reduces the deployment velocity. I might have to do as you describe when I start scaling out - there is no hope of updating many servers in sync so might as well embrace multi-version.