Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Replication Set Priority
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  3 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Daniel Friesen  
View profile  
 More options Sep 7 2010, 11:41 am
From: Daniel Friesen <nadir.seen.f...@gmail.com>
Date: Tue, 07 Sep 2010 08:41:54 -0700
Local: Tues, Sep 7 2010 11:41 am
Subject: Replication Set Priority
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]


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Eliot Horowitz  
View profile  
 More options Sep 7 2010, 11:46 am
From: Eliot Horowitz <eliothorow...@gmail.com>
Date: Tue, 7 Sep 2010 11:46:08 -0400
Local: Tues, Sep 7 2010 11:46 am
Subject: Re: [mongodb-user] Replication Set Priority

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.

On Tue, Sep 7, 2010 at 11:41 AM, Daniel Friesen
<nadir.seen.f...@gmail.com>wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Daniel Friesen  
View profile  
 More options Sep 7 2010, 1:38 pm
From: Daniel Friesen <nadir.seen.f...@gmail.com>
Date: Tue, 07 Sep 2010 10:38:37 -0700
Local: Tues, Sep 7 2010 1:38 pm
Subject: Re: [mongodb-user] Replication Set Priority
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]


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »