camille really has the right solution. you have to let it become the leader
and then kill it. here is why:
lets says you have servers: A, B, C, D, and E and A is the node that you
don't want to be the leader. let's also say that C is a leader and commits
transaction x on A, B, and C but before D and E get x B and C fail. now A
is the only surviving node with x, so unless A can become the leader, at
least temporarily, D and E will never get x. if you follow Camille's
suggestion, you let A become the leader (since it has the most recent
transaction) and D and E will sync with A and get x. now if you restart A,
leader election will run again and D or E can be elected leader. this does
also show that you want the less desirable nodes to have lower server ids
so that there will be less chance of them becoming leader if there is a
"tie" (other nodes are just as uptodate as them).
On Sun, Nov 24, 2013 at 5:09 PM, Owen Kim <[EMAIL PROTECTED]> wrote:
> Observers can't vote in leader election, though right? I'm not sure the
> loss of fault tolerance would be worth it.
> The scenario is that I have a 5-node cluster but one node is in an network
> partition that gets DOSed around it. When this happens and it's leader, I
> see huge performance degradation. The real solution is obviously to move
> the node off that network but I wondered if there was an easy way to keep
> it from being leader in its configuration.