Re: Master-Slave Equivalent using Replica Sets

From: Stephen Steneker <stennie@xxxxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Wed, 4 May 2016 05:01:26 -0700 (PDT)
Why ads?


On Wednesday, 4 May 2016 09:53:51 UTC+10, Mike Fisher wrote:

I have a question regarding the “Replication and MongoDB” manual release 
3.2.4. I am using MongoDB version 3.2. I have created a Replica Set with 
two members running on different machines. I have configured the replica 
set to behave like a Master/Slave replication (see page 44).

Hi Mike,

The Master/Slave configuration is a deprecated legacy deployment option. 
The instructions you are referencing are specific to both Master/Slave and 
the MMAP storage engine, so will not be helpful for a new MongoDB 3.2 
replica set deployment which will be using WiredTiger as the default 
storage engine.

For a new deployment you should definitely be using replica sets.

However, I am wanting to convert the slave member to be the new Master and 
the old Master to be the new slave. In section 2.6.4 of the “Replication 
and MongoDB” manual, there is a subsection entitled “Inverting Master and 
Slave”.

The usual goal of a replica set deployment 
<https://docs.mongodb.org/manual/core/replication-introduction/#replication-in-mongodb
is to enable automatic failover. Replica set primaries are maintained based 
on a quorum vote of configured members, so require a minimum of three 
members 
<https://docs.mongodb.org/manual/core/replica-set-architecture-three-members/
for automatic failover. If you only want to have two data-bearing members, 
there is the option of adding a third voting-only arbiter 
<https://docs.mongodb.org/manual/core/replica-set-architecture-three-members/#primary-with-a-secondary-and-an-arbiter
to enable a majority vote in the event of failure.

For more information please see: Three Member Replica Sets 
<https://docs.mongodb.org/manual/core/replica-set-architecture-three-members/>
.

A properly configured replica set deployment can automatically handle 
failover up to the level of fault tolerance 
<https://docs.mongodb.org/manual/core/replica-set-architectures/#consider-fault-tolerance
you have provisioned. Generally you should consider all members of the 
replica set as peers in terms of resource and configuration (particularly 
if you only have three members), so that any data-bearing member is 
eligible to become primary.

If you *really* want to have a two member replica set with manual failover 
(which is highly discouraged) the equivalent helpers you’d be looking for 
are:

   - 
   
   Use rs.stepDown(..) 
   <https://docs.mongodb.org/manual/reference/method/rs.stepDown/> to force 
   the current primary to become a secondary and trigger an election. In a two 
   member replica set, this will only work if both members are healthy (a two 
   member replica set does not provide any fault tolerance).
   - 
   
   Use member priorities to influence the outcome of elections 
   <https://docs.mongodb.org/manual/core/replica-set-elections/> if there 
   is a strong reason to favour a specific replica set member being the 
   primary (for example, with a geographically distributed replica set). 
   - 
   
   If either member is down, you can force reconfiguration 
   <https://docs.mongodb.org/manual/tutorial/reconfigure-replica-set-with-unavailable-members/#reconfigure-by-forcing-the-reconfiguration
   to create a new replica set with the surviving member.
   
Regards,
Stephen


-- 
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/4caf7300-ff9a-44f6-93ca-0a33f3accd4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?