4 ms·

Interesting - but what if your database has constant activity? "Oops, my SQL bad" becomes "Oops, my rewind lost 410 transactions"?

gtowey 8y ago
This is exactly my concern. There is no production system I have ever worked on which this feature would ever be used. What if you had an e-commerce site? Other customers were placing orders, right? Credit cards being charged? You didn't catch your mistake instantly. So you have a window of maybe, 5 minutes or a hour in which other things happened. You can't simply forget those other transactions and throw away the data.
- Lightbody 8y ago
  Consider non-production use cases... run a test suite and then reset the data back to a pristine state after each run.
- joemag 8y ago
  There have been many well publicized events where a production database was lost, or in some way corrupted. I’ve lived through one such event myself. When that happens, you usually go to a backup, and typically run into two problems: 1) Point in time back ups can be hours old. 2) More importantly, “backups” are useless, it’s the “restores” that are valuable. And very few organizations have a well practiced muscle memory for restoring from a backup. A turn key restore solution, with a per second granularity can both significantly decrease the loss window, and recovery time. Hope nobody gets to use it, but when you have, it can be a difference between a big and a small outage.
joemag 8y ago
When faced with the alternative of loosing the entire database [1], loosing 410 transactions is usually preferable. Per second granularity gives you ability to restore as close to the fatal mistake (or poison pill transaction) as possible. After that, recovering transactions lost by the rewind can be really tricky (but not impossible). If the entire database got dropped, for example, it’s possible for the unwound writes to contain conflicting IDs. [1] https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/ https://about.gitlab.com/2017/02/10/postmortem-of-database-o...

gtowey 8y ago

This is exactly my concern. There is no production system I have ever worked on which this feature would ever be used. What if you had an e-commerce site? Other customers were placing orders, right? Credit cards being charged? You didn't catch your mistake instantly. So you have a window of maybe, 5 minutes or a hour in which other things happened. You can't simply forget those other transactions and throw away the data.

Lightbody 8y ago
Consider non-production use cases... run a test suite and then reset the data back to a pristine state after each run.
joemag 8y ago
There have been many well publicized events where a production database was lost, or in some way corrupted. I’ve lived through one such event myself. When that happens, you usually go to a backup, and typically run into two problems: 1) Point in time back ups can be hours old. 2) More importantly, “backups” are useless, it’s the “restores” that are valuable. And very few organizations have a well practiced muscle memory for restoring from a backup. A turn key restore solution, with a per second granularity can both significantly decrease the loss window, and recovery time. Hope nobody gets to use it, but when you have, it can be a difference between a big and a small outage.

joemag 8y ago

When faced with the alternative of loosing the entire database [1], loosing 410 transactions is usually preferable. Per second granularity gives you ability to restore as close to the fatal mistake (or poison pill transaction) as possible. After that, recovering transactions lost by the rewind can be really tricky (but not impossible). If the entire database got dropped, for example, it’s possible for the unwound writes to contain conflicting IDs. [1] https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/ https://about.gitlab.com/2017/02/10/postmortem-of-database-o...