To clarify, we communicated this incident to the personalized status page [1] of all affected customers within 30 minutes of this single host going down, and resolved the incident on the status page once it was resolved ~47h later. Here's the timeline (UTC):
- 2023-07-17 16:19 - host goes down
- 2023-07-17 16:49 - issue posted to personalized status page
- 2023-07-19 15:00 - host is fixed
- 2023-07-19 15:17 - issue marked resolved on status page
That's how other [useful] providers notify their customers that one of their hosts went down unexpectedly. Linode will send me 6 emails when they need to reboot something. Even Oracle sends me notices about network blips. I believe I've gotten one from AWS, but I also know sometimes their gear gets stuck in a bad state and I didn't get a notification, which was super annoying because it took forever to figure out it was AWS's faulty state.
The bad news is that I'd be out of a job if I chose your service in this instance. 47 hours is two full days. For an entire cluster to be down for that long is just unacceptable. Rebuilding a cluster from the last-known-good backup should not take that long, unless there are PBs of data involved; dividing such large data stores into separate clusters/instances seems warranted. Solution archs should steer customers to multiple, smaller clusters (sharding) whenever possible. It is far better to have some customers impacted (or just some of your customer's customers) than have all impacted, in my not so humble opinion.
And, if the data size is smaller, you may want to trigger a full rebuild earlier in your DR workflows just as an insurance policy.
The good news is that only a single cluster was impacted. When the "big boys" go down, everything is impacted... but customers don't really care about that.
Not sure if this impacted customer had other instances that were working for them?
There was one physical server down. That's it. They even brought it back.
I've had AWS delete more instances, including all local NVMe store data, than I can count on my hands. Just in the last year.
Those instances didn't experience 47 hours downtime, they experienced infinite downtime, gone forever.
I guess by your standard I'd be fired for using AWS too.
But no, in reality, AWS deletes or migrates your instances all the time due to host hardware failure, and it's fine because if you know what you're doing, you have multiple instances across multiple AZs.
The same is true of fly. Sometimes underlying hardware fails (exactly like on AWS), and when that happens, you have to either have other copies of your app, or accept downtime.
I'll also add that the downtime is only 47 hours for you if you don't have the ability to spin up a new copy on a separate fly host or AZ in the meanwhile.
Combine that with them having tooling for setting up Postgres built on top of single node storage, and you have the downtime problems and unhappy customers as a given.
> If your instance root device is an instance store volume, the instance is terminated, and cannot be used again.
See also the aws "Dedicated Hosts" and "Mac Instances". Those also have similar termination behavior.
The majority of my instances lost are from the instance store thing.
I've never experienced AWS killing nodes forever; at least not DB instances.
> Rebuilding a cluster from the last-known-good backup should not take that long
It's not even clear if that's the right thing to do as a service provider.
Let's say you host a database on some database service, and the entire host is lost. I don't think you want the service provider to restore automatically from the last backup because it makes assumptions about what data loss you're tolerant to. If it just works from the last backup, suddenly you're potentially missing a day of transactions that you thought were there that magically disappears as opposed to knowing they disappeared from a hard break.