5 ms·
He was using v2.0 in that article. A version that is years old and pretty awful. The default then was that a write was fired from the client and that's it - fir
by nemo44x 12y ago
He was using v2.0 in that article. A version that is years old and pretty awful. The default then was that a write was fired from the client and that's it - fire and forget. A stupid default.
The default since is to get an ack from the server. You can control this on each write and make it more durable (make sure it is replicated to 1, majority or all replicas) or faster (just get to the server). The default is to be written to the primary server and put into the transaction log so if it doesn't get committed to disk (possibly 60 seconds by default) it can recover. The transaction log is flushed (fsync) every 100ms by default and is configurable. You can also specify that the write is only acknowledged after the transaction log is synced. Anyways the default is it is put into the transaction log and then acknowledged.
- jedberg 12y agoOk, fair enough. Then the answer is yes, they did fix it. :) I guess I'll give it another look then. But I'm still a little wary of a database built by people who ever thought that such behavior was acceptable for a database...
- nemo44x 12y agoI'd make sure you use the new storage engine, wiredtiger too if you give them another shot. The standard one works well on read heavy use cases but saturates I/O pretty quickly if you're doing a lot of updates that make documents grow if you don't take some precautions. I also agree, having a setting of "fire and forget", although useful in some (limited!) use cases, is not a sane default.