Please correct me if I'm wrong, but if I read the docs correctly, when choosing what server to make primary priority is considered over oplog?
In other words, in a case where we have a (1.0), b (0.9), and c (0.9), is there any possibility of a circumstance In other words, in this example circumstance:
You have 3 servers in a replset, A has a priority of 1, B and C have priorities of .9; Starting out we have: a: primary oplog (a1, a2) b: secondary oplog (a1, a2) c: secondary oplog (a1, a2) ...a goes down and b and c randomly chose c as primary... a: down oplog (a1, a2) b: secondary oplog (a1, a2) c: primary oplog (a1, a2, c3) ... a: down oplog (a1, a2) b: secondary oplog (a1, a2) c: primary oplog (a1, a2, c3) ...a comes back online and resyncs... a: secondary oplog (a1, a2, c3) b: secondary oplog (a1, a2, c3) c: primary oplog (a1, a2, c3) ... a: secondary oplog (a1, a2, c3) b: secondary oplog (a1, a2, c3) c: primary oplog (a1, a2, c3, c4) ... a: secondary oplog (a1, a2, c3) b: secondary oplog (a1, a2, c3, c4) c: primary oplog (a1, a2, c3, c4) ...before a syncs operation c4 c goes down a: secondary oplog (a1, a2, c3) b: secondary oplog (a1, a2, c3, c4) c: down oplog (a1, a2, c3, c4) ...now, b has the freshest oplog, however a has higher priority, from what I think I understand, in this case a's priority will kick in and even though b is fresher a will become primary?... a: primary oplog (a1, a2, c3) b: secondary oplog (a1, a2, c3, c4) c: down oplog (a1, a2, c3, c4) ... a: primary oplog (a1, a2, c3) b: secondary oplog (a1, a2, c3) // c4 is discarded c: down oplog (a1, a2, c3, c4) ...
If that's the case then even if you ensure getLastError({ w: 2 }); then you can still lose that data even though a majority has the data if that majority happens to be b and c and a becomes primary when one goes down because of it's priority.
A good recommendation I remember was to try and keep the primaries of shards on separate servers. ie: Given 3 servers with 3 sharded replica sets of 3 members it's good to try and ensure that the primary for each set is on a different machine to try and spread out write load. If what I was thinking of above is true then setting one member of each set with higher priority so that mongodb prefers primaries on different servers isn't a good way to do that since it could end up with small bits of data being lost. Would giving one member a higher number of votes work better?
> Please correct me if I'm wrong, but if I read the docs correctly, when > choosing what server to make primary priority is considered over oplog?
> In other words, in a case where we have a (1.0), b (0.9), and c (0.9), is > there any possibility of a circumstance > In other words, in this example circumstance:
> You have 3 servers in a replset, A has a priority of 1, B and C have > priorities of .9; > Starting out we have: > a: primary oplog (a1, a2) > b: secondary oplog (a1, a2) > c: secondary oplog (a1, a2) > ...a goes down and b and c randomly chose c as primary... > a: down oplog (a1, a2) > b: secondary oplog (a1, a2) > c: primary oplog (a1, a2, c3) > ... > a: down oplog (a1, a2) > b: secondary oplog (a1, a2) > c: primary oplog (a1, a2, c3) > ...a comes back online and resyncs... > a: secondary oplog (a1, a2, c3) > b: secondary oplog (a1, a2, c3) > c: primary oplog (a1, a2, c3) > ... > a: secondary oplog (a1, a2, c3) > b: secondary oplog (a1, a2, c3) > c: primary oplog (a1, a2, c3, c4) > ... > a: secondary oplog (a1, a2, c3) > b: secondary oplog (a1, a2, c3, c4) > c: primary oplog (a1, a2, c3, c4) > ...before a syncs operation c4 c goes down > a: secondary oplog (a1, a2, c3) > b: secondary oplog (a1, a2, c3, c4) > c: down oplog (a1, a2, c3, c4) > ...now, b has the freshest oplog, however a has higher priority, from what > I think I understand, in this case a's priority will kick in and even though > b is fresher a will become primary?... > a: primary oplog (a1, a2, c3) > b: secondary oplog (a1, a2, c3, c4) > c: down oplog (a1, a2, c3, c4) > ... > a: primary oplog (a1, a2, c3) > b: secondary oplog (a1, a2, c3) // c4 is discarded > c: down oplog (a1, a2, c3, c4) > ...
> If that's the case then even if you ensure getLastError({ w: 2 }); then you > can still lose that data even though a majority has the data if that > majority happens to be b and c and a becomes primary when one goes down > because of it's priority.
> A good recommendation I remember was to try and keep the primaries of > shards on separate servers. ie: Given 3 servers with 3 sharded replica sets > of 3 members it's good to try and ensure that the primary for each set is on > a different machine to try and spread out write load. > If what I was thinking of above is true then setting one member of each set > with higher priority so that mongodb prefers primaries on different servers > isn't a good way to do that since it could end up with small bits of data > being lost. Would giving one member a higher number of votes work better?
> -- > 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@googlegroups.com. > To unsubscribe from this group, send email to > mongodb-user+unsubscribe@googlegroups.com<mongodb-user%2Bunsubscribe@google groups.com> > . > For more options, visit this group at > http://groups.google.com/group/mongodb-user?hl=en.
Ok, fixing that would solve one problem I had thought of -- I was considering the idea of a secondary-only server for backups but realized that doing so could make w: 2 no longer reliable, so I switched to an idea involving picking a random secondary to use instead -- however it does make for another reason using a high priority on a single server to prefer primaries on different machines isn't good. Is giving a single shard member extra votes a good way to give preference to it becoming primary to affect distribution of primaries among machines?
> Basically w=2 will block until 2 servers with max priority have the write.
> On Tue, Sep 7, 2010 at 11:41 AM, Daniel Friesen > <nadir.seen.f...@gmail.com <mailto:nadir.seen.f...@gmail.com>> wrote:
> Please correct me if I'm wrong, but if I read the docs correctly, > when choosing what server to make primary priority is considered > over oplog?
> In other words, in a case where we have a (1.0), b (0.9), and c > (0.9), is there any possibility of a circumstance > In other words, in this example circumstance:
> You have 3 servers in a replset, A has a priority of 1, B and C > have priorities of .9; > Starting out we have: > a: primary oplog (a1, a2) > b: secondary oplog (a1, a2) > c: secondary oplog (a1, a2) > ...a goes down and b and c randomly chose c as primary... > a: down oplog (a1, a2) > b: secondary oplog (a1, a2) > c: primary oplog (a1, a2, c3) > ... > a: down oplog (a1, a2) > b: secondary oplog (a1, a2) > c: primary oplog (a1, a2, c3) > ...a comes back online and resyncs... > a: secondary oplog (a1, a2, c3) > b: secondary oplog (a1, a2, c3) > c: primary oplog (a1, a2, c3) > ... > a: secondary oplog (a1, a2, c3) > b: secondary oplog (a1, a2, c3) > c: primary oplog (a1, a2, c3, c4) > ... > a: secondary oplog (a1, a2, c3) > b: secondary oplog (a1, a2, c3, c4) > c: primary oplog (a1, a2, c3, c4) > ...before a syncs operation c4 c goes down > a: secondary oplog (a1, a2, c3) > b: secondary oplog (a1, a2, c3, c4) > c: down oplog (a1, a2, c3, c4) > ...now, b has the freshest oplog, however a has higher priority, > from what I think I understand, in this case a's priority will > kick in and even though b is fresher a will become primary?... > a: primary oplog (a1, a2, c3) > b: secondary oplog (a1, a2, c3, c4) > c: down oplog (a1, a2, c3, c4) > ... > a: primary oplog (a1, a2, c3) > b: secondary oplog (a1, a2, c3) // c4 is discarded > c: down oplog (a1, a2, c3, c4) > ...
> If that's the case then even if you ensure getLastError({ w: 2 }); > then you can still lose that data even though a majority has the > data if that majority happens to be b and c and a becomes primary > when one goes down because of it's priority.
> A good recommendation I remember was to try and keep the primaries > of shards on separate servers. ie: Given 3 servers with 3 sharded > replica sets of 3 members it's good to try and ensure that the > primary for each set is on a different machine to try and spread > out write load. > If what I was thinking of above is true then setting one member of > each set with higher priority so that mongodb prefers primaries on > different servers isn't a good way to do that since it could end > up with small bits of data being lost. Would giving one member a > higher number of votes work better?
> -- > 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@googlegroups.com > <mailto:mongodb-user@googlegroups.com>. > To unsubscribe from this group, send email to > mongodb-user+unsubscribe@googlegroups.com > <mailto:mongodb-user%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/mongodb-user?hl=en.
> -- > 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@googlegroups.com. > To unsubscribe from this group, send email to > mongodb-user+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mongodb-user?hl=en.