Comment by sargun | Hacker News Reader

Comment by sargun | Hacker News Reader

Parent Full thread

Having run Oracle RAC, MySQL circular replication, Postgres replication since 9.X, Amazon RDS, and others in production, I can say that Oracle RAC was the worst experience.

We had to provide our own active / active storage backend, and fabric. If there were any hiccups, the entire system fell over. The horizontal scalability was nice, but if you caused I/O saturation on the backend, you'd end up knocking over the entire cluster due to shared components. Several times, the entire DB just "broke" (this was a couple scenarios, one where the DB was using 100% of CPU, one where the DB was frozen, and not allowing connections, and things like hung queries that couldn't be stopped), and it required restarting the whole cluster, for which there was minimal tooling.

Perhaps SQL server is better, but that comes with an entirely new ecosystem, and other problems.

My biggest thing is being able to crack open the DB, and look at the source code when it breaks. In this, the likes of Datastax Cassandra and Cockroachdb are great, but I wouldn't call them "proprietary" by any means.

To this day only Oracle RAC provides true active-active cluster. All the other things are not real clusters, just replications.

err, CockroachDB would like a word... Although, I'm not sure if its just data serving that's active-active, or query execution is distributed.

Also, Cassandra is active-active as well.

I'm sure there are others, but I'm less familiar with them (Yugabyte, Couchbase, etc..)

Active-active is when you don't have any replicas, you have just one data store and multiple 'engines' accessing it. So there is no replication, because there is nothing to replicate. So CockroachDB is definitively not active-active, despite their claims to the otherwise; what they call active-active is two-way synchronous replication, which is worse than asynchronous replication because of the latency and worse than Oracle RAC active-active because it's less fail-tolerant. In Oracle RAC your cluster is up and running even if just one engine is still alive, in CockroachDB approach when you lose majority of nodes the cluster goes down. Obviously Oracle RAC active-active has it's own downsides, too, but it's another topic. EDIT to expand: Think about a SQL transaction. In Oracle RAC it gets picked up by any of the nodes and is executed by this node. All the other nodes see updated data immediately. In CockroachDB the same transaction would need to be executed by each of the nodes separately plus the overhead of communication between the nodes.

> In Oracle RAC your cluster is up and running even if just one engine is still alive

So it's not consistent in the CAP Theorem sense. Comparing it with other databases that don't lose writes and don't have split brain issues makes no sense

It is always consistent because it is a single storage database with multiple access points. It's not distributed data so CAP theorem doesn't even apply to it.

Oracle RAC is a shared storage system, every database instances write to same datastore, so as long as a transaction is committed by one node, it'll be seen by other nodes.

Of course, the issue with all shared-storage systems is how much it costs to have a reliable and fast shared storage.

You have a misconception about CockroachDB and YugabyteDB architecture. It is not 2-way replication. It writes to a Raft group. The transaction can be picked up by any node because the transaction intents are also replicated. The main difference with RAC is that the current version of a row is read/write on the Raft Leader, replicated to followers (that can be elected new leader). In RAC, the block with current version of a row is moved back and forth between the instance. That's possible only with reliable, short distance, dedicated network. Distributed SQL can scale out to multiple availability zones. Not RAC

Reply on news.ycombinator.com