[SERVER-20025] mongos fails to start if CSRS primary is not ismaster Created: 19/Aug/15 Updated: 25/Jan/17 Resolved: 29/Sep/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.1.7 |
| Fix Version/s: | 3.1.9 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jonathan Abrahams | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | 32qa | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Sharding 8 08/28/15, Sharding 9 (09/18/15), Sharding A (10/09/15) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
mongos fails to start if the primary node does not have ismaster set to true (see
|
| Comments |
| Comment by Spencer Brody (Inactive) [ 20/Jan/16 ] |
|
tung@misfit.com Can you elaborate on what you doing when you encountered this? Worth noting is that you cannot start up a mongos for the first time in a new cluster unless the config server has a primary. Existing clusters should have no problem starting new mongoses, however, even if there is no config server primary, so long as at least one config server is up. |
| Comment by Tung Nguyen [ 20/Jan/16 ] |
|
Looks like this is happening in 3.2.1 when the config cluster has already ready. Is anyone else experiencing the same issue? |
| Comment by Spencer Brody (Inactive) [ 29/Sep/15 ] |
|
Confirmed that this was fixed by |
| Comment by Githook User [ 29/Sep/15 ] |
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}Message: |
| Comment by Randolph Tan [ 19/Aug/15 ] |
|
Yes. I will rerun the attached test.js I wrote to make sure it passes once |
| Comment by Andy Schwerin [ 19/Aug/15 ] |
|
So this will go away once |
| Comment by Randolph Tan [ 19/Aug/15 ] |
|
This is because all operations in the catalog manager has the read preference setting set to PrimaryOnly. Confirmed that you can start a mongos once I switched to nearest in the code. Confirmed that you can also do queries on config collections as long as you pass slaveOk true or a read preference that allows reading secondaries. |
| Comment by Andy Schwerin [ 19/Aug/15 ] |
|
Actually, looks like we've separately confirmed this bug exists even for already initialized clusters. |
| Comment by Andy Schwerin [ 19/Aug/15 ] |
|
jonathan.abrahams, when a new sharded cluster is started, the first mongos (or some early mongos) initializes the config collections on the config servers. I suspect that the bug you've reported here only applies to a mongos contacting a not-yet-initialized cluster. To help me understand the scope of this bug, could you try the following?
Does the mongos started in the last step stay up, or does it shut down? |