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()
Yes, this is effectively what rs.stepDown()
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.
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.
You received this message because you are subscribed to the Google Groups "mongodb-user"