I actually didn't have the problem with data not being synced to disk immediately, and I wasn't using getLastError to sync on every operation (AFAIK it doesn't by default, unless you use fsync option).
My more mundane problem was that I didn't know whether database said the (insertion) operation was ok (or, for example, I tried to reuse an unique key value). Without using getLastError (or, indeed, safe=True in Python), I have no idea whether any possible errors (eg. a bug in my code) have occurred.
For data for which you can ignore occasional error (e.g. some logging, or click tracking, or similar) I agree getLastError may not be needed. I believe that it's not a very good default for most users with use-cases similar to mine - you have a VPS, you build a simple app on it, and use MongoDB in it.
Re:MongoDB gotchas for the unaware user
by dmytton on Thursday December 23, 2010 @08:31AM
(#2034327)
Perhaps your use case is better suited to a traditional RDMS then, like MySQL or Postresql. Mongo is specifically marketed as a high performance database, which is why this is the default.
Re:MongoDB gotchas for the unaware user
by robotadam on Thursday December 23, 2010 @01:07PM
(#2035249)
getLastError (or safe=true) does not force the write to the disk. Checking getLastError determines whether the server accepted the write, or whether there were failures (uniqueness checks, for instance, or whether any rows were updated).
However, one of the great things about MongoDB is that, in some cases, you can easily afford to lose 1 minute worth of inserts in exchange for huge performance gains. Large chunks of data that is used for analytics is a good example since lost data won't [likely] impact final aggregates/percentages.
Some of our inserts, like user registration we run with safe=>true. Others, like audit logs (which, for us aren't as important as they might be for others) we don't.