[SERVER-66089] Initial sync should do transaction table read with a later afterClusterTime Created: 29/Apr/22 Updated: 29/Oct/23 Resolved: 09/May/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.9, 4.4.15, 6.0.0-rc6, 6.1.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Matthew Russotto | Assignee: | Matthew Russotto |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Backport Requested: |
v6.0, v5.0, v4.4
|
||||||||||||||||
| Sprint: | Repl 2022-05-02, Repl 2022-05-16 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 15 | ||||||||||||||||
| Description |
|
To find the beginFetching and beginApplying timestamps in logical initial sync, we do a three-step process 1) Read the last optime on the sync source. 2) Read the transaction table on the sync source 3) Read the last optime on the sync source again. beginApplying is the result of the third step. beginFetching is either the result of the first step or a time in the transaction table. We must read the transaction table strictly after that everything before that last optime in the first step. On a primary sync source, that just means the no-holes point, which we achieve by using an afterClusterTime of (0,1). On a secondary sync source, after Additionally, we need to make sure everything after 3) is read after the lastApplied reaches the beginApplyingTimestamp. Fortunately we already do this by using an afterClusterTime of the beginApplyingTimestamp in the next query (for FCV) |
| Comments |
| Comment by Githook User [ 16/May/22 ] |
|
Author: {'name': 'Matthew Russotto', 'email': 'matthew.russotto@mongodb.com', 'username': 'mtrussotto'}Message: (cherry picked from commit 878b6bb32413dc105133ffac31e9a0cf21e930f4) |
| Comment by Githook User [ 16/May/22 ] |
|
Author: {'name': 'Matthew Russotto', 'email': 'matthew.russotto@mongodb.com', 'username': 'mtrussotto'}Message: (cherry picked from commit 878b6bb32413dc105133ffac31e9a0cf21e930f4) |
| Comment by Githook User [ 16/May/22 ] |
|
Author: {'name': 'Matthew Russotto', 'email': 'matthew.russotto@mongodb.com', 'username': 'mtrussotto'}Message: (cherry picked from commit 878b6bb32413dc105133ffac31e9a0cf21e930f4) |
| Comment by Matthew Russotto [ 10/May/22 ] |
|
NB: if backporting, make sure to backport |
| Comment by Githook User [ 09/May/22 ] |
|
Author: {'name': 'Matthew Russotto', 'email': 'matthew.russotto@mongodb.com', 'username': 'mtrussotto'}Message: |