[SERVER-16513] Changes made by applyOps during migration may not be propagated to the destination shard Created: 11/Dec/14 Updated: 06/Dec/22 Resolved: 01/Apr/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 2.8.0-rc2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding
|
| Operating System: | ALL |
| Participants: |
| Description |
|
MigrateFromStatus::logOp currently ignores all commands so any document updates during a migration with applyOps can be missed if the document was cloned before the applyOps. |
| Comments |
| Comment by Kaloian Manassiev [ 01/Apr/19 ] |
|
applyOps is an internal operation used to support our backup/restore solutions and that's on a quiesced system. Because of this, during a restore, there should not be chunk migrations. |
| Comment by Randolph Tan [ 12/Jan/15 ] |
|
It has been like this since v1.6. |
| Comment by Andy Schwerin [ 12/Jan/15 ] |
|
renctan, how far back in time does this bug go? The applyOps command is primarily for internal use, and ultimately destined for the dustbin. If this behavior is a regression, it's slightly higher priority, but if it's not, I think we might leave it alone. |