3 ms·

"Broken by bad logic" The post contains the 'straw man' informal fallacy - ie. standing up an absurd scenario in order to knock it down. Mongo provides write

"Broken by bad logic" The post contains the 'straw man' informal fallacy - ie. standing up an absurd scenario in order to knock it down. Mongo provides write concerns for several use cases. Those concerns are: NONE NORMAL SAFE FSYNC_SAFE REPLICAS_SAFE The author focuses on the write concern NONE - a write concern that is provided for the 'fire and forget' use case. To choose NONE and expect guarantees and fault tolerance is simply user error.

emin_gun_sirer 14y ago
Something tells me that you did not read the article.
- enigma1510 14y ago
  Something tells me you did not read the manual. The post focuses on the least safe mode (NONE), and barely touches on REPLICA_SAFE at the end of the article. Leaving the reader to wait for "a future blog post". Choose the tool and configuration for the job. For a Mongo user that needs fault tolerance and consistency guarantees, I would recommend (based on documentation) choosing a configuration that attempts to provide those. The safest server configuration would be a multi-node replica set (3 or 5) that spans multiple data centers (preferably 3 or more). The safest client configuration would be a write concern REPLICA_SET (majority). If you have examples of Mongo not providing fault tolerance in this setup, the world would be a better place if you shared.
  - emin_gun_sirer 14y ago
    I not only read but quoted the manual, in parts of the article that you evidently skipped. I also described why SAFE and FSYNC_SAFE, aren't. I also described why getLastError doesn't work when pipelined or multithreaded. It's hard writing for the "tl;dr"-generation (as this exchange demonstrates -- there was a time when it used to be embarrassing to have someone say the same thing twice to you in a discussion). I'll have a separate blog entry on why REPLICA_SAFE is broken, and how the setup you outlined can lose data.
  - enigma1510 14y ago
    gun, you sound like a logical and un-biased man. I humbly await an answer to the question asked.

emin_gun_sirer 14y ago

Something tells me that you did not read the article.

enigma1510 14y ago
Something tells me you did not read the manual. The post focuses on the least safe mode (NONE), and barely touches on REPLICA_SAFE at the end of the article. Leaving the reader to wait for "a future blog post". Choose the tool and configuration for the job. For a Mongo user that needs fault tolerance and consistency guarantees, I would recommend (based on documentation) choosing a configuration that attempts to provide those. The safest server configuration would be a multi-node replica set (3 or 5) that spans multiple data centers (preferably 3 or more). The safest client configuration would be a write concern REPLICA_SET (majority). If you have examples of Mongo not providing fault tolerance in this setup, the world would be a better place if you shared.
- emin_gun_sirer 14y ago
  I not only read but quoted the manual, in parts of the article that you evidently skipped. I also described why SAFE and FSYNC_SAFE, aren't. I also described why getLastError doesn't work when pipelined or multithreaded. It's hard writing for the "tl;dr"-generation (as this exchange demonstrates -- there was a time when it used to be embarrassing to have someone say the same thing twice to you in a discussion). I'll have a separate blog entry on why REPLICA_SAFE is broken, and how the setup you outlined can lose data.
- enigma1510 14y ago
  gun, you sound like a logical and un-biased man. I humbly await an answer to the question asked.