[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:
Related
is related to SERVER-13951 uncommited UnitOfWork needs to rollback Closed
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?
I would argue that the copy should halt and both the source and target should vanish.
If we do it that way, fixing this situation becomes easier.
Essentially, we need to make the cloner be aware of the same operations as the background indexer, so that it can recover from yielding properly.

Generated at Thu Feb 08 03:26:34 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.