[SERVER-2168] Allow read only slaves to enter Secondary state even if Primary is unreachable Created: 01/Dec/10  Updated: 29/Feb/12  Resolved: 02/Sep/11

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

Type: Improvement Priority: Major - P3
Reporter: Mike Copley Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

As per the summary, it would be good to optionally configure specific slaves to enter Secondary state even if they cannot contact Primary. In my particular scenario the nature of the data is such that it is safe to serve that data to clients without checking Primary on startup.

My test setup is a 5 node layout: 3 with Priority 1, and 2 with Priority 0 (i.e. read-only always secondary). The secondary servers are on a separate physical machine from the primary ones. I pretend to have a power cut and reboot the primary machine. It starts up - but no mongod instances running. Likewise, I pretend the secondary also has power cut and reboot it. It starts up - and so does mongod (let's say someone slipped up to not configure primary to automatically start mongod). The secondary priority-0 instances now remain in STARTUP2 state until a Primary is reachable. Thus when I try to query (using mongo) I get:

> db.getMongo().setSlaveOk()
> use Example
switched to db Example
> db.Widget.find()
error:

{ "$err" : "not master or secondary, can't read", "code" : 13436 }

> Wed Dec 1 11:36:30 [conn4] assertion 13436 not master or secondary, can't read ns:Example.Widget query:{}

This scenario is a very quirky one I admit. It's very unlikely but I'm just going through the corner cases.



 Comments   
Comment by Kristina Chodorow (Inactive) [ 02/Sep/11 ]

This has already been fixed. If a member comes up, even if it can't reach anyone else in the set, it will become a secondary.

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