[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:
Backports
Depends
Related
is related to SERVER-66356 Fix test failures in initial_sync_wit... Closed
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 SERVER-58636, that means the lastAppliedSnapshot must reach that point. We can achieve that by instead using an afterClusterTime that is the result of 1).

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: SERVER-66089 Initial sync should do transaction table read with a later afterClusterTime.

(cherry picked from commit 878b6bb32413dc105133ffac31e9a0cf21e930f4)
Branch: v4.4
https://github.com/mongodb/mongo/commit/a672707bcbde034c24ab426f481714b3d5b8bfc6

Comment by Githook User [ 16/May/22 ]

Author:

{'name': 'Matthew Russotto', 'email': 'matthew.russotto@mongodb.com', 'username': 'mtrussotto'}

Message: SERVER-66089 Initial sync should do transaction table read with a later afterClusterTime.

(cherry picked from commit 878b6bb32413dc105133ffac31e9a0cf21e930f4)
Branch: v6.0
https://github.com/mongodb/mongo/commit/fa5d029fd8a6f06e42be69a1ba7842ca35e39333

Comment by Githook User [ 16/May/22 ]

Author:

{'name': 'Matthew Russotto', 'email': 'matthew.russotto@mongodb.com', 'username': 'mtrussotto'}

Message: SERVER-66089 Initial sync should do transaction table read with a later afterClusterTime.

(cherry picked from commit 878b6bb32413dc105133ffac31e9a0cf21e930f4)
Branch: v5.0
https://github.com/mongodb/mongo/commit/d424a76ded97659d5c0933444a3210df82f096e6

Comment by Matthew Russotto [ 10/May/22 ]

NB: if backporting, make sure to backport SERVER-66356 with it.

Comment by Githook User [ 09/May/22 ]

Author:

{'name': 'Matthew Russotto', 'email': 'matthew.russotto@mongodb.com', 'username': 'mtrussotto'}

Message: SERVER-66089 Initial sync should do transaction table read with a later afterClusterTime.
Branch: master
https://github.com/mongodb/mongo/commit/878b6bb32413dc105133ffac31e9a0cf21e930f4

Generated at Thu Feb 08 06:04:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.