[SERVER-46722] update StorageTimestampTests TimestampIndexBuilderOnPrimary dbtest test case Created: 09/Mar/20  Updated: 29/Oct/23  Resolved: 24/Apr/20

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.4.0-rc7, 4.7.0

Type: Improvement Priority: Major - P3
Reporter: Benety Goh Assignee: Maria van Keulen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
related to SERVER-48510 StorageTimestampTests::TimestampIndex... Closed
is related to SERVER-46714 dbtest StorageTimestampTests suite re... Closed
is related to SERVER-43642 Remove IndexBuilder in favor of Index... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.4
Sprint: Execution Team 2020-05-04
Participants:
Linked BF Score: 0

 Description   

This test should be updated to test the time stamping logic using a non-applyOps method. It no longer works with applyOps due to SERVER-41554.



 Comments   
Comment by Githook User [ 19/May/20 ]

Author:

{'name': 'Maria van Keulen', 'email': 'maria@mongodb.com', 'username': 'mvankeulen94'}

Message: SERVER-46722 Update primary createIndex oplog application dbtest

(cherry picked from commit 2cc8dcf2807a19cffe0d93c857730ec694696abf)
Branch: v4.4
https://github.com/mongodb/mongo/commit/c2be2d5383f8df149b05d13dc5911503b3f8ca82

Comment by Githook User [ 24/Apr/20 ]

Author:

{'name': 'Maria van Keulen', 'email': 'maria@mongodb.com', 'username': 'mvankeulen94'}

Message: SERVER-46722 Update primary createIndex oplog application dbtest
Branch: master
https://github.com/mongodb/mongo/commit/2cc8dcf2807a19cffe0d93c857730ec694696abf

Comment by Maria van Keulen [ 22/Apr/20 ]

Thanks for the clarification, Dan.

It seems that the code path of interest in the test case is oplog application of a createIndexes oplog entry on a primary. My patch will be replacing the applyOps call with a simulation of the oplog application. As a result, the primary must be in a state in which it cannot accept writes, otherwise it will mistakenly try to create its own oplog entry for the createIndexes command during the oplog application. This also means that the primary cannot build the index in the foreground, since it cannot accept writes, and the oplog application mode is kSecondary. This comment of the test case of interest will no longer be true as a result.
The only other way that the comment would be true for a primary node is if it were applying oplog entries in kRecovering mode, which AFAIK is not possible.

As an update, I was unable to write the test to use the createIndexes oplog entry, due to index build synchronization difficulties. Using the two-phase index build oplog entries instead addresses the synchronization issues and also is consistent with what we expect in practice.

Comment by Daniel Gottlieb (Inactive) [ 21/Apr/20 ]

The "drain" referenced on TimestampIndexBuilderOnPrimary is a particular phase when nodes step up to become primary. From the replication architecture guide:

At this point, whether catchup was successful or not, the node goes into "drain mode". This is when the node has already logged "transition to PRIMARY", but has not yet applied all of the oplog entries in its oplog buffer. replSetGetStatus will now say the node is in PRIMARY state.

The "drain" referenced in TimestampIndexBuildDrain is referring to draining the concurrent writes of a hybrid index build.

Comment by Maria van Keulen [ 20/Apr/20 ]

I'm wondering if the test case of interest is still necessary after SERVER-43642. It looks like we have a separate test for timestamping index builds during drain, which was one of the cases mentioned in the TimestampIndexBuilderOnPrimary test.

Generated at Thu Feb 08 05:12:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.