Re:Postmortem of database outage of January 31
by qaq on Saturday February 11, 2017 @12:29PM
(#13623585)
how is buying a quality hardware component for a few K throwing "money at the problem" vs paying thousands a month for a very subpar product?
Re:Postmortem of database outage of January 31
by illumin8 on Sunday February 12, 2017 @09:35AM
(#13628485)
You can't just buy a single enterprise-grade NVMe SSD and call it a day. Are you planning on buying enough to populate at least 2-3 servers with multiple devices, then setting up some type of synchronous replication across them? What type of software layer are you going to use to provide high availability for your data? DRBD? How are you going to manage all of the different failure modes (failed SSD, network partition, split brain, etc.)? How are you going to test it?
I'm afraid you are seriously underestimating the operational capabilities required to successfully operate a highly-available, distributed, SSD storage layer.
Re:Postmortem of database outage of January 31
by qaq on Sunday February 12, 2017 @10:12PM
(#13632864)
Nope but if I pay a few K for a service I expect it to scale to perfomance at least comparable to a very low end device. Why would I use DRBD in a Postgres cluster? I am not underestimating anything I am simply pointing out that RDS is overpriced and crappy service. A proper setup & operation of a postgres cluster is manageable task. What you totally can not manage on AWS is the risks of having single tenant that is using 30% of resources or having lengthy multi AZ outages due to bugs in extremely complex control layer etc.
If you truly need more than 30K IOPs, I would recommend leveraging read-replicas, a Redis cache, and other solutions before just "throwing money at the problem" and purchasing a million IOPs.