Hacker News Reader

Comment by Thaxll | Hacker News Reader

It's the same for every DB, like you can say MySQL to ack a write but there was no fsync(). All those settings are usually tunable for various scenarios / performance you want.

View on HN

It is, in fact, not the same for every DB. Databases vary significantly in their default and maximum guarantees for successfully acknowledged writes; Mongo chooses fairly weak ones. By contrast, consider systems like VoltDB, which aims for strict serializability by default, or etcd, which offers linearizability/sequential reads by default.

> etcd, which offers linearizability/sequential reads by default

Not quite true - you have to opt-in to quorum reads in etcd. Otherwise it just returns the first read (which used to be the default in k8s and caused a lot of grief).

Ah, yes, sorry! I forgot exactly how that all shook out. I thiiink that prevents dirty reads, and with client monotonicity you can recover sequential consistency? Not sure how many clients actually do that; maybe they just do regular reads at RC...

That is true. etcd v3 provides l-read by default. You have to opt-out that to improve latency.

No. You are wrong. etcdv3 enables l-read by default.

The MySQL default has always been thee safe, not the fast, option.

https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.ht...

Correct me if I'm wrong, but an ack-without-fsync will not "unapply" a write while keeping things happening after it intact? It also won't "unapply" those writes without something catastrophic happening, e.g. dead disk or power outage. This isn't a general failure mode in a distributed system. MySQL with synchronous replication won't ack until all/majority of nodes ack the write.

Also, just because you fsync doesn't mean your data will hit the disk. It's a fairly large problem that has nothing to do with the consistency model of the database replication.

Abruptly terminating a VM is quite common in cloud services, can "unapply" a write, because it's equivalent to a power outage. The data lives in the VM guest's cache until the fsync sends it to the host.

With VM termination in the cloud being not exactly uncommon, I would say that's a general enough failure mode in a distributed system that it's an unacceptable risk to run MongoDB in its default configuration (or any database in the equivalent configuration).

Reply on news.ycombinator.com