[SERVER-40114] The repl two-phase collection drop reaper can log the same drop several times with different notification optimes Created: 13/Mar/19  Updated: 06/Dec/22  Resolved: 08/Jun/20

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

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Backlog - Storage Execution Team
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-39235 Support SE-based 2-phase drop for SE'... Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

[ReplicaSetFixture:job9:secondary] 2019-01-16T20:03:29.431+0000 I REPL     [replication-4] Completing collection drop for test.system.drop.1547668969i105t1.index_bigkeys_background_test with drop optime { ts: Timestamp(1547668969, 105), t: 1 } (notification optime: { ts: Timestamp(1547669004, 2), t: 2 })
[ReplicaSetFixture:job9:secondary] 2019-01-16T20:03:29.431+0000 I REPL     [replication-7] Completing collection drop for test.system.drop.1547668969i105t1.index_bigkeys_background_test with drop optime { ts: Timestamp(1547668969, 105), t: 1 } (notification optime: { ts: Timestamp(1547669005, 1), t: 2 })
[ReplicaSetFixture:job9:secondary] 2019-01-16T20:03:29.431+0000 I REPL     [replication-3] Completing collection drop for test.system.drop.1547668969i105t1.index_bigkeys_background_test with drop optime { ts: Timestamp(1547668969, 105), t: 1 } (notification optime: { ts: Timestamp(1547669004, 2), t: 2 })
[ReplicaSetFixture:job9:secondary] 2019-01-16T20:03:29.431+0000 I REPL     [replication-5] Completing collection drop for test.system.drop.1547668969i105t1.index_bigkeys_background_test with drop optime { ts: Timestamp(1547668969, 105), t: 1 } (notification optime: { ts: Timestamp(1547669005, 2), t: 2 })
[ReplicaSetFixture:job9:secondary] 2019-01-16T20:03:29.431+0000 I REPL     [replication-0] Completing collection drop for test.system.drop.1547668969i105t1.index_bigkeys_background_test with drop optime { ts: Timestamp(1547668969, 105), t: 1 } (notification optime: { ts: Timestamp(1547669004, 1), t: 2 })
[ReplicaSetFixture:job9:secondary] 2019-01-16T20:03:29.431+0000 I REPL     [replication-2] Completing collection drop for test.system.drop.1547668969i105t1.index_bigkeys_background_test with drop optime { ts: Timestamp(1547668969, 105), t: 1 } (notification optime: { ts: Timestamp(1547669004, 1), t: 2 })
[ReplicaSetFixture:job9:secondary] 2019-01-16T20:03:29.431+0000 I REPL     [replication-1] Completing collection drop for test.system.drop.1547668969i105t1.index_bigkeys_background_test with drop optime { ts: Timestamp(1547668969, 105), t: 1 } (notification optime: { ts: Timestamp(1547669004, 2), t: 2 })
[ReplicaSetFixture:job9:secondary] 2019-01-16T20:03:29.434+0000 I REPL     [replication-6] Completing collection drop for test.system.drop.1547668969i105t1.index_bigkeys_background_test with drop optime { ts: Timestamp(1547668969, 105), t: 1 } (notification optime: { ts: Timestamp(1547669005, 1), t: 2 })

Replication has many threads that run the code that notifies the drop-pending-reaper of work and executes that work synchronously. And the drop-pending-reaper does not prevent multiple callers from running drop collection for the same collection: it is a race between whether the first caller finishes the drop collection and deletes entries from the reaper's map before the next caller redundantly accesses the map to find drops to execute.


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