[SERVER-20260] New indexes should bump their Collection's minimum SnapshotName Created: 02/Sep/15  Updated: 23/Feb/18  Resolved: 17/Sep/15

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 3.1.7
Fix Version/s: 3.1.9

Type: Bug Priority: Major - P3
Reporter: Michael Grundy Assignee: Mathias Stearn
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File readmajoritycounthint.js    
Issue Links:
Duplicate
is duplicated by SERVER-20261 Planner unable to find index for $geo... Closed
Related
related to SERVER-19212 New indexes shouldn't be usable until... Closed
related to SERVER-20439 Use OpTimes as SnapshotNames Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

jstest attached.

Sprint: Quint 9 09/18/15
Participants:

 Description   

This is a temporary solution to ensure that indexes created with w:majority are guaranteed to be usable to a read using majority readConcern level. Currently w:majority only waits for the OpTime and does not wait for the SnapshotName set on the Client. This means that it is possible for an index to be in the committed snapshot but not usable to queries since they are using a too old SnapshotName. The changes for this ticket will be made unnessesary once we complete the work of reunifying OpTime and SnapshotName for SERVER-20439.

Original title: Running count with readConcern majority and a hint errors

Original description:
When running a count with a hint and readConcern majority, the command fails with planner returned bad hint.

Here is the dbCommand object:

{
        "count" : "jstests_hint1",
        "query" : { 
            "live" : true,
            "ts" : { 
                "$lt" : ISODate("2009-02-08T18:55:08.272Z")
            },  
            "cls" : "entry",
            "verticals" : "alleyinsider"
        },  
        "hint" : { 
            "ts" : 1 
        },  
        "fields" : { 
        },  
        "readConcern" : { 
            "level" : "majority"
        }   
    }

And the log output with the error.

m31000| 2015-09-02T11:14:05.543-0400 I COMMAND  [conn1] command test.jstests_hint1 command: count { count: "jstests_hint1", query: { live: true, ts: { $lt: new Date(1234119308272) }, cls: "entry", verticals: "alleyinsider" }, hint: { ts: 1.0 }, fields: {}, readConcern: { level: "majority" } } ntoreturn:1 ntoskip:0 keyUpdates:0 writeConflicts:0 numYields:0 reslen:273 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_command 1919ms
{
	"waitedMS" : NumberLong(945),
	"ok" : 0,
	"errmsg" : "error processing query: ns=test.jstests_hint1Tree: $and\n    cls == \"entry\"\n    live == true\n    verticals == \"alleyinsider\"\n    ts $lt new Date(1234119308272)\nSort: {}\nProj: {}\n planner returned error: bad hint",
	"code" : 2
}



 Comments   
Comment by Githook User [ 17/Sep/15 ]

Author:

{u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}

Message: SERVER-20260 New indexes should bump their Collection's minimum SnapshotName

This is a temporary solution to ensure that indexes created with w:majority
are guaranteed to be usable to a read using majority readConcern level. These
changes will be made undone once we complete the work of reunifying OpTime and
SnapshotName for SERVER-20439.
Branch: master
https://github.com/mongodb/mongo/commit/480df0c4376f5faa572ba031e53483f071cf1423

Comment by Eric Milkie [ 15/Sep/15 ]

Why didn't SERVER-19212 fix this issue?

Comment by Mathias Stearn [ 15/Sep/15 ]

Unfortunately, even on a single local node, w:majority only waits for the OpTime since the SnapshotName is stripped off before calling into the ReplicationCoordinator::awaitReplication(). Currently the only way to wait for both is to call ReplicationCoordinator::awaitReplicationOfLastOpForClient(), but that is only used by the RangeDeleter, not any user-initiated w:majority actions.

Comment by Eric Milkie [ 15/Sep/15 ]

I'm not sure the attached jstests is representative of the problem as described; it doesn't use sharding or mongos.

Comment by Mathias Stearn [ 11/Sep/15 ]

Replaced title and description with plan of action.

Comment by Eric Milkie [ 02/Sep/15 ]

redbeard0531 Sounds plausible.

Comment by Mathias Stearn [ 02/Sep/15 ]

milkie I think when we reserve a SnapshotName we need to add that to the Clients ReplInfo so it knows to wait for it.

Comment by Michael Grundy [ 02/Sep/15 ]

Adding w:majority to the index build didn't fix it. Is it possible that w:majority on an index build isn't working? If I toss a sleep in, it will pass.

Comment by Eric Milkie [ 02/Sep/15 ]

For this, does it fix the test if you do w:majority on the index build? Otherwise, it won't wait long enough for the index build to be present in the read level majority snapshot, so you would get "bad hint" since it doesn't see the index you specified.

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