Mongodb read data from secondary hidden replicaset

mongodb

We have a mongo cluster (3 member replica set) with two replicaset names (rs0 and rs1). We also enabled balancing and our data is splitted in both replicaset. In both replica set we have add a new replica member as hidden. Please find the hidden response below,

{
    "_id" : 3,
    "host" : "server1-replica-3:27018",
    "arbiterOnly" : false,
    "buildIndexes" : true,
    "hidden" : true,
    "priority" : 0,
    "tags" : {
            "dc" : "east",
            "use" : "reporting"
    },
    "slaveDelay" : NumberLong(0),
    "votes" : 1
}

For a reporting purpose we need to connect both hidden servers (since our data is splitted into both replica sets) via router, so that live data cannot affect with the activities we done for repoting. For this we have tried the below commands to connect the hidden servers, but no luck.

Commands we tried:

  1. With multiple replicaset hidden members:

    /usr/local/mongo/bin/mongo mongodb://server1-replica-3:27018,server2-replica-3:27018/databasename?replicaSet=rs0,rs1&w=0&readPreference=secondary&maxPoolSize=50

  2. With read preference secondary

    /usr/local/mongo/bin/mongo mongodb://localhost:27017/?readPreference=secondary

  3. Enabled tagging for both hidden servers and tried the below commands:

    /usr/local/mongo/bin/mongo mongodb://localhost:27017/?readPreference=secondary&readPreferenceTags=dc:east,use:reporting
/usr/local/mongo/bin/mongo mongodb://server1-replica-3:27018,server2-replica-3:27018/databasename?replicaSet=rs0,rs1readPreference=secondary&readPreferenceTags=dc:east,use:reporting

Can anyone please help us with the steps to connect hidden replicaset members from both replicaset?

Best Answer

Hidden replica set members are invisible to client applications via replica set or mongos connections so all three of your examples are working as designed.

As per the documentation on Hidden Replica Set Members:

Clients will not distribute reads with the appropriate read preference to hidden members. As a result, these members receive no traffic other than basic replication. Use hidden members for dedicated tasks such as reporting and backups. Delayed members should be hidden.

In a sharded cluster, mongos do not interact with hidden members.

You can only connect to a hidden member directly (i.e. by specifying a single hostname and port). Read preferences and tags are ignored for direct connections.

For example, any of the following should work assuming server1-replica-3 is a resolvable hostname and you aren't blocked by firewall configuration:

 mongo server1-replica-3:27018
 mongo --host server1-replica-3 --port 27018
 mongo mongodb://server1-replica-3:27018

If you have a sharded cluster with multiple hidden members, you can only read from one hidden member at a time via a direct connection. Note that bypassing mongos with a direct connection to a hidden secondary may return stale or orphaned data for a sharded collection.

If you want to dedicate nodes for specific read use cases in a sharded cluster, instead of making these hidden you should use secondary read preferences with replica tag sets. Be aware that reading from secondaries may return stale, duplicate, or orphaned data for a sharded collection as at MongoDB 3.4. For more background, see SERVER-5931: secondary reads in sharded clusters need stronger consistency. An improvement for SERVER-5931 was recently committed to the MongoDB 3.5 development branch, so secondary reads in sharded clusters should be safer in the MongoDB 3.6 production release (expected later this year).

Related Question