Replication Set Priority

[Daniel Friesen]

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?

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

[Eliot Horowitz]

Admitting I didn't completely finish your mail, but I think you are correct, but we are going to change some things.

See:

http://jira.mongodb.org/browse/SERVER-1513

Basically w=2 will block until 2 servers with max priority have the write.

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

[Daniel Friesen]

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?

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

> <mailto:mongod...@googlegroups.com>.

> To unsubscribe from this group, send email to
> mongodb-user...@googlegroups.com

> <mailto:mongodb-user%2Bunsu...@googlegroups.com>.