|
After renaming a collection which contains background indexes, the collection will be successfully renamed on the primary, correctly recorded in the oplog, but does not replicate, ie. the collection will not have been renamed on the secondaries. This is due to the following error on the secondaries:
2014-09-25T15:56:39.080+1000 [repl writer worker 1] build index on: db2.content properties: { v: 1, key: { _id: 1 }, name: "_id_", ns: "db2.content" }
|
2014-09-25T15:56:39.080+1000 [repl writer worker 1] building index using bulk method
|
2014-09-25T15:56:39.080+1000 [repl writer worker 1] build index done. scanned 1 total records. 0 secs
|
2014-09-25T15:56:39.080+1000 [repl writer worker 1] build index on: db2.content properties: { v: 1, key: { a: 1.0 }, name: "a_1", ns: "db2.content", background: true }
|
2014-09-25T15:56:39.083+1000 [repl writer worker 1] index build failed. spec: { v: 1, key: { a: 1.0 }, name: "a_1", ns: "db2.content", background: true } error: 13130 can't start bg index b/c in recursive lock (db.eval?)
|
2014-09-25T15:56:39.083+1000 [repl writer worker 1] restarting 0 index build(s)
|
2014-09-25T15:56:39.083+1000 [repl writer worker 1] warning: repl Failed command { renameCollection: "db1.content", to: "db2.content", dropTarget: true } on admin with status UnknownError Location13130 can't start bg index b/c in recursive lock (db.eval?) during oplog application
|
2014-09-25T15:56:48.965+1000 [repl writer worker 1] warning: repl Failed command { renameCollection: "db2.content", to: "db1.content", dropTarget: true } on admin with status UnknownError source namespace does not exist during oplog application
|
The problem does not occur in 2.7.5, so it must have been fixed between 2.7.4 and 2.7.5. It's still present in 2.6.4.
|