[SERVER-2158] repl set primary won't elect itself is a secondary is fresher Created: 29/Nov/10  Updated: 12/Jul/16  Resolved: 22/Dec/10

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 1.7.5

Type: Bug Priority: Major - P3
Reporter: Dwight Merriman Assignee: Kristina Chodorow (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-1826 replica sets - use data from secondar... Closed
is duplicated by SERVER-2090 replica set: on master election, shou... Closed
Operating System: ALL
Participants:

 Description   

a replica set primary will not elect itself if a secondary is fresher. this is a "legal" situation so we must handle.

currently it says:

Mon Nov 29 16:33:34 [rs Manager] replSet info not electing self, we are not freshest

so what to do. perhaps:

(1) take over even if not freshest if the time gap or # of operations gap is small. the secondary will then roll back (we'll need to test this). when this happens, log the optimes so the operator knows what is up.
(2) if the gap is larger, do what it does now, however, log more on the size of the gap. and we can have an override that says "take over anyway"

easy to reproduce, i just tried.



 Comments   
Comment by auto [ 22/Dec/10 ]

Author:

{u'login': u'kchodorow', u'name': u'Kristina', u'email': u'kristina@10gen.com'}

Message: sync against secondaries if primary is unavailable SERVER-2158
https://github.com/mongodb/mongo/commit/52a46867c7b862edf871df4a27f49858ff535802

Comment by Dwight Merriman [ 30/Nov/10 ]

actually, you are right. the best way to fix is to resync from the secondary and then assume primary. let's do that.

Comment by Eliot Horowitz (Inactive) [ 30/Nov/10 ]

You mean if a priority=0 secondary is fresher?

Need to be very careful here because with w=2 people assume data isn't lost...

We can't pull operations from there?

Generated at Thu Feb 08 02:59:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.