[SERVER-22139] Config server reports that it is in replica set mode, but we are still using the legacy SCCC protocol for config server communication Created: 12/Jan/16 Updated: 26/Jan/16 Resolved: 25/Jan/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.2.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | João Soares | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: | Just setup a sharded cluster following the 3.2 normal guide and instead of using:
just add the first one and then the following 2 separately:
The rest is just the normal configuration files similar to instructed on the guide: Config Server configuration file:
Config Server Conf:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: |
| Description |
|
When making a fresh 3.2 deployment on my development mac with 3 new and clean WiredTiger CSRS config servers I keep getting the following error messages on mongos as soon as any balancing starts to occur:
No config server configurations has the flag configsvrMode: sccc present. Just as I was writing this very issue I noticed I did something different that than said on the guide, I did not add the 3 hosts when initiating the CSRS, I added just one and then added the other two separately using
When I restarted all over again and did the 3 at once my problems were fixed, but the question remains, why wouldn't it work. I ended up submitting the issue as I see others doing the same. |
| Comments |
| Comment by Spencer Brody (Inactive) [ 15/Jan/16 ] |
|
Hi jasoares, |
| Comment by João Soares [ 12/Jan/16 ] |
|
Thank you Andy, you are right, it has nothing to do with the initiation process of the first config server on the replica set. The cause is indeed the string passed to the mongos --configdb. I would change this to improvement if I could edit the issue. |
| Comment by Kaloian Manassiev [ 12/Jan/16 ] |
|
spencer, will this bug, which is easy to cause by a typo, go away once we have the zero-downtime upgrade logic in place? |
| Comment by Andy Schwerin [ 12/Jan/16 ] |
|
What string are you using for the --configdb argument to mongos? It should bea replica set connection string, like configReplSet/host1,host2,host3. I think you're passing an old-style connection string, host1,host2,host3 (without the replset name at front). |