-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: 2.0.3
-
Component/s: Index Maintenance, Replication
-
Environment:ubuntu 10.04 base install using the mongo upstart repo
-
ALL
1) create a db with a capped collection
2) make sure the capped collection has an index on _id
3) add a new, empty member into the replica set containing the capped collection
after initial replication is over and the new member goes into RECOVERING, the index on the capped collection is not created. this causes oplog applies to be really really slow:
Wed Mar 14 03:17:07 [rsSync] replSet initial oplog application from mongo3.thedomain.net:27017 starting at Mar 14 01:18:02:2 to Mar 14 03:16:56:3
Wed Mar 14 03:29:26 [rsSync] replSet initialSyncOplogApplication applied 1000 operations, synced to Mar 14 01:18:17:3
Wed Mar 14 03:54:09 [rsSync] replSet initialSyncOplogApplication applied 2000 operations, synced to Mar 14 01:18:54:1
the workaround of removing the new member from the replica set by omitting it's --replSet, manually running ensureIndex and then re-starting the new member back inside the replica set seems to do the trick. recovery then completes rapidly. this might also work with other indexes besides '_id' – haven't tested.
see this thread:https://groups.google.com/d/topic/mongodb-user/oU66dwiRR4w/discussion
- is related to
-
SERVER-6577 capped collection _id index creation on secondaries not triggered by updates
- Closed
-
SERVER-5516 Capped collections (tracking ticket)
- Closed