[SERVER-28892] Test Causal Consistency in shell Created: 20/Apr/17  Updated: 30/Oct/23  Resolved: 04/May/17

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

Type: Task Priority: Major - P3
Reporter: Misha Tyulenev Assignee: Jack Mulrow
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Sharding 2017-05-08, Sharding 2017-05-29
Participants:

 Description   

Use ShardingTest to verify that CausalConsistency is supported by shell

  • add negative tests verifying that causal consistency is enabled for the commands mentioned in SERVER-28869

    // start a shard that could use read majority
    var st = new ShardingTest({shards:1, mongos:1, rs: {nodes:1, enableMajorityReadConcern: ""}}
     
    // once its started enable causal consistency
    db.setMongo().setCausalConsistency();
     
    // check its enabled using 
    assert.eq(db.getMongo().getCausalConsistency(), true)
     
    // check its enabled for a command (find, aggregate, count etc ) using 
    db.getMongo().isCausalConsistencyEnabled(cmdName) {}
    
    

  • add negative tests verifying that causal consistency is not enabled when its not explicitly set or for commands not in the list
  • add tests that check that commands work as (using find as an example):

     
    // make sure that operation time is not set 
    assert.isnull(mongo.getOperationTime(), ...)
     
    // make sure that cluster time is not set 
    assert.isnull(mongo.getClusterTime(), ...)
     
    db.runCommand({find:'foo'})
    // make sure that operation time is still not set 
    // make sure that cluster time is set 
     
     
    db.runCommand({insert:'foo', documents:[{x: 1}]})
    // now both cluster and operation time are set
    const time = mongo.getOperationTime()
     
    // increase operation time to one day ahead and run a command
    const time = mongo.setOperationTime(increasedTime)
    db.runCommand({find:'foo'})
    // now it should fail with "Operation time can not be greater than cluster time" error
     
    // use the logical time returned as a new operation time and run the read 
    // the result should match the write and returned operation time must be >= passed operation time
    



 Comments   
Comment by Githook User [ 04/May/17 ]

Author:

{u'username': u'jsmulrow', u'name': u'Jack Mulrow', u'email': u'jack.mulrow@mongodb.com'}

Message: SERVER-28892 Test causal consistency in the shell
Branch: master
https://github.com/mongodb/mongo/commit/aa10fc48720dc915d106bfb14a8c9bc391f10fe6

Comment by Jack Mulrow [ 03/May/17 ]

max.hirschhorn Oh ok that makes sense. I'll do that and then there won't be any need for manually setting logical times.

Comment by Max Hirschhorn [ 03/May/17 ]

As for your second comment, this ticket is for testing that the methods added to the Mongo object by SERVER-28450, work as expected when _isCausal is true, so I can't put readConcern: {afterClusterTime: ... in the initial command because the test is making sure the shell adds it automatically for the commands enabled in SERVER-28869.

jack.mulrow, my point is that you can breaking up the behavior you're testing to (1) verify that the mongo shell forwards the operation time for all relevant commands and updates it based on the server's response, and (2) verify the server rejects the command when the operation time is invalid. The mongo shell doesn't have a notion of whether its operation time is valid (i.e. only the server does), so you don't get any benefit for testing #2 by modifying _operationTime directly rather than just running the command with an explicit "afterClusterTime" option.

Comment by Jack Mulrow [ 03/May/17 ]

max.hirschhorn I'm fine with updating _operationTime and _clusterTime directly, I just wasn't sure if that was a best practice. So I won't add new methods then, I'll just update those properties directly.

As for your second comment, this ticket is for testing that the methods added to the Mongo object by SERVER-28450, work as expected when _isCausal is true, so I can't put readConcern: {afterClusterTime: ... in the initial command because the test is making sure the shell adds it automatically for the commands enabled in SERVER-28869.

Thanks!

Comment by Misha Tyulenev [ 27/Apr/17 ]

max.hirschhorn its a good point, as we discussed offline - this can be split in 2 pieces:
1. testing dbclient_rs ability to propagate the operation time implicitly can be done in tests that use mongos connected to RS.
2. keeping track of operationTime in shell - this is what the current test will be doing.

Comment by Max Hirschhorn [ 25/Apr/17 ]

misha.tyulenev, in addition to the test cases you've described, I think it would also be good to also test that the operation time for Mongo object initialized using a replica set connection string (e.g. the return value of ReplSetTest.prototype.getURL()) is forwarded from the primary's response to the secondary.

Comment by Misha Tyulenev [ 21/Apr/17 ]

CC jack.mulrow

Comment by Misha Tyulenev [ 20/Apr/17 ]

max.hirschhorn here is an outline of the test case for the API - as a reviewer of this test could you please take a look and ack the general concept leaving the details to the actual CR?

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