[SERVER-83119] Secondary replica crashes on clustered collection if notablescan is enabled Created: 10/Nov/23  Updated: 02/Feb/24  Resolved: 12/Jan/24

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 5.3.0, 5.0.0, 6.0.0, 7.0.0, 7.2.0-rc0
Fix Version/s: 7.2.1, 7.3.0-rc0, 7.0.6

Type: Bug Priority: Major - P3
Reporter: Louis Williams Assignee: Peter Volk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Documented
is documented by DOCS-16583 [SERVER] Investigate changes in SERVE... Backlog
Problem/Incident
Related
is related to SERVER-83475 Passthrough tests for notablescan Backlog
Assigned Teams:
Query Optimization
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v7.2, v7.0, v6.0, v5.0
Sprint: QO 2023-12-11, QO 2023-12-25, QO 2024-01-08, QO 2024-01-22
Participants:
Linked BF Score: 145

 Description   

On a clustered collection when notablescan is enabled:

  • Query to delete multiple documents using a secondary index on the primary.  Eg., db.coll.remove({x:{$gte:0}}), where an index is defined for the field x.
  • We replicate oplog entries to delete documents on the secondary replica by _id
  • On the secondary, the deletion is not done by the indexed field x but by _id.  However, the query system doesn't recognize the clustered index as a real _id index, and it fails. This causes a crash of the secondary replica.

In this scenario, the plan for the delete by _id on the secondary would include a CLUSTERED_IXSCAN and thus should not be blocked by the notablescan setting.

The solution is to fix the planner logic to allow CLUSTERED_IXSCAN with the notablescan setting.

See the repro script in the comment below and see the code here



 Comments   
Comment by Githook User [ 02/Feb/24 ]

Author:

{'name': 'Peter Volk', 'email': '77723508+HCSPete@users.noreply.github.com', 'username': 'HCSPete'}

Message: SERVER-83119 Qualify a ClusteredIndexscan as an allowed operation when notablescan is set (#18507)

GitOrigin-RevId: 19aee73de8ff18e3b18ff98fca5458e44fe2d09f
Branch: v7.0
https://github.com/mongodb/mongo/commit/3f028290e9aa434b79e4eb7806f73d3f2a9bd939

Comment by Githook User [ 18/Jan/24 ]

Author:

{'name': 'Peter Volk', 'email': 'peter.volk@mongodb.com', 'username': 'HCSPete'}

Message: SERVER-83119 Qualify a ClusteredIndexscan as an allowed operation when notablescan is set
Branch: v7.2
https://github.com/mongodb/mongo/commit/76530ad3f56f3170c25e67252c5ad4fae8ce0dc5

Comment by Githook User [ 11/Jan/24 ]

Author:

{'name': 'Peter Volk', 'email': '77723508+HCSPete@users.noreply.github.com', 'username': 'HCSPete'}

Message: SERVER-83119 Qualify a ClusteredIndexscan as an allowed operation when notablescan is set. (#17342)

GitOrigin-RevId: 0556bfee1e398617dca5703e8eb75487bef23f3e
Branch: master
https://github.com/mongodb/mongo/commit/4f11366f066df179b529174f099db6b8e3a528b0

Comment by Chris Hutchinson [ 17/Nov/23 ]

bernard.gorman@mongodb.com steve.tarzia@mongodb.com Reassigning this bug to QO - sounds like we need to relax the query planner so that it will produce a bounded clustered collection scan even when. notablescan is enabled. cc david.storch@mongodb.com 

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