Lab - Read Preference

I was marked incorrect for this question for an answer that, according to the code pasted, is correct. Can someone explain why? Thanks in advance.

2018-10-24T18:55:48.369+0000 I CONTROL [initandlisten]
MongoDB Enterprise m103-repl:SECONDARY> rs.status()
{
“set” : “m103-repl”,
“date” : ISODate(“2018-10-24T18:56:01.692Z”),
“myState” : 2,
“term” : NumberLong(3),
“syncingTo” : “”,
“syncSourceHost” : “”,
“syncSourceId” : -1,
“heartbeatIntervalMillis” : NumberLong(2000),
“optimes” : {
“lastCommittedOpTime” : {
“ts” : Timestamp(0, 0),
“t” : NumberLong(-1)
},
“appliedOpTime” : {
“ts” : Timestamp(1540357658, 1),
“t” : NumberLong(3)
},
“durableOpTime” : {
“ts” : Timestamp(1540357658, 1),
“t” : NumberLong(3)
}
},
“lastStableCheckpointTimestamp” : Timestamp(1540357652, 1),
“members” : [
{
“_id” : 0,
“name” : “192.168.103.100:27001”,
“health” : 0,
“state” : 8,
“stateStr” : “(not reachable/healthy)”,
“uptime” : 0,
“optime” : {
“ts” : Timestamp(0, 0),
“t” : NumberLong(-1)
},
“optimeDurable” : {
“ts” : Timestamp(0, 0),
“t” : NumberLong(-1)
},
“optimeDate” : ISODate(“1970-01-01T00:00:00Z”),
“optimeDurableDate” : ISODate(“1970-01-01T00:00:00Z”),
“lastHeartbeat” : ISODate(“2018-10-24T18:56:01.569Z”),
“lastHeartbeatRecv” : ISODate(“1970-01-01T00:00:00Z”),
“pingMs” : NumberLong(0),
“lastHeartbeatMessage” : “Error connecting to 192.168.103.100:27001 :: caused by :: Connection r
efused”,
“syncingTo” : “”,
“syncSourceHost” : “”,
“syncSourceId” : -1,
“infoMessage” : “”,
“configVersion” : -1
},
{
“_id” : 2,
“name” : “m103:27002”,
“health” : 0,
“state” : 8,
“stateStr” : “(not reachable/healthy)”,
“uptime” : 0,
“optime” : {
“ts” : Timestamp(0, 0),
“t” : NumberLong(-1)
},
“optimeDurable” : {
“ts” : Timestamp(0, 0),
“t” : NumberLong(-1)
},
“optimeDate” : ISODate(“1970-01-01T00:00:00Z”),
“optimeDurableDate” : ISODate(“1970-01-01T00:00:00Z”),
“lastHeartbeat” : ISODate(“2018-10-24T18:56:01.587Z”),
“lastHeartbeatRecv” : ISODate(“1970-01-01T00:00:00Z”),
“pingMs” : NumberLong(0),
“lastHeartbeatMessage” : “Error connecting to m103:27002 (192.168.103.100:27002) :: caused by ::
Connection refused”,
“syncingTo” : “”,
“syncSourceHost” : “”,
“syncSourceId” : -1,
“infoMessage” : “”,
“configVersion” : -1
},
{
“_id” : 3,
“name” : “m103:27003”,
“health” : 1,
“state” : 2,
“stateStr” : “SECONDARY”,
“uptime” : 14,
“optime” : {
“ts” : Timestamp(1540357658, 1),
“t” : NumberLong(3)
},
“optimeDate” : ISODate(“2018-10-24T05:07:38Z”),
“syncingTo” : “”,
“syncSourceHost” : “”,
“syncSourceId” : -1,
“infoMessage” : “”,
“configVersion” : 41088,
“self” : true,
“lastHeartbeatMessage” : “”
}
],
“ok” : 1,
“operationTime” : Timestamp(1540357658, 1),
“$clusterTime” : {
“clusterTime” : Timestamp(1540357658, 1),
“signature” : {
“hash” : BinData(0,“6bMfu4jfWQ2tqlltKegW9IDNs4o=”),
“keyId” : NumberLong(“6615675745370898433”)
}
}
}
MongoDB Enterprise m103-repl:SECONDARY> use admin
switched to db admin
.
.
MongoDB Enterprise m103-repl:SECONDARY> rs.initiate()
{
“operationTime” : Timestamp(1540357658, 1),
“ok” : 0,
“errmsg” : “already initialized”,
“code” : 23,
“codeName” : “AlreadyInitialized”,
“$clusterTime” : {
“clusterTime” : Timestamp(1540357658, 1),
“signature” : {
“hash” : BinData(0,“6bMfu4jfWQ2tqlltKegW9IDNs4o=”),
“keyId” : NumberLong(“6615675745370898433”)
}
}
}
.
.
MongoDB Enterprise m103-repl:SECONDARY> cfg = rs.conf()
{
“_id” : “m103-repl”,
“version” : 41088,
“protocolVersion” : NumberLong(1),
“writeConcernMajorityJournalDefault” : true,
“members” : [
{
“_id” : 0,
“host” : “192.168.103.100:27001”,
“arbiterOnly” : false,
“buildIndexes” : true,
“hidden” : false,
“priority” : 1,
“tags” : {

                    },
                    "slaveDelay" : NumberLong(0),
                    "votes" : 1
            },
            {
                    "_id" : 2,
                    "host" : "m103:27002",
                    "arbiterOnly" : false,
                    "buildIndexes" : true,
                    "hidden" : false,
                    "priority" : 1,
                    "tags" : {

                    },
                    "slaveDelay" : NumberLong(0),
                    "votes" : 1
            },
            {
                    "_id" : 3,
                    "host" : "m103:27003",
                    "arbiterOnly" : false,
                    "buildIndexes" : true,
                    "hidden" : false,
                    "priority" : 2,
                    "tags" : {

                    },
                    "slaveDelay" : NumberLong(0),
                    "votes" : 1
            }
    ],
    "settings" : {
            "chainingAllowed" : true,
            "heartbeatIntervalMillis" : 2000,
            "heartbeatTimeoutSecs" : 10,
            "electionTimeoutMillis" : 10000,
            "catchUpTimeoutMillis" : -1,
            "catchUpTakeoverDelayMillis" : 30000,
            "getLastErrorModes" : {

            },
            "getLastErrorDefaults" : {
                    "w" : 1,
                    "wtimeout" : 0
            },
            "replicaSetId" : ObjectId("5bcf9a08e9eae220e2a8b0d4")
    }

}
MongoDB Enterprise m103-repl:SECONDARY> cfg.members=[cfg.members[2]]
[
{
“_id” : 3,
“host” : “m103:27003”,
“arbiterOnly” : false,
“buildIndexes” : true,
“hidden” : false,
“priority” : 2,
“tags” : {

            },
            "slaveDelay" : NumberLong(0),
            "votes" : 1
    }

]
MongoDB Enterprise m103-repl:SECONDARY> rs.reconfig(cfg,{force:true})
{
“ok” : 1,
“operationTime” : Timestamp(1540357658, 1),
“$clusterTime” : {
“clusterTime” : Timestamp(1540357658, 1),
“signature” : {
“hash” : BinData(0,“6bMfu4jfWQ2tqlltKegW9IDNs4o=”),
“keyId” : NumberLong(“6615675745370898433”)
}
}
}
MongoDB Enterprise m103-repl:PRIMARY> use products
MongoDB Enterprise m103-repl:PRIMARY> db.products.find({“name”:“Ebonyhill - CD”}).readPref(“primary”)
{ “_id” : ObjectId(“573f7197f29313caab89b288”), “sku” : 20001104, “name” : “Ebonyhill - CD”, “type” : “Music”, “regularP
rice” : 14.99, “salePrice” : 14.99, “shippingWeight” : “0.25” }
MongoDB Enterprise m103-repl:PRIMARY> db.products.find({“name”:“Ebonyhill - CD”}).readPref(“primaryPreferred”)
{ “_id” : ObjectId(“573f7197f29313caab89b288”), “sku” : 20001104, “name” : “Ebonyhill - CD”, “type” : “Music”, “regularP
rice” : 14.99, “salePrice” : 14.99, “shippingWeight” : “0.25” }
MongoDB Enterprise m103-repl:PRIMARY> db.products.find({“name”:“Ebonyhill - CD”}).readPref(“nearest”)
{ “_id” : ObjectId(“573f7197f29313caab89b288”), “sku” : 20001104, “name” : “Ebonyhill - CD”, “type” : “Music”, “regularP
rice” : 14.99, “salePrice” : 14.99, “shippingWeight” : “0.25” }
MongoDB Enterprise m103-repl:PRIMARY> db.products.find({“name”:“Ebonyhill - CD”}).readPref(“secondaryPreferred”)
{ “_id” : ObjectId(“573f7197f29313caab89b288”), “sku” : 20001104, “name” : “Ebonyhill - CD”, “type” : “Music”, “regularP
rice” : 14.99, “salePrice” : 14.99, “shippingWeight” : “0.25” }
MongoDB Enterprise m103-repl:PRIMARY> db.products.find({“name”:“Ebonyhill - CD”}).readPref(“secondary”)
{ “_id” : ObjectId(“573f7197f29313caab89b288”), “sku” : 20001104, “name” : “Ebonyhill - CD”, “type” : “Music”, “regularP
rice” : 14.99, “salePrice” : 14.99, “shippingWeight” : “0.25” }
MongoDB Enterprise m103-repl:PRIMARY> db.products.find({“name”:“Ebonyhill - CD”}).readPref(“fish”)
Error: error: {
“operationTime” : Timestamp(1540410896, 1),
“ok” : 0,
“errmsg” : “Could not parse $readPreference mode ‘fish’. Only the modes ‘primary’, ‘primaryPreferred’, secondary
', ‘secondaryPreferred’, and ‘nearest’ are supported.”,
“code” : 9,
“codeName” : “FailedToParse”,
“$clusterTime” : {
“clusterTime” : Timestamp(1540410896, 1),
“signature” : {
“hash” : BinData(0,“4jqT5lRCJt2UZ0hf6hTaGJuXY04=”),
“keyId” : NumberLong(“6615675745370898433”)
}
}
}
MongoDB Enterprise m103-repl:PRIMARY>

