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).
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
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
The usual goal of a replica set deployment
is to enable automatic failover. Replica set primaries are maintained based
on a quorum vote of configured members, so require a minimum of three
for automatic failover. If you only want to have two data-bearing members,
there is the option of adding a third voting-only arbiter
to enable a majority vote in the event of failure.
For more information please see: Three Member Replica Sets
A properly configured replica set deployment can automatically handle
failover up to the level of 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:
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
to create a new replica set with the surviving member.