Re: Master-Slave Equivalent using Replica Sets

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


On Thursday, 5 May 2016 04:01:41 UTC+10, Mike Fisher wrote:

So, it seems like there should be some mechanism to flush out the original 
Masters write operation buffer to completion, synch the changes to the 
original slave and then change roles. Is that what the rs.stepDown() 
function does?

Hi Mike,

Yes, this is effectively what rs.stepDown() 
<https://docs.mongodb.org/manual/reference/method/rs.stepDown/#behavior
does. By default rs.stepDown() waits 10 seconds for an electable secondary 
to catch up with any changes, but you can set a different period with 
secondaryCatchUpPeriodSecs as per Rhys example. If an electable secondary 
cannot catch up in this time period, the primary prior to the stepdown will 
be re-elected as the most current data source. If you reconfigure the 
replica set with a higher priority for your preferred primary, this will 
also have the effect of electing the member with highest priority as 
primary once it is in sync.

In the event of unexpected shutdown where changes haven’t fully replicated 
to a secondary that becomes primary, a rollback 
<https://docs.mongodb.org/manual/core/replica-set-rollbacks/> will occur 
when the former primary rejoins the replica set. The rollback process 
reverts writes to make the former primary consistent with the current state 
of the replica set; documents that are rolled back are written to BSON 
files in a rollback/ directory for review.

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. 

FYI, you can also use replica set priorities 
<https://docs.mongodb.org/manual/tutorial/adjust-replica-set-member-priority/
for this purpose: set a higher priority for your primary data centre and 
your preferred primary member.

Manual failover and forced reconfiguration with two members will leave your 
deployment more exposed to downtime and rollbacks, but I assume that is 
acceptable for your use case.

I would also encourage you to use “primary” and “secondary” terminology for 
clarity that your deployment is a replica set. As noted earlier, 
Master/Slave is a different (and deprecated) deployment topology.

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/466c17c4-d276-4ceb-ac29-fb0d315348e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?