[SERVER-4262] when dropping collections need to invalidate all conn sharding state Created: 11/Nov/11 Updated: 11/Jul/16 Resolved: 12/Jun/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 2.1.2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Greg Studer | Assignee: | Greg Studer |
| Resolution: | Done | Votes: | 7 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Description |
|
When dropping sharded collections on mongod, we need to invalidate all connection state for that namespace. If the collection gets recreated, this information will be stale. |
| Comments |
| Comment by auto [ 15/Jun/12 ] |
|
Author: {u'date': u'2012-06-15T13:17:50-07:00', u'email': u'greg@10gen.com', u'name': u'Greg Studer'}Message: |
| Comment by auto [ 15/Jun/12 ] |
|
Author: {u'date': u'2012-06-15T13:06:26-07:00', u'email': u'greg@10gen.com', u'name': u'Greg Studer'}Message: |
| Comment by Greg Studer [ 12/Jun/12 ] |
|
Only fixed with a full upgrade of all cluster portions to 2.1.2/2.2. Behavior of writes while the drop is in progress is undefined - they may succeed and be added to a new collection with the same name afterward, they may not. |
| Comment by auto [ 11/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 11/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: This reverts commit f1852efa8e4e5d702c472c35fb45d0a29a90d7d3. |
| Comment by auto [ 11/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: This reverts commit 2deb6a2f1b457adc58436f11dd730d1fcc525084. |
| Comment by auto [ 11/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: This reverts commit ccd568b6e292b4641f60c704ddf983240e8f23a4. |
| Comment by auto [ 11/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: This reverts commit 38a258f13283440eb3f19afbb653d872b04d0d98. |
| Comment by auto [ 11/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: This reverts commit 2e12c38432817131bfa463e763198436ac82d115. |
| Comment by auto [ 11/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: This reverts commit e123c445170548c0eb248dc1b221dfb09aa9b1ec. |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: Revert " This reverts commit 9494663f0ab571215dba96f10cdca78a1a36cddc. |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: Revert " This reverts commit d7f89643a917538fa953a17d80acc164fb4885ad. |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: Revert " This reverts commit bc4475ebcb2548e21fadf44549b73f61f0c577ce. |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: Revert " This reverts commit a65d2bc01f263ccefc1a7392f48b362338c83daf. |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: Revert " This reverts commit 4c881e3c93ee29fa4ca22d9da7b7a45150448455. |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: Revert " This reverts commit 13aa0a0276eb239454da00d65f8f15aa1a97bb10. |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: also requires a fix for the WBL to report errors more nicely |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: also better track and message how many writebacks are being processed |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: again, also refactor option parameters |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: also refactor to make option-passing cleaner |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: Otherwise propagates as a "HostAndPort host empty" error, which is very misleading. |
| Comment by auto [ 09/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: In particular, a database drop may abort at any collection which has a lock taken, and so |
| Comment by auto [ 08/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 08/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 08/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 08/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 08/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 08/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: need to check epoch when comparing non-zero, otherwise we'll never reload different epochs |
| Comment by auto [ 08/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 08/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: Insert has been updated to correctly detect unsharded collections without errors, update and remove still contain race conditions partially mitigated by the WBL fix here. Also includes tests of this functionality. |
| Comment by auto [ 08/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 08/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 08/Jun/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 22/May/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 21/May/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: |
| Comment by auto [ 21/May/12 ] |
|
Author: {u'login': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: Refactoring to allow better tracking of when we compare versions, since this needs to be changed. |
| Comment by Eliot Horowitz (Inactive) [ 17/Apr/12 ] |
|
@Y Wayne: There are tests that test this functionality, but there were edge cases they didn't catch. |
| Comment by Y. Wayne Huang [ 17/Apr/12 ] |
|
all of these version-related issues and the fact that none of the fixes are backported to 2.0 really speaks volumes about priorities at 10gen. nobody has bothered to test very simple use cases that cause these problems before releasing a "stable" version. instead of properly fixing the issues and backporting to stable, we are told to implement ridiculous workarounds like restarting mongos or running experimental versions. seriously, wtf guys? |
| Comment by Greg Studer [ 17/Apr/12 ] |
|
For these cases, another workaround that avoids version issues and restarting is to append OIDs to recycled namespaces, so that the namespaces aren't re-used but new namespaces are continually created. |
| Comment by Y. Wayne Huang [ 17/Apr/12 ] |
|
it's unfortunate that this is not being backported to 2.0. restarting mongos hardly seems like a suitable workaround, particularly for workloads where collections are automatically created/removed periodically. |
| Comment by David Nesbitt [ 17/Apr/12 ] |
|
Workaround from Kristina Chodorow: "You could try running the flushRouterConfig command, but you will http://groups.google.com/group/mongodb-user/browse_thread/thread/29898a80b4aed670 |
| Comment by auto [ 14/Nov/11 ] |
|
Author: {u'login': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}Message: fix case where a sharded collection is dropped and we need to reset state |
| Comment by Eliot Horowitz (Inactive) [ 14/Nov/11 ] |
|
The above commit fixes the test, but there probably is a better way to do this pre-emptively. |
| Comment by Greg Studer [ 13/Nov/11 ] |
|
Attached test case which reproduces the issue (on 2.0 at least). |