Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-37554

Cannot drop config.system.sessions when calling addShard on 4.0 inMemory cluster

    • Type: Icon: Bug Bug
    • Resolution: Works as Designed
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 4.0.3
    • Component/s: Sharding
    • Labels:
      None
    • Sharding
    • ALL
    • v4.0
    • Hide
      1. Clear out all db directories
      2. Start up 3-node replica set with inMemory storage engine
      3. Initiate the replica set
      4. Start up 3-node csrs
      5. Initiate the csrs
      6. Start up the mongos
      7. Call addShard
      Show
      Clear out all db directories Start up 3-node replica set with inMemory storage engine Initiate the replica set Start up 3-node csrs Initiate the csrs Start up the mongos Call addShard

      I've attached the conf files I used for my sharded cluster. 

      I was running this on 4.0.3-ent. 

      I tried running the csrs with and without inMemory (wasn't sure if it's allowed for csrs) and saw the same behavior both ways. 

      When I try to add the rs as a shard, I get the following:

      MongoDB Enterprise mongos> db.runCommand({"addShard": "rs1/louisamac:5000,louisamac:5001,louisamac:5002", "name": "shard0"})MongoDB Enterprise mongos> db.runCommand({"addShard": "rs1/louisamac:5000,louisamac:5001,louisamac:5002", "name": "shard0"}){ "ok" : 0, "errmsg" : "can't add shard with a local copy of config.system.sessions, please drop this collection from the shard manually and try again. :: caused by :: failed to run command { drop: \"system.sessions\", writeConcern: { w: \"majority\" } } when attempting to add shard rs1/louisamac:5000,louisamac:5001,louisamac:5002 :: caused by :: NetworkInterfaceExceededTimeLimit: timed out", "code" : 96, "codeName" : "OperationFailed", "operationTime" : Timestamp(1539203544, 1), "$clusterTime" : { "clusterTime" : Timestamp(1539203544, 1), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } }} 

       

      When I tried the same repro with wiredTiger, I did not see this issue. 

      Note: I found this while testing, not in a production or customer issue.

      cc kaloian.manassiev esha.maharishi

        1. cs1.conf
          0.3 kB
        2. cs2.conf
          0.3 kB
        3. cs3.conf
          0.3 kB
        4. mongos.conf
          0.2 kB
        5. mongos.log
          7 kB
        6. primary.log
          16 kB
        7. rs1.conf
          0.3 kB
        8. rs2.conf
          0.3 kB
        9. rs3.conf
          0.3 kB

            Assignee:
            backlog-server-sharding [DO NOT USE] Backlog - Sharding Team
            Reporter:
            louisa.berger@mongodb.com Louisa Berger
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: