This is the correct behavior. A majority of the replica set must be up and communicating with each other, and then hold an election, in order to have a primary and accept any write operations. You cannot configure a replica set so that, when 1/3 members are up (from some point of view), the set can accept writes. Why? Suppose we have a 3 member replica set, with each member in a different data center, and that solitary replica set members are allowed to make themselves primary
DC1: rs0/serverA
DC2: rs0/serverB
DC3: rs0/serverC
Rebellious gnomes cut all of the wires between the datacenters; servers A, B, and C can no longer communicate with each other. Server A sees this situation as "I'm still alive, but B and C are dead. I must become primary!" Servers B and C say the same thing about themselves. Three clients X, Y, Z connect, one to A, one to B, one to C. They send the following operations that involve writes:
X: db.mission_control.drop()
Y: db.mission_control.update({ }, { "fire_all_missiles" : true }, { "multi" : true })
Z: db.mission_control.update({ }, { "world_peace_mode" : "engage" }, { "multi" : true })
Now the wires between the data centers are restored and A, B, and C can talk to each other again. What should we do with the mission_control
collection? Drop it, then try to fire the missiles, then try to engage world peace? Fire the missiles, then drop it, then try to engage world peace? Perhaps, most dastardly, we should engage world peace, then, once everyone's lowered their guard, fire the missiles, then destroy the evidence by dropping the collection. How should MongoDB know what to do in this situation?
Thus you can't have a primary (node that accepts writes) without a majority. You can still read from a secondary when there's no primary, though. You just need to set a secondary read preference.