3 ms·

"Aurora will try to retain enough log information to support that window of time." It's good to know that Aurora will try. It's not like it needs to be reliab

• jeffbarr 8y ago
  As I noted in the blog post, the storage resides within the cluster. It is storing small values (log sequence numbers) so the space is used with great efficiency, but there is a finite limit. While I don't know the specifics, I would expect that the mapping (time to size) was chosen based on real-world historical data. Cause that's how we roll!
• ben509 8y ago
  Database activity is volatile, so they have to allocate disk space, and that takes time. So if you have light access, and then start uploading many large BLOBs, it may take time for them to allocate space, and during that time the backups might not go all the way back to X hours. And, really, all of this is just servers in a datacenter, so you can have however many 9's of reliability, and still be That Guy that wins the fail lottery.
• chimeracoder 8y ago
  > It's good to know that Aurora will try. It's not like it needs to be reliable or anything. "Reliable" isn't a binary concept. There's no service that is 100% reliable. Having a solution that works 99.99% of the time (which is "only" four nines) is probably good enough that people are willing to use it as a last-resort. (From what it seems, it's included for free, so it's not like this costs you anything anyway - at worst, you end up where you would be if they hadn't released this).
  • ddorian43 8y ago
    It's not free, look at "estimated 10$/month".
  • barkingcat 8y ago
    Not free - there's even a pricing directly on the screenshot!
  • amelius 8y ago
    It has to be extremely reliable, simply because on large databases, it may take a considerable amount of time before you find out that something is wrong; and when you find out, it may be too late to fix things, even when you have backups.
• adrianmonk 8y ago
  If space fills up (or log storage becomes unavailable), which of the following do you want? 1. Writes to fail and your production service goes down because you couldn't guarantee Backtrack. 2. Your service stays up and you lose some amount of emergency undo ability.
  • ryanianian 8y ago
    3. Some actual guarantee that you can use to feel safe in the service, even if that guarantee is much smaller and less miraculous than the PR would suggest.
    • cavisne 8y ago
      The marketing message could be clearer here but if you read the aurora paper https://www.allthingsdistributed.com/files/p1041-verbitski.pdf https://www.allthingsdistributed.com/files/p1041-verbitski.p... And the docs There are actually two backup/restore methods. 1) Point In Time - streamed to S3. Guaranteed restore to a new cluster with less than 5 minutes data loss 2) Aurora Backtrack - On cluster buffer, up to 24 hours retention (no guarantee). "Instant" restore to the same cluster So you should feel safe using the service (up to the 5 minute worst case scenario). Obviously no one would ever want to use either backup method. However previously disaster recovery would involve spinning up a new cluster, deploying application changes with the new endpoint (or in a best case repointing a dns entry), waiting for the cache to warm up again. Now it becomes a 1 click fix through the UI with no application changes.
• fizx 8y ago
  As a person who has run multi-tenant storage for ten years, I'd like to say that users can be pathological use cases for fun.