[SERVER-27722] Write tests for mixVersion, upgrade/dowgrade scenario for logical clock Created: 17/Jan/17  Updated: 06/Dec/17  Resolved: 23/Jun/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.5.1
Fix Version/s: 3.5.10

Type: Task Priority: Major - P3
Reporter: Randolph Tan Assignee: Jack Mulrow
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Sharding 2017-06-19, Sharding 2017-07-10
Participants:

 Description   

The mongo config server should not enable key generation until the featureCompatibilityVersion = 3.6 is set
The mongo should not write to oplog until featureCompatibilityVersion = 3.6 is set. For the sharded cluster the featureCompatibilityVersion is sent to mongos and it in turn send it to config servers and shards.

The existing multiversion test suite. https://github.com/mongodb/mongo/blob/master/jstests/multiVersion/upgrade_cluster.js
starts with last-stable binary = 3.4 and upgrades it to the latest = current master.

upgrade order is
config servers
shards
mongos

need to add a test case where
once the config servers are upgraded it verifies that

  • config returns dummy signed $logicalTime and operation time
  • mongod and mongos ignore afterClusterTime that can be sent by mongo shell

once mongod is upgraded

  • mongod returns dummy signed $logicalTime and operation time
  • mongod and mongos ignore afterClusterTime that can be sent by mongo shell

once mongos are upgraded and

  • mongod and mongos returns dummy signed $logicalTime and operation time
  • mongod and mongos ignore afterClusterTime that can be sent by mongo shell

once featureCompatibilityVersion = 3.6 is set

  • mongos and mongod correctly process causally consistent requests

the downgrade should check this in reverse.



 Comments   
Comment by Githook User [ 23/Jun/17 ]

Author:

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

Message: SERVER-27722 write tests for upgrade/downgrade scenario for logical clock
Branch: master
https://github.com/mongodb/mongo/commit/063f30fab53d4a15d5c680337ae168fb1efe9530

Comment by Misha Tyulenev [ 12/Jun/17 ]

jack.mulrow yes implementing this scenario is required but can be split off into a separate jira that we can address later

Comment by Jack Mulrow [ 12/Jun/17 ]

misha.tyulenev
1. I meant the scenario described at the bottom of this ticket, where one of the config servers might say it's replicated after an initial sync without copying the admin.system.keys collection
2. Got it. Thanks!

Comment by Misha Tyulenev [ 12/Jun/17 ]

jack.mulrow here are the clarifications:
1. please clarify what is the "test csrs scenario" .
2. it means that it should not add a "wall" field to the oplog entries https://github.com/mongodb/mongo/commit/a85685ce5ed0e07107476e1f4098034452cf7d6a

Comment by Jack Mulrow [ 12/Jun/17 ]

misha.tyulenev couple questions:

  • It looks like there isn't a test for downgrading a sharded cluster, is it worth making a new one? Or is it enough to just test the csrs scenario?
  • What exactly does it mean that "mongo should not write to the oplog"? Is that just the appendOplogNote command in makeNoopWriteIfNeeded? Or something else?
Comment by Randolph Tan [ 09/Jun/17 ]

The ticket looks good to me. We have to double check the downgrade procedure: It might involve sending featureCompatibilityVersion to 3.4.

Comment by Misha Tyulenev [ 08/Jun/17 ]

renctan could you please take a look and lmk the feedback? Thanks!

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