Re: Question about MongoDB-replication-guide

From: John Reno <jlreno@xxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Fri, 15 Apr 2016 07:21:06 -0700 (PDT)
Why ads?
This is by design. Consider a replica set with one member in each of 3 data 
centers, DC1, DC2, and DC3. Mongo1 is primary and mongo2 and 3 are 
secondary. Now a network partition occurs which isolates DC1 but mongo1 
stays up. The Mongos in DC2 and DC3 are unaffected, constitute a majority 
and vote Mongo2 as primary. If Mongo1 does not step down you will have a 
replica set with 2 primaries.... Very bad. Some writes may go to Mongo1 
from local users and other writes will go to Mongo2 from users on the other 
side of the partition. When the partition clears, it will be very difficult 
or impossible to reconcile the two primaries.
The solution is to add data centers and mongo processes until you feel 
comfortable that you will always have a majority up :). Or accept that if 
you lose two data centers you will have to manually break the replica set 
at the surviving data center to allow writes again.

On Thursday, April 14, 2016 at 9:32:21 PM UTC-4, Mike Fisher wrote:

I have read in the MongoDB-replication-guide from the MongoDB website (
http://docs.mongodb.org/master/MongoDB-replication-guide.pdf) the 
following statement on page 28, under section "2.3.1 Replica Set 
Elections": 

 

"If a majority of the replica set is inaccessible or unavailable to the 
current primary, the primary will step down and become a secondary. The 
replica set cannot accept writes after this occurs, but remaining members 
can continue to serve read queries if such queries are configured to run on 
secondaries."

 

Is this statement true?  Unless I misunderstand the above statement, this 
scenario seems very "BAD" to me.  To me this statement is telling me that 
if I have a Replica set with three members that spans three data centers; 
i.e. data center 1 contains the primary member, data center 2 contains a 
secondary member, and data center 3 contains a secondary member; and if 
data centers 2 and 3 go down, then data center 1 will have the primary 
member revert to being a secondary member.  This would be very bad for a 
production system running on data center 1.  In this scenario, the 
primary member would become a secondary member and no more write operations 
would be allowed by the production system running on data center 1.  Is 
this true?  Why would anyone want this behavior?  I can see a situation 
where one would want to take down data centers 2 and 3 for maintenance, or 
they might go down for some kind of failure, but that should not affect the 
production system running on data center 1.  Can anyone please explain 
this statement in more detail to me?


-- 
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.org/manual/support/
--- 
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/b2f20e90-1ad2-41c2-9602-b67f9caa9837%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?