4 ms·
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 / perfo
by Thaxll 8y ago
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.
- aphyr 8y agoIt 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.
- nvarsj 8y ago> 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).
- aphyr 8y agoAh, 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...
- ideal0227 8y agoThat is true. etcd v3 provides l-read by default. You have to opt-out that to improve latency.
- ideal0227 8y agoNo. You are wrong. etcdv3 enables l-read by default.
- jimktrains2 8y agoCorrect 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.
- jlokier 8y agoAbruptly 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).
- wolf550e 8y agoThe MySQL default has always been thee safe, not the fast, option. https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.ht...