Re: Master-Slave Equivalent using Replica Sets

From: Mike Fisher <fisherm@xxxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Wed, 4 May 2016 11:01:08 -0700 (PDT)
Why ads?
Stephen,

     Thanks for the information.  Especially the reference to force 
reconfiguration 
<https://www.google.com/url?q=https%3A%2F%2Fdocs.mongodb.org%2Fmanual%2Ftutorial%2Freconfigure-replica-set-with-unavailable-members%2F%23reconfigure-by-forcing-the-reconfiguration&sa=D&sntz=1&usg=AFQjCNH2WRYe_MWSvJNDzA6LeAyg9Z_4bw>.  
That reference will come in handy.  However, I really don't want the 
automatic fail over functionality of replica sets.  For my application, I 
will have a single database in a data center that will be my primary 
database.  I wish to replicate that data base to other data centers.  
However, I want to be able to manually choose which data center will be 
failed over to in case of an outage or a planned application software 
upgrade.  So, I would really like my replica set to behave like a 
Master/Slave configuration.



On Wednesday, May 4, 2016 at 5:01:27 AM UTC-7, Stephen Steneker wrote:

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://www.google.com/url?q=https%3A%2F%2Fdocs.mongodb.org%2Fmanual%2Ftutorial%2Freconfigure-replica-set-with-unavailable-members%2F%23reconfigure-by-forcing-the-reconfiguration&sa=D&sntz=1&usg=AFQjCNH2WRYe_MWSvJNDzA6LeAyg9Z_4bw
   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/00162f91-abcf-4e05-946c-d25f2c3e4aa1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?