[SERVER-12844] unable to build background index on secondary Created: 23/Feb/14 Updated: 10/Dec/14 Resolved: 25/Feb/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance, Replication |
| Affects Version/s: | 2.6.0-rc0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Daniel Pasette (Inactive) | Assignee: | Eric Milkie |
| Resolution: | Cannot Reproduce | 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: |
|
||||
| Participants: | |||||
| Description |
|
| Comments |
| Comment by Eric Milkie [ 21/Apr/14 ] | |
|
The MongoDB shell's ensureIndex shell helper will use the system.indexes insertion method if the shell's writeMode is "compatibility". You can enable this write mode by starting the shell with a command line parameter:
| |
| Comment by Kent Sibilev [ 21/Apr/14 ] | |
|
Thanks for the info. That's great news. Could you please provide a pointer on how to use system.indexes instead? Thanks. | |
| Comment by Eric Milkie [ 21/Apr/14 ] | |
|
Hi Kent. I believe your problem is | |
| Comment by Kent Sibilev [ 21/Apr/14 ] | |
|
We've just upgraded to 2.6.0 and run into this issue. A new index is created on master but on the secondaries we get the following in the log files: 2014-04-16T20:56:53.639+0000 [repl writer worker 2] build index on: xxx.messages properties: { v: 1, key: { fname: 1.0 }, name: "fname_1", ns: "xxx.messages", background: true } , name: "fname_1", ns: "xxx.messages", background: true } error: 13130 can't start bg index b/c in recursive lock (db.eval?) Any solutions? | |
| Comment by Daniel Pasette (Inactive) [ 25/Feb/14 ] | |
|
can no longer repro this issue with new build of mongo server and shell. resolving | |
| Comment by Eric Milkie [ 24/Feb/14 ] | |
|
I also don't understand the output in the description. The index build should have been done by a spawned thread [repl index builder 0], but instead it is being done inline using one of the replication threads (so of course it fails). I can't think of why this would happen unless you were doing something like applyOps command. | |
| Comment by Eric Milkie [ 24/Feb/14 ] | |
|
(I tried running the test with smoke.py --auth as well, and it still passes for me) | |
| Comment by Eric Milkie [ 24/Feb/14 ] | |
|
The attached .js test passes for me. There must be a race so I'll look into that next. |