[SERVER-11716] renameCollection allows background index builds to yield Created: 15/Nov/13 Updated: 03/Mar/15 Resolved: 05/Feb/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Replication |
| Affects Version/s: | 2.4.7, 2.5.3 |
| Fix Version/s: | 2.7.8 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Asya Kamsky | Assignee: | Eric Milkie |
| Resolution: | Done | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Minor Change | ||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
renameCollection command rebuilds indexes the way they were originally created. When it's background, it allows yielding and can possibly allow a command on original collection which would cause a problem for replication since renameCollection is logged in the oplog after the index builds finish. |
| Comments |
| Comment by Eric Milkie [ 05/Feb/15 ] |
|
In 3.0, renameCollection no longer builds any indexes in the background. |
| Comment by Eric Milkie [ 28/Aug/14 ] |
|
redbeard0531 can you confirm this is fixed with your refactoring of renameCollection? |
| Comment by J Rassi [ 15/Nov/13 ] |
|
I support using a temp collection, at least on the destination. It's not correct to leave the target collection partially-full in case of a crash – a journal commit can be forced in the middle of renaming cross-database (otherwise it's impossible to rename collections of size >512MB across databases). Using a temp collection on the destination helps skirt that issue, at least. |
| Comment by Eric Milkie [ 15/Nov/13 ] |
|
One idea would be to rename locally to a temp collection name, copy to the destination db as a temp name, and then rename on the target once we're done with building the indexes. |
| Comment by J Rassi [ 15/Nov/13 ] |
|
At the risk of derailing the original issue: I suggest that renameDatabase should be logged as individual ops in the cross-database case (perhaps: individual document inserts, followed by individual system.index inserts, followed by a drop – or maybe put the background index builds last). The same-database case could stay as logOp('c'). |
| Comment by Asya Kamsky [ 15/Nov/13 ] |
|
The problem is that the collection was effectively copied - indexes were being built. I was thinking maybe the operation should go in the oplog after copy and before index builds. |
| Comment by Eric Milkie [ 15/Nov/13 ] |
|
If you drop a collection while it's being copied, what should happen? |