0

MongoDB has configurable durability: When doing an update operation, you can specify a "write concern" to tell the system that you want the update to only be considered complete when the data has (for example) been flushed to disk and replicated to X slaves.

Are there any kind of assurances about not the current update, but the writes that preceded it? If I want to update three documents, do I have to tag the expensive write concern on all of them, or is it sufficient to issue it with just the last operation?

Also, is this reasoning affected by using connection pools (i.e. the three updates being done over three different connections) and sharding (i.e. the three updates affecting more than one shard)?

Thilo
  • 257,207
  • 101
  • 511
  • 656

1 Answers1

1

If you use the same connection for multiple writes, getLastError with j, safe, fsync flag that returns successfully will indicate that the previous operations before the last operation are getting saved/replicated to other servers already.

However, if those previous operations fail for any reasons, you wouldn't know about it if you don't call getLastError for each operation. However, if your writes are sent from different connections, there is no guaranteed that all operations are saved to disk/replicated to other servers.

Nat
  • 3,587
  • 20
  • 22
  • Does that first paragraph also apply when sharding is in place? – Thilo Dec 15 '11 at 07:04
  • getLastError() on a mongos will succeed if all writes in the cluster succeed -- i.e., getLastError() will block until all shards have satisfied the write concern. The first error to occur will be returned, otherwise. – brandon10gen Dec 19 '11 at 16:24