2

I am new to MongoDB and trying to understand replica sets. Specifically, I am trying to understand how MongoDB would handle the following situation:

  1. A record is written to a table with a unique index on the primary Mongo member (Mongo 1).
  2. Mongo #1 crashes before the new record is propagated to the secondary Mongo member (Mongo 2).
  3. Mongo 2 and the arbiter elect Mongo 2 to be the primary.
  4. The application attempts to create a duplicate record in the table. Because Mongo 2 is not aware of the record written to Mongo 1, the unique constraint is not enforced.
  5. Mongo 1 becomes available again and replication resumes.

What happens next? Does Mongo 1 attempt to replicate the record to Mongo 2? Or Mongo 2 to Mongo 1? Or both simultaneously? How is the conflict resolved?

6
  • This is still basically asking for an answer to a course question
    – Neil Lunn
    Oct 1, 2014 at 4:55
  • 2
    Neil, this is a question about the behavior of a database engine. It should be documented as reference information. I don't understand why you're hung up on this being a question that was asked in an online course. I'll ask again -- can you please explain your concern?
    – peteallen
    Oct 1, 2014 at 4:58
  • My concern here is that this is not only covered in the documentation but it specifically is almost exactly how a question is phrased in the online course material that has been referenced. The relevant documentation is covered in Rollbacks During Replica Set Failover but explaining the particular case of what happens given these conditions is effectively "posting an answer" to a course question, where the point is to work out the result from the documentation and not just "find the answer" online.
    – Neil Lunn
    Oct 1, 2014 at 5:03
  • @NeilLunn: Wasn't this a Quiz question only? Oct 1, 2014 at 5:34
  • @MarkusWMahlberg I seem to remember a "test" question on M101. But why ask questions if all you need to do is "google" the result? So basically voicing the opinion that answers to "any form" of question asked should generally be provided by reading the documentation and working it out. Not by just asking someone to solve it for you or otherwise just google the result. That is why I don't think it is valid to answer.
    – Neil Lunn
    Oct 1, 2014 at 5:46

2 Answers 2

1

In this case, the following will happen:

  1. When a member rejoins the replica set, the point in time on which the oplog is identical on the cluster is figured out.
  2. If there are oplog entries beyond said given point in time, those entries are tried to be reverted and saved for human analysis. This is called a rollback in MongoLand.
  3. If the node was down for a longer time than the oplog window, it becomes stale as usual, and a manual resync is required. In this case all the entries of the oplog are rolled back when the node comes up again.
  4. The maximum size for a rollback is 300MB. While this sounds little, it is actually quite some, as those 300MB only need to hold the data in which a primary has to figure out that it is not longer part of a replica set (may be through network partitioning).

Please read more on this at Rollbacks During Replica Set Failover and Resync a Member of a Replica Set in the docs.

0

When Mongo 1 becomes available, it will be a secondary replica and should be sync to the primary (Mongo 2). If there is a conflict, the admin should decide to manually perform a rollback or not. See http://docs.mongodb.org/manual/core/replica-set-rollbacks/

It is recommended to use write concern when performing write operation to a MongoDB replica set

db.collection.insert(
   { item: "item1", qty : 100},
   { writeConcern: { w: majority, wtimeout: 5000} }
)

where majority is more than 50% the number of replicas, this insert is succesful only when it is confirmed by the majority of replicas and failed if the wtimeout occurs before the confirmation. The data consistency is then maintained as long as the majority of replicas are available. See http://docs.mongodb.org/manual/core/replica-set-write-concern/

1
  • 1
    a) with a write concern set to the number of the replica set members, any write will fail as soon as one node goes down. This completely eliminates failover capabilities for writes. b) The relatively rare and most of the times easy to handle rollback usually does not warrant that. A write concern of majority usually is enough, offering both consistency and availability. c) An DBA will NOT be notified about rollback data to review. This has to be checked manually after a failover occurs (of which you can actually be notified by MMS). Oct 1, 2014 at 5:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.