[SERVER-34343] Initial sync should not timestamp secondary indexes at the current 'clusterTime' Created: 05/Apr/18  Updated: 29/Oct/23  Resolved: 08/May/18

Status: Closed
Project: Core Server
Component/s: Index Maintenance, Storage
Affects Version/s: 3.7.4
Fix Version/s: 4.0.0-rc0

Type: Bug Priority: Major - P3
Reporter: Louis Williams Assignee: Daniel Gottlieb (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-34440 Secondary reads from internal (non-ne... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2018-05-07
Participants:
Linked BF Score: 50

 Description   

During initial sync, a secondary will timestamp an index build at the clusterTime, which may occur after the lastAppliedOpTime. The lastAppliedOpTime is used to indicate the latest a reader is allowed to read. If secondary reads are allowed during batch application, a reader will wait for future catalog changes that may never come. The current workaround is to retry the read while taking the PBWM lock, which is suboptimal.



 Comments   
Comment by Githook User [ 08/May/18 ]

Author:

{'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb', 'username': 'dgottlieb'}

Message: SERVER-34343: startup2 states never require ghost timestamps
Branch: master
https://github.com/mongodb/mongo/commit/76df84766b802578547cdfe430c2ca6efd48547b

Comment by Louis Williams [ 01/May/18 ]

This hang can occur after initial sync completes, once the node is serving reads as a secondary.

Comment by Daniel Gottlieb (Inactive) [ 30/Apr/18 ]

Is this a problem specifically with initial sync or general oplog application? A node shouldn't be serving reads during initial sync.

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