"If you are not running a database at home, you have the database in a replication setup."
That's one of the perceptions I'm saying isn't always true. Especially in big, non-tech companies that have a mish-mash of crazy legacy stuff. Traditional H/A disks and backups still dominate some spaces.
Backups that are easily restored trump replication for so many cases and much more cheaply. High availability is overrated when you have spare preconfigured commodity hardware you can spin up in minutes, which is often perfectly acceptable human time scale.
You really don't need the other insurance running all the time - that only makes it more fragile.
Only really huge services would care about downtime of this degree, or horizontal scaling.
> Backups that are easily restored trump replication for so many cases and much more cheaply
At 400 MB/s, you restore a terabyte in 45 minutes, and then you need to replay the changes that happened since the backup (in MySQL: replay the binlog), which will take aproximately another 15 minutes.
"One hour of MTTR or provisioning time per Terabyte of data at 400 MB/s sustained linear I/O speed" is a useful rule of thumb.
Having a replica that you can promote reduces that to seconds. Having a time delayed replica where you just roll forward the binlog reduces that to minutes.
You can work with modern databases without using replication, but that in most cases just shows you suck at operations.
That's one of the perceptions I'm saying isn't always true. Especially in big, non-tech companies that have a mish-mash of crazy legacy stuff. Traditional H/A disks and backups still dominate some spaces.