Galera builds on that, and it works very well. It has weak points, but if you build a working Galera cluster and test it (test the failovers, test [re]bootstrapping a node), you can then be confident that it'll continue to work as intended for a long time.

There are rough edges. Upgrades, recovery from corrupted hot backup, etc. But it's very easy to rebuild the cluster in flight, for example when changing some fundamental cluster property, or after a PEBKAC, (with a not too big read-only window), though it requires plus one node, a regular MySQL/MariaDB server that acts as a donor (where Galera can bootstrap from), but that's not too surprising if you want to at least serve read-only requests.

You also can't use Galera on RDS, which is a deal breaker for some: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_M...

Sounds like a reason not to use RDS more than a reason not to use Gallera.

Why would you use RDS? AWS is overpriced.

If you really want no-ops deployment, use something that requires minimal amount of ops, like ElasticSearch. Just give it an obscene amount of RAM and it'll work fine for ages.

RDS or not, if you want to run a big site, you'll need (dev)ops expertise. And a lot of it. Famously, Netflix - the big full-cloud business, - employs the most aggressive performance engineering and other "auxiliary" development groups. (Because AWS is fckn!1 expensive, and when you can run on a thousand less nodes, it'll cost you less. And yes, of course Netflix gets a big discount, but you won't, at least not initially.)

Neither Netflix nor any of the top "startups" are anywhere near aggressive performance. In fact they're usually full of slow fragile tech that only looks great to blog about.

HFT, adtech, scientific engineering and many other industries are magnitudes farther ahead.

> no-ops deployment

This is the worst joke in tech really. Developers/Managers all jumping on the "cloud" bandwagon because "hey we don't need ops" and then you end up with "Galera is such a POS, you can't use it with RDS".. <facepalm>

> If you really want no-ops deployment, use something that requires minimal amount of ops, like ElasticSearch. Just give it an obscene amount of RAM and it'll work fine for ages.

I can assure you this is not the case if your indexes are very large and their number is constantly growing, and/or clients are doing very complex queries that stress the system.

The same thing applies to anything really, if you try to "shard" (partition, or simply do multi tenancy) based on files, MySQL tables, MongoDB collections, and of course elasticsearch indexes.

And you have to plan ahead and start with a large number of shards, to be able to scale your ES cluster.

Yet it's much better than trying to get some kind of SQL based cluster going, because those require knowledge of a lot of subtle internal details.

It's multi-master from MySQL's settings perspective.

Restoring a backup takes minutes for multi-TB restores.

Just because MySQL calls it multi-master doesn't make it so. What you described is single master with a hot spare. Real multi master is when a client can write to both servers and they will be consistent by the magic fairy dust that is replication.

How exactly do you get that multi-TB backup onto the database server's disk so quickly? Even with a gigabit network interface, that's only 125MB/s, which is over two hours[0] to transfer 1TB. Even if you have a 10 gigabit network, that's ~13 minutes[0].

Also consider if the backups are compressed -- a 1TB compressed file also takes time to uncompress. If the data compresses well, you could even run into the disk being the bottleneck, not the network.

[0] Well, more than that; those numbers assume you're actually getting the link rate with no overhead, which of course isn't reality.

Minutes for multi TB restores? Only if both your main and your backup are on SSD, which is still not common for multi TB databases, I think.

1TiB=1,000GiB; if your drives do 300MB/sec, that's still one hour.