[SERVER-16733] mongos does not fail when different configdb string is used Created: 06/Jan/15  Updated: 15/Jan/15  Resolved: 09/Jan/15

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 2.7.8
Fix Version/s: 2.8.0-rc5

Type: Bug Priority: Blocker - P1
Reporter: Kevin Pulo Assignee: Randolph Tan
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-15375 initShardVersion triggers inline RS r... Closed
related to SERVER-15879 Better error reporting when the mongo... Closed
is related to SERVER-16774 Better enforcement of configdb string... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:
  1. Start a minimal sharded environment, eg:

    mlaunch init --single --sharded 1 --config 3 --mongos 1

    In my case, this has a configdb string of "genique:27019,genique:27020,genique:27021".

  2. Start another mongos with a different configdb string, eg. reorder the config servers, or use FQDNs:

    mongos --port 27022 --configdb genique.local:27019,genique.local:27020,genique.local:27021
    mongos --port 27023 --configdb genique:27021,genique:27020,genique:27019

  3. Connect to the new mongos and write to the config db.

    $ mongo --port 27022 config
    MongoDB shell version: 2.6.6
    connecting to: 127.0.0.1:27022/config
    Server has startup warnings:
    2015-01-06T08:37:44.758+1100 I -
    2015-01-06T08:37:44.758+1100 I -        ** NOTE: This is a development version (2.7.8) of MongoDB.
    2015-01-06T08:37:44.758+1100 I -        **       Not recommended for production.
    2015-01-06T08:37:44.758+1100 I -
    > db.foo.insert({})
    WriteResult({ "nInserted" : 1 })

    This operation should fail, for example, the result with a 2.7.7 mongos is:

    $ mongo --port 27022 config
    MongoDB shell version: 2.6.6
    connecting to: 127.0.0.1:27022/config
    Server has startup warnings:
    2015-01-06T13:07:25.141+1100 I -
    2015-01-06T13:07:25.142+1100 I -        ** NOTE: This is a development version (2.7.7) of MongoDB.
    2015-01-06T13:07:25.142+1100 I -        **       Not recommended for production.
    2015-01-06T13:07:25.142+1100 I -
    > db.foo.insert({})
    WriteResult({
            "writeError" : {
                    "code" : 25,
                    "errmsg" : "could not verify config servers were active and reachable before write"
            }
    })

    (The above uses write commands, but the outcome is the same if legacy mode is used instead.)

Participants:

 Description   

If mongos 2.7.8 or later is started with a configdb string that differs from other mongoses, it can successfully perform writes to the config db. This is possible even if the config servers specified by the mongos are partially or wholly disjoint from the actual/existing config servers. The expected behaviour (and actual behaviour in 2.7.7 and earlier) is that these writes fail (with "could not verify config servers were active and reachable before write").

git bisect confirms that this is a regression caused by SERVER-15375, ie. f67afb4ff33bd803e93e2a52c0249cb872af680b is the breaking commit.

The proximal cause is a failure of the mongos to call setShardVersion (SSV) (with init: true) when it connects to the config servers. This lack of SSV has been verified with logLevel 1 on the config servers. This means that the usual configdb string checking is not performed, and so the mongos is unaware that its configdb string differs from other mongoses.

There should be a jstest to check that a mongos started with a different configdb string is unable to write to the configdb.



 Comments   
Comment by Githook User [ 09/Jan/15 ]

Author:

{u'username': u'renctan', u'name': u'Randolph Tan', u'email': u'randolph@10gen.com'}

Message: SERVER-16733 mongos does not fail when different configdb string is used
Branch: master
https://github.com/mongodb/mongo/commit/bc274534b82eb2328d417dc5b256fb6d66287f74

Comment by Randolph Tan [ 08/Jan/15 ]

This ticket will only fix the regression. A more comprehensive fix will be covered in SERVER-16774.

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