|
|
MongoDB allows you to tune the level of consistency you achieve by
controlling (a) whether you read from the primary only, or from secondaries, and (b) when you write, how many nodes you wish to acknowledge the write before control returns to the writing process (this is useful for read-your-own-writes, for instance). MongoDB also uses an in-order replication protocol such that a read from any given node, once it succeeds (i.e. some particular write can be read from some particular secondary), it will never not succeed when reading from that node. As you point out, there are some situations around failures and fail overs in which the writes can seem to disappear. They will eventually show up on all secondaries, but this can take some time depending on the read and write load, network conditions, etc. None of the 10gen drivers support detection of this sort of "violation" of MRC. If it is critical to your application to always have monotonic read consistency, you should read from the primary only, as this offers the strongest consistency guarantees. - Dan On Apr 25, 12:15 pm, dhsieh <dhsi...@xxxxxxxxx> wrote: > Inhttp://blog.mongodb.org/post/523516007/on-distributed-consistency-par..., > Dwight alluded that MongoDB's default consistence model supports > Strong Consistency, a super set of MRC. I would like to reconfirm > through the following scenario that MongoDB does indeed support MRC: > > (1) There are 2 DC with DC1(1M1S), DC2(1S). There are 2 Apps with App2 > continues to run in the same session > (2) App1 writes w1 to M in DC1 > (3) App2 in DC1 sets slaveOk() true, reads w1 from S in DC1 assuming > w1 has been replicated from M in DC1 > (4) Assuming S in DC2 receives w1 replicated from M in DC1 > (4) App1 writes w2 to M in DC1 > (5) App2 reads w2 from S in DC1 assuming w2 has been replicated from M > in DC1 > (6) Assuming S in DC1 failed & App2 reads w2 again to find out if > there is a new w3. This time, App2 receives w1 from DC2 S since w2 > hasn't been replicated from M in DC1 > > My question is that since App2 continues to run in the same session, > will Mongo language driver detects violation of MRC and returns an > error? -- You received this message because you are subscribed to the Google Groups "mongodb-user" group. To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxxx To unsubscribe from this group, send email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.
Thread at a glance:
Previous Message by Date:[mongodb-user] Re: Why does rs.reconfig always take down primary briefly?Which version of MongoDB are you running? These was an issue in v1.8 but should not be an issue post 2.0. On Wednesday, April 25, 2012 11:17:05 AM UTC-4, idris wrote: > > For example, I just had a slaveDelay member and I removed the slaveDelay, > then saved the config using rs.reconfig(), and the primary went down > briefly, and apparently dropped all connections to clients. Why does it > need to do this? Shouldn't there be an option for "don't go down upon > reconfig" or something? > > -Idris > -- You received this message because you are subscribed to the Google Groups "mongodb-user" group. To view this discussion on the web visit https://groups.google.com/d/msg/mongodb-user/-/_KoShIxPJaIJ. To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxxx To unsubscribe from this group, send email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en. Next Message by Date:Re: [mongodb-user] MongoDB an C#I have downloaded your zip file. I had to pull down the nuget package for mongodb as you didn't include those binaries, which is version 1.4.1. Other than that, I ran your program and got a message box that said "Double Key". I believe this is what you were expecting, so I don't know what say at this point. That being said, given what your program appears to be doing, relying on the database to prove uniqueness is not the best way to handle this problem. This is a business convern, not a data issue and therefore should be checked as business logic, not at the database. I suggest that you check this type of constraint with a query first and let the database handle exceptional circumstances. This will also set you up for sharding in the future if it ever gets big enough to need that. -- You received this message because you are subscribed to the Google Groups "mongodb-user" group. To view this discussion on the web visit https://groups.google.com/d/msg/mongodb-user/-/EZLMFVRS49gJ. To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxxx To unsubscribe from this group, send email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en. Previous Message by Thread:[mongodb-user] MongoDB support for Monotonic Read Consistency (MRC)In http://blog.mongodb.org/post/523516007/on-distributed-consistency-part-6-consistency-chart, Dwight alluded that MongoDB's default consistence model supports Strong Consistency, a super set of MRC. I would like to reconfirm through the following scenario that MongoDB does indeed support MRC: (1) There are 2 DC with DC1(1M1S), DC2(1S). There are 2 Apps with App2 continues to run in the same session (2) App1 writes w1 to M in DC1 (3) App2 in DC1 sets slaveOk() true, reads w1 from S in DC1 assuming w1 has been replicated from M in DC1 (4) Assuming S in DC2 receives w1 replicated from M in DC1 (4) App1 writes w2 to M in DC1 (5) App2 reads w2 from S in DC1 assuming w2 has been replicated from M in DC1 (6) Assuming S in DC1 failed & App2 reads w2 again to find out if there is a new w3. This time, App2 receives w1 from DC2 S since w2 hasn't been replicated from M in DC1 My question is that since App2 continues to run in the same session, will Mongo language driver detects violation of MRC and returns an error? -- You received this message because you are subscribed to the Google Groups "mongodb-user" group. To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxxx To unsubscribe from this group, send email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en. Next Message by Thread:[mongodb-user] Re: MongoDB support for Monotonic Read Consistency (MRC)Would you please clarify what you mean on the following setences: "MongoDB also uses an in-order replication protocol such that a read from any given node, once it succeeds (i.e. some particular write can be read from some particular secondary), it will never not succeed when reading from that node" -- You received this message because you are subscribed to the Google Groups "mongodb-user" group. To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxxx To unsubscribe from this group, send email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.
|
|