[SERVER-23562] cluster hung a moment when use 'aaa' which not in the cluster Created: 06/Apr/16 Updated: 14/Jun/16 Resolved: 14/Jun/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Question | Priority: | Major - P3 |
| Reporter: | ufo ofu | Assignee: | Kaloian Manassiev |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Sprint: | Sharding 14 (05/13/16), Sharding 15 (06/03/16), Sharding 16 (06/24/16) | ||||||||
| Participants: | |||||||||
| Description |
|
cluster hung a moment when use 'aaa' which not in the cluster. all connection will reconnected.
environment |
| Comments |
| Comment by Kaloian Manassiev [ 14/Jun/16 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
The bug in question ( Best regards, | ||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kaloian Manassiev [ 31/May/16 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
Thank you liang.zhang@17zuoye.com for providing me with the set of indexes. I do not see anything wrong with these indexes so the most likely cause for the stalls when trying to use a non-existent database remains to be Like I mentioned, this bug was fixed in version 3.2, but is still present in 3.0 and earlier versions. Would it be possible that you attempt to reproduce it with the latest 3.2 release and let me know if this helps? Best regards, | ||||||||||||||||||||||||||||||||||||||||||||
| Comment by ufo ofu [ 26/May/16 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
This behavior can occur in the cluster: A total of five shards mongos> use config , "ns" : "config.lockpings", "name" : "id" } , "ns" : "config.locks", "name" : "id" } , "ns" : "config.lockpings", "name" : "ping_1" } , "ns" : "config.changelog", "name" : "id" } , "ns" : "config.version", "name" : "id" } , "ns" : "config.settings", "name" : "id" } , "ns" : "config.chunks", "name" : "id" } , "unique" : true, "ns" : "config.chunks", "name" :"ns_1_min_1" } , "unique" : true, "ns" : "config.chunks", "name" : "ns_1_shard_1_min_1" } , "unique" : true, "ns" : "config.chunks", "name" : "ns_1_lastmod_1" } , "ns" : "config.shards", "name" : "id" } , "unique" : true, "ns" : "config.shards", "name" : "host_1" } , "ns" : "config.mongos", "name" : "id" } , "ns" : "config.databases", "name" : "id" } , "ns" : "config.collections", "name" : "id" } , "ns" : "config.tags", "name" : "id" } , "unique" : true, "ns" : "config.tags", "name" : "ns_1_min_1" } , "ns" : "config.locks", "name" : "state_1_process_1" } , "name" : "ts_1", "ns" : "config.locks" } , "name" : "id", "ns" : "config.actionlog" } Another cluster case this phenomenon did not occur mongos> use config , "name" : "id", "ns" : "config.changelog" } , "name" : "id", "ns" : "config.actionlog" } , "name" : "id", "ns" : "config.locks" } , "name" : "id", "ns" : "config.chunks" } , "name" : "ts_1", "ns" : "config.locks" } , "name" : "state_1_process_1", "ns" : "config.locks" } , "name" : "ns_1_min_1", "ns" : "config.chunks" } , "name" : "ns_1_shard_1_min_1", "ns" : "config.chunks" } , "name" : "ns_1_lastmod_1", "ns" : "config.chunks" } , "name" : "id", "ns" : "config.collections" } , "name" : "id", "ns" : "config.lockpings" } , "name" : "id", "ns" : "config.databases" } , "name" : "id", "ns" : "config.mongos" } , "name" : "ping_1", "ns" : "config.lockpings" } , "name" : "id", "ns" : "config.shards" } , "name" : "host_1", "ns" : "config.shards" } , "name" : "id", "ns" : "config.tags" } , "name" : "ns_1_min_1", "ns" : "config.tags" } , "name" : "id", "ns" : "config.settings" } , "name" : "id", "ns" : "config.version" } | ||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kaloian Manassiev [ 23/May/16 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
Thanks for the prompt response. The metadata operations I am referring to happen against the config.databases collection. How big is it in each of the two clusters you have listed above? Also, this collection should also have index on it for the database name. Can you please run db.getIndexes() and paste the output? Thanks in advance. -Kal. | ||||||||||||||||||||||||||||||||||||||||||||
| Comment by ufo ofu [ 23/May/16 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
Thank you for your answer. ).count() Another cluster case this phenomenon did not occur ).count() Is it because the amount of data in congfig database? | ||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kaloian Manassiev [ 23/May/16 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
Apologies for the delayed response. I tried to reproduce the problem you are experiencing, by accessing an unknown database and I am unable to get any existing shard connections to get reset. However, one thing which I noticed is related to My suspicion is that you are experiencing the side effects of This bug was fixed in version 3.2, but is still present in 3.0 and earlier versions. Would it be possible that you attempt to reproduce it with the latest 3.2 release and let me know if still occurs? Best regards, | ||||||||||||||||||||||||||||||||||||||||||||
| Comment by ufo ofu [ 08/Apr/16 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
environment
run command:
"cluster hung" means all connection will reconnected at a moment. The client is due to reconnect, resulting in slow operation. The client's Slow operation is mainly due to reconnect. mongos log
| ||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kaloian Manassiev [ 06/Apr/16 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
Can you please provide the following information to help us better understand the problem you are encountering.
Also, can you elaborate on what does "cluster hung" means? I.e., did the command timeout or it just got stuck there indefinitely. Best regards, |