Replica set and MongoDB, does the option {w: 1} make the system AP in terms of CAP?

Looking at Mongodb replication guide it look like, by default all query goes to the primary server. It you want the 'A' you also need to read on secondaries server, this is requiere to be AP. And then you loose the C because the results may be different from one server to another.

The question also look like this one, the answer could be helpful.

I am going to put this as answer due to pieces of evidence (like Mr K posted: Where does mongodb stand in the CAP theorem? ) to support my original concern on the subject before I deleted my comments due to Asya.

MongoDBs CAP compliancy seems to be based around what write concern is placed with what read concern.

Let's take an example. With the default configuration of reading from a primary {w:1} will be:

• C since the write can be read immediately (maybe not because it doesn't go to all members, hmm this one is a thinker)
• A since it is available immediately
• but not P since on a single server it is not partition tolerant if there was immediately failover

MongoDB itself will be partition tolerant perfectly fine (as long as you don't have even number of servers on each side) irrespective of the write (even if that write is lost due to paritioning).

However reading from secondaries with this write concern will actually cause A since MongoDB will now be eventually consistent and you will return stale data back from members.

With your second example of 3 members with {w:3} it could be CAP entirely:

• C because it goes to all members
• A because it is available on all members
• P because the replica set should not have a even number of members on either side. The contradiction to this is in the event of an immediate failover and two servers sit on oposite sides in which case P is lost because MongoDB is unsure as to which side to read from/write to and requires your intervention but you can just add abitriers to the forumla. This part of CAP is described well in a link put on Wikipedia: http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed under the heading "Why "2 of 3" is missleading". The exception is that MongoDB chooses to not loose C or A and instead requires your intervention.

Edit: Actually in this case CAP is lost entirely since MongoDB will just halt.

Edit again: As Asya pointed out MongoDB does still accept reads it just won't take writes which means it stays C but loses A, which fits in well with the standard then.

With all read concerns.

So I go back to what I said originally about the read concern and write concern having an involvement here (I honestly think they both do) and this is my answer.