[SERVER-22392] "Operation timed out" when enableSharding on new cluster Created: 01/Feb/16 Updated: 18/Apr/16 Resolved: 05/Mar/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.2.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Johannes Ziemke | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Steps To Reproduce: | 1. Create 6 replication sets with 3 nodes each |
||||||||||||
| Sprint: | Sharding 10 (02/19/16), Sharding 11 (03/11/16) | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 0 | ||||||||||||
| Description |
|
Given a mongodb 3.2.1 cluster with multiple shards, enabling sharding for a database yields "Operation timed out":
Adding shards worked just fine but sh.status() also shows timeout issues:
On the config server RS, rs.status() looks good:
All this was working when I did the same on 3.2.0 without authentication. So it's either related to the authentication or a regression in 3.2.1. I'll try to reproduce this with 3.2.1 now. |
| Comments |
| Comment by Kelsey Schubert [ 18/Apr/16 ] |
|
Hi joerg.rech, Thank you reporting this issue. Can you please open a new ticket so we can investigate the behavior you are describing? Kind regards, |
| Comment by Jörg Rech [ 18/Apr/16 ] |
|
I have the same problem with MongoDB 3.2.5 on Microsoft Azure with large collections (> 1 Billion documents; >2 TB compressed) for commands such as sh.shardCollection ({{ "code" : 50, "ok" : 0, "errmsg" : "Operation timed out" }}), db.count and have problem during balancing Last reported error: could not get updated shard list from config server due to ExceededTimeLimit Operation timed out. Is there a way to increase the timeout in the mongodb config? |
| Comment by Ramon Fernandez Marina [ 05/Mar/16 ] |
|
fish, after your last successful attempt we haven't heard back from you, so I assume you haven't had any further issues. I'm therefore going to close this ticket for the time being, but if the same issue reappears please post back and we can reopen. If you run into some other issues please open a new ticket. Note also that 3.2.3 is out, and 3.2.4 is scheduled for next week (with a 3.2.4-rc0 release candidate already published), so you may want to consider upgrading since these releases include a number of fixes that your configuration could benefit from. Regards, |
| Comment by Johannes Ziemke [ 04/Feb/16 ] |
|
Ah darn.. now I created it again (the 3rd time) and now it seems to work.. I'll continue with data import and maybe run into this/similar issues. |
| Comment by Johannes Ziemke [ 04/Feb/16 ] |
|
Hi Spencer, 1) Yes, we're using packer to build mongodb AMIs and cloudformation to deploy it:
I'll create a new mongodb 3.2.1 cluster now and provide the other informations soon. |
| Comment by Spencer Brody (Inactive) [ 01/Feb/16 ] |
|
Hi Johannes,
If any of this information I've requested is sensitive or contains things you'd rather not have attached to this (public) ticket, feel free to file a new ticket in the Community Private (SUPPORT) project with the information I requested and link it here. Tickets in that project will only be viewable by you and engineers at MongoDB. |
| Comment by Johannes Ziemke [ 01/Feb/16 ] |
|
Okay, so I can reliably reproduce this with 3.2.1. I've created the cluster like 3-4 times, always running into this issue, although sometimes sh.enableSharding("my-db") still works and it fails on sh.shardCollection. Sometimes sh.status() fails as well, sometimes it works. I've also tried to reproduce this with 3.2.0 but can't, so to me it really looks like a regression unless there were some breaking changes between 3.2.0 and 3.2.1. |