Re: Question about MongoDB-replication-guide

From: Darshan Shah <dee.cal@xxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Thu, 5 May 2016 07:23:05 -0700 (PDT)
Why ads?
John,

What do you think of using replicaset member priority to solve this?

For example. primary at DC1 has a priority of 5 and secondaries at DC2 & 
DC3 have a priority of 2.
So in the event of a network partition or DC2 / DC3 going down, primary at 
DC1 would continue to be primary.
But in the event of the primary going down, one of the secondary would step 
up, but as soon as the DC1 primary is available again and caught up, it 
automatically becomes the primary
I did a small test of this scenario and saw it work - but want more inputs 
and to confirm my assumptions

Thanks!


On Friday, 15 April 2016 16:30:09 UTC-4, John Reno wrote:

Yes, if a majority of the replset instances are in DC1 than a loss of DC2 
and DC3 will not affect your primary in DC1 as it will still be able to 
contact a majority. However if DC1 goes down you will still have to do a 
manual reconfiguration to move the primary to DC2 or DC3.

In short, there is no way to guarantee a majority of the instances will 
always be available if enough of your nodes go down; all you can do is add 
diversity (multiple servers, racks, power supplies, routers, ISPs, data 
centers,...) to reduce the possibility of losing contact with a majority of 
the replicas. But one node in 3 geographically diverse data centers gets 
you 95% of the way there.

I am currently building a sharded cluster made up of 5 member replica 
sets, two members at the main data center, two at our alternate location 
and an arbiter in a third location. Both members at the main site have 
priority 9 and the members at the alternate site have priority 1. This 
causes the main site members to be preferred primary; I do that because our 
analytic batch jobs run at the main site so I want the primary to be there 
if possible. If you have a good enough network (we don't) it shouldn't 
matter where the primary is, but you will find out it usually does.
With this setup, I can take down either of the members at the main site 
and be assured the primary will remain local. If both nodes or the main 
site go down, the replicas at the alternate site consult with the arbiter 
to see if one of them should become primary. If I lose a node during 
maintenance the replica set remains writeable. It's as much availability as 
I can afford.

You are correct to worry about a failure during maintenance. Our 
operations group tends to do all kinds of updates in short outage windows 
so a firewall reconfiguration at the same time as an OS patch/reboot at the 
same time as I'm upgrading a database is very possible.

Hope this helps


-- 
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/091d6417-4e04-4893-b199-216193e5a032%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?