[SERVER-37554] Cannot drop config.system.sessions when calling addShard on 4.0 inMemory cluster Created: 10/Oct/18 Updated: 27/Oct/23 Resolved: 12/Oct/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 4.0.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Louisa Berger | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Sharding
|
||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v4.0
|
||||||||
| Steps To Reproduce: |
|
||||||||
| Participants: | |||||||||
| Description |
|
I've attached the conf files I used for my sharded cluster. I was running this on 4.0.3-ent. I tried running the csrs with and without inMemory (wasn't sure if it's allowed for csrs) and saw the same behavior both ways. When I try to add the rs as a shard, I get the following:
When I tried the same repro with wiredTiger, I did not see this issue. Note: I found this while testing, not in a production or customer issue. cc kaloian.manassiev esha.maharishi |
| Comments |
| Comment by Andy Schwerin [ 11/Oct/18 ] | ||||||||||||||||
|
If the in-memory member has votes:1, then you should set writeConcernMajorityDefault:false, generally speaking. | ||||||||||||||||
| Comment by Louisa Berger [ 11/Oct/18 ] | ||||||||||||||||
|
Setting to false fixes the issue! So we can add a validation on our end that inMemory shards must always have writeConcernMajorityDefault:false. Is that correct schwerin? Also, is this true for any shard with at least one inMemory member? | ||||||||||||||||
| Comment by Andy Schwerin [ 11/Oct/18 ] | ||||||||||||||||
|
My fault. I should have said to set that parameter to false. The default is true. | ||||||||||||||||
| Comment by Louisa Berger [ 11/Oct/18 ] | ||||||||||||||||
|
Just tried with writeConcernMajorityJournalDefault: true and got the same issue:
| ||||||||||||||||
| Comment by Andy Schwerin [ 11/Oct/18 ] | ||||||||||||||||
|
What's the replica set config look like for the replica set? Replica sets that include voting memory-only nodes need to set writeConcernMajorityJournalDefault: true in their replica set configuration, or they won't be able to commit majority writes. Perhaps that is causing you to experience this problem, louisa.berger. | ||||||||||||||||
| Comment by Louisa Berger [ 10/Oct/18 ] | ||||||||||||||||
|
blake.oler yes, same in both releases. My attached logs are for 4.0.3 | ||||||||||||||||
| Comment by Blake Oler [ 10/Oct/18 ] | ||||||||||||||||
|
louisa.berger steps to reproduce mention 4.0.2, but the description mentions 4.0.3. Does the issue exist in both releases? And how about the latest master build? |