[SERVER-57769] Operation time from donor may be greater than any oplog timestamp on the recipient after tenant migration Created: 16/Jun/21 Updated: 29/Oct/23 Resolved: 23/Jun/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0-rc4, 5.1.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Jack Mulrow |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | pm-1791_other_required | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Backport Requested: |
v5.0
|
||||
| Sprint: | Sharding 2021-06-28 | ||||
| Participants: | |||||
| Description |
|
The recipient in a tenant migration is guaranteed to persist an oplog entry with a timestamp >= the migration's block timestamp, but cluster time can advance on the donor after the block timestamp has been selected (from writes to other tenant's data or internal collections). This means the operation time a client receives when reading from the donor may be greater than the block timestamp, so if it performs an afterClusterTime read on the recipient after the migration finishes, that timestamp may not exist in the recipient's oplog, leading to a stall waiting for write concern until the next write on the recipient - from any tenant, background activity, or the periodic noop writer (the next write is guaranteed to satisfy the afterClusterTime because cluster times from the donor are gossiped to the recipient). A similar problem exists in sharded clusters and is handled by writing a noop oplog entry, but this logic is disabled for standalone replica sets. |
| Comments |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 23/Jun/21 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: (cherry picked from commit 536090be65b70cc0f73ddbbffe5c501c12143a0d) |
| Comment by Githook User [ 22/Jun/21 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: |
| Comment by Jack Mulrow [ 21/Jun/21 ] |
|
Re-opening because I realized we have the same problem with donors. |
| Comment by Githook User [ 21/Jun/21 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: (cherry picked from commit fca4506a72e32e2346ddaa7e0a7d9d59f2138d8e) |
| Comment by Githook User [ 21/Jun/21 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: |