[SERVER-10058] Possible race condition with ensureIndex (text only?) Created: 28/Jun/13 Updated: 10/Dec/14 Resolved: 28/Jun/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | 2.4.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jason R. Coombs | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
mongodb 2.4.4; pymongo 2.4.2 |
||
| Issue Links: |
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Steps To Reproduce: | I haven't yet tried to reproduce the issue, but here's a proposed technique: 1. Deploy mongod 2.4.4 with textSearchEnabled. |
||||||||||||
| Participants: | |||||||||||||
| Description |
|
Today I encountered a situation where a brand new (test) database had become corrupted. I realized too late that I should have saved the state for analysis. Here's roughly what happened: Configured the mongod to enableTextSearch. coll.ensure_index([('qsl', 'text')], background=True) On a collection in that restored db. When I tried to query the text index, I got an error indicating a problem because there was "more than one text index" (I'm unsure about the wording). I thought, "how weird," queried the collection for its indexes and sure enough, it had two copies of the /exact same index/ (name, type, etc). So I removed it, and the remove operation succeeded. Just one remove and both manifestations were gone. Great, I thought, problem solved, but I was wrong. Subsequently, whenever I tried to start the app (which would recreate the index), I got the same error reported here (https://groups.google.com/forum/#!topic/mongodb-user/5xNYJVJdp5c). Basically, it seems my database was corrupted. That's when I dropped the database and started again. This time, instead of starting the two apps in parallel, I only started one locally (so ensureIndex would have been called once first), and everything seems to be running swimmingly. Here's what I suspect happened: Alternatively, I am using pymongo 2.4.2, which is somewhat dated, and could be implicated. In any case, mongod is almost certainly implicated here. I would be shocked if this issue existed for standard indexes. I'm guessing that text indexes are somehow implicated (perhaps bypassing checks that standard indexes using). I'm reporting this here because I wanted to capture the issue while I still remember the details. I invite others to investigate further. |
| Comments |
| Comment by Jason R. Coombs [ 28/Jun/13 ] |
|
Awesome. Thanks for the follow-up and workaround suggestions. |
| Comment by J Rassi [ 28/Jun/13 ] |
|
This is a known issue (
|