3 ms·

You've always been able to control this with write concern on a per-write basis. If you can handle an instance where and acknowledged write may not get replica

by nemo44x 12y ago

You've always been able to control this with write concern on a per-write basis. If you can handle an instance where and acknowledged write may not get replicated and possibly lost (logging use case - fast writes) then use that level of write concern. If you require extreme durability (slower writes but more durable) then use that level. In many applications you have both requirements and MongoDB lets you choose at write time the level of durability you want.

jedberg 12y ago
Does version 3 fix the issue where the database lies to you and says the write was complete once it hits the network socket and doesn't wait for the ack? http://hackingdistributed.com/2013/01/29/mongo-ft/ http://hackingdistributed.com/2013/01/29/mongo-ft/
- 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 ago
    Ok, 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 ago
      I'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.

by nemo44x 12y ago

jedberg 12y ago

Does version 3 fix the issue where the database lies to you and says the write was complete once it hits the network socket and doesn't wait for the ack? http://hackingdistributed.com/2013/01/29/mongo-ft/ http://hackingdistributed.com/2013/01/29/mongo-ft/

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 ago
  Ok, 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 ago
    I'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.