[SERVER-38910] Remove redundant rollback handling on index drops Created: 09/Jan/19  Updated: 29/Oct/23  Resolved: 09/Feb/21

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.9.0

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Dianna Hohensee (Inactive)
Resolution: Fixed Votes: 0
Labels: techdebt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-33161 Postpone WiredTigerKVEngine table dro... Closed
is depended on by SERVER-37637 Standalone mode nodes should ignore i... Closed
Related
related to SERVER-38548 Leverage the KVDropPendingIdentReaper... Closed
is related to SERVER-55397 Index build restart ident drops are n... Closed
is related to SERVER-37966 Do not wait for index build completio... Closed
is related to SERVER-38702 Set up FCV for simultaneous index builds Closed
Backwards Compatibility: Fully Compatible
Sprint: Storage NYC 2019-01-14, Execution Team 2021-02-22
Participants:
Linked BF Score: 137

 Description   

With the completion of SERVER-38548 making index drops two-phase, we can now remove the special handling where we rebuild indexes on rollback because the index table was dropped immediately and the dropIndex gets rolled back.

I believe this code in kv_storage_engine.cpp does the special handling and can now be eliminated safely.

And in this bit, it should also be safe to refactor away the "!foundIdent" piece. Dan G's explanation of that scenario was as follows, which won't happen anymore either with SERVER-38548 complete,

"
Suppose the oplog contains:
ts: 10, createIndex: "a"
ts: 30, dropIndex: "a"
If the secondary completes the background index and timestamps the `ready: true` write at ts: 20, rolling back to 25 will show a `ready: true` index, but no underlying table because it was dropped. (edited)
"

Note: A good way to test that those code paths are inactive might be to add some invariants that they never occur anymore and run a full evergreen patch.



 Comments   
Comment by Githook User [ 09/Feb/21 ]

Author:

{'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@mongodb.com', 'username': 'DiannaHohensee'}

Message: SERVER-38910 Remove index drop rollback handling on opening the storage engine.

This scenario can no longer occur because we wait for index drops to be majority
committed before dropping the underlying data table.
Branch: master
https://github.com/mongodb/mongo/commit/dc96088c84c5411b70caa0c01be000da1a1ae3d1

Comment by Dianna Hohensee (Inactive) [ 23/Jun/20 ]

I think this ticket can be tried again.

It doesn't look like there's been anything but logging format changes to the relevant code. I believe the issue described in the CR pertained to the v4.0->v4.2 upgrade path, where v4.0 didn't have two-phase index drop: this would no longer be a problem for v4.4->v4.6, since we've had two-phase drop since v4.2 (I think). Some extra testing might not go amiss, but I'm not sure whether it would be worth the trouble to test or not.

Comment by Dianna Hohensee (Inactive) [ 23/Jan/19 ]

Found that it is FCV dependent whether the code can be removed.

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