odd, your replica set have no primary node, why your code shows " MongoDB Enterprise m103-repl:PRIMARY>"?
It seems like you do “rs.reconfig(cfg,{force:true})” effect your result

Perhaps, however the question says shutdown two nodes. So, you could shut down two secondaries and be left with a primary, or shutdown a primary and secondary and force election, which resulted in the answer I got.

Isn’t it that if you shutdown 2 secondary nodes in a 3 node cluster, the primary node automatically steps down to become a secondary? Or like you said, if you shut down the primary and secondary , you are left with just a secondary. This secondary can never become elected to be primary because there is no more majority (2 out of 3 ) because 2 nodes are down.

The question says to shut down two nodes. It does not say leave a secondary and use that. I used a primary node for the question.

You can change a secondary to a primary in this case.

I just read this.

There is a misunderstanding in the process here.

The lab does say to shut down two nodes. It doesn’t make any difference how you do this. Once the cluster is down to one node, if the node that is still online is the original primary, it steps down until there is at the amount of nodes present to ensure there isn’t a deadlock when an election takes place (hence the minimum of 3 nodes for a replica set(unless there is a hidden or arbiter)). So. I think the point of the lab is that there will not be a primary.

I also got this question wrong, when you forced it to become a primary, your lab will show bad results. When a cluster fails to one node, the online node automatically becomes a secondary, so… all reads except primary will work on the server. That is the point of the lab. (I also blew the pooch on this one. LOL) I hope this helps answer your question.

1 Like

I get it now, makes sense.

Thanks everyone for your replies.