0

I am newbie with MongoDB and even more in administration of databases. But my boss passed me an issue to solve.

SCENARIO

I have two servers using MongoDB and ReplicaSet, when I run the command

db.adminCommand( { replSetGetStatus : 1 } )

on the primary server I get the result below:

{
    ...
    "date" : ISODate("2018-12-17T10:39:00.247Z"),
    "myState" : 1,
    ...
}

and on the secondary server I get the result below:

{
    ...
    "date" : ISODate("2018-12-17T10:39:00.247Z"),
    "myState" : 2,
    ...
}

as expected.

QUESTIONS

  1. If I stop the network interface (eth0) of the primary server to activate ReplicaSet, should the myStatus attribute of the secondary server change to 1?
  2. If the status is to change, I have already tested it and it is not changing. How do I know that the secondary has become primary?
1

If I stop the network interface (eth0) of the primary server to activate ReplicaSet, should the myStatus attribute of the secondary server change to 1?

As per MongoDB documentation here

rs.stepDown()

Or

rs.stepDown(stepDownSecs, secondaryCatchUpPeriodSecs)

Instructs the primary of the replica set to become a secondary. After the primary steps down, eligble secondaries will hold an election for primary.

The method does not immediately step down the primary. If no electable secondaries are up to date with the primary, the primary waits up to secondaryCatchUpPeriodSecs (by default 10 seconds) for a secondary to catch up. Once an electable secondary is available, the method steps down the primary.

Note: All writes to the primary fail during the period starting when the rs.stepDown() method is received until either a new primary is elected, or if there are no electable secondaries, the original primary resumes normal operation. The time period where writes fail is at maximum: secondaryCatchUpPeriodSecs (10s by default) + electionTimeoutMillis (10s by default).

If the status is to change, I have already tested it and it is not changing. How do I know that the secondary has become primary?

As per MongoDB documentation rs.status() This output reflects the current status of the replica set, using data derived from the heartbeat packets sent by the other members of the replica set.

Starting in MongoDB 3.4, the replSetGetStatus command can accept the optional initialSync: 1 to report on initial sync status and progress if the command is run on the secondary. To report on initial sync for the secondary, you must run the command instead of the helper.

db.adminCommand( { replSetGetStatus : 1 } )

For example

The command returns the following output for an example replica set primary:

{
   "set" : "replset",
   "date" : ISODate("2018-12-06T18:34:41.288Z"),
   "myState" : 1,
   "term" : NumberLong(1),
   "syncingTo" : "",
   "syncSourceHost" : "",
   "syncSourceId" : -1,
   "heartbeatIntervalMillis" : NumberLong(2000),
   "optimes" : {
      "lastCommittedOpTime" : {
         "ts" : Timestamp(1544121271, 1),
         "t" : NumberLong(1)
      },
      "readConcernMajorityOpTime" : {
         "ts" : Timestamp(1544121271, 1),
         "t" : NumberLong(1)
      },
      "appliedOpTime" : {
         "ts" : Timestamp(1544121271, 1),
         "t" : NumberLong(1)
      },
      "durableOpTime" : {
         "ts" : Timestamp(1544121271, 1),
         "t" : NumberLong(1)
      }
   },
   "lastStableCheckpointTimestamp" : Timestamp(1544121271, 1),
   "members" : [
         {
            "_id" : 0,
            "name" : "m1.example.net:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 85,
            "optime" : {
               "ts" : Timestamp(1544121271, 1),
               "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2018-12-06T18:34:31Z"),
            "syncingTo" : "",
            "syncSourceHost" : "",
            "syncSourceId" : -1,
            "infoMessage" : "could not find member to sync from",
            "electionTime" : Timestamp(1544121209, 1),
            "electionDate" : ISODate("2018-12-06T18:33:29Z"),
            "configVersion" : 1,
            "self" : true,
            "lastHeartbeatMessage" : ""
         },
         {
            "_id" : 1,
            "name" : "m2.example.net:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 81,
            "optime" : {
               "ts" : Timestamp(1544121271, 1),
               "t" : NumberLong(1)
            },
            "optimeDurable" : {
               "ts" : Timestamp(1544121271, 1),
               "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2018-12-06T18:34:31Z"),
            "optimeDurableDate" : ISODate("2018-12-06T18:34:31Z"),
            "lastHeartbeat" : ISODate("2018-12-06T18:34:39.866Z"),
            "lastHeartbeatRecv" : ISODate("2018-12-06T18:34:41.118Z"),
            "pingMs" : NumberLong(0),
            "lastHeartbeatMessage" : "",
            "syncingTo" : "m1.example.net:27017",
            "syncSourceHost" : "m1.example.net:27017",
            "syncSourceId" : 0,
            "infoMessage" : "",
            "configVersion" : 1
         },
         {
            "_id" : 2,
            "name" : "m3.example.net:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 12,
            "optime" : {
               "ts" : Timestamp(1544121271, 1),
               "t" : NumberLong(1)
            },
            "optimeDurable" : {
               "ts" : Timestamp(1544121271, 1),
               "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2018-12-06T18:34:31Z"),
            "optimeDurableDate" : ISODate("2018-12-06T18:34:31Z"),
            "lastHeartbeat" : ISODate("2018-12-06T18:34:40.934Z"),
            "lastHeartbeatRecv" : ISODate("2018-12-06T18:34:40.740Z"),
            "pingMs" : NumberLong(0),
            "lastHeartbeatMessage" : "",
            "syncingTo" : "m2.example.net:27017",
            "syncSourceHost" : "m2.example.net:27017",
            "syncSourceId" : 1,
            "infoMessage" : "",
            "configVersion" : 1
         }
      ],
   "ok" : 1,
   "$clusterTime" : {
      "clusterTime" : Timestamp(1526229410, 1),
      "signature" : {
         "hash" : BinData(0,"WE7yaBuLazOtqwdJxaroLp1Kluo="),
         "keyId" : NumberLong("6554495980643811329")
      }
   },
   "operationTime" : Timestamp(1526229410, 1),
}
1

If I stop the network interface (eth0) of the primary server to activate ReplicaSet, should the myState attribute of the secondary server change to 1?

Since you only have two voting members in your replica set, the strict majority of voting members required to elect or maintain a primary (n/2 + 1) is 2.

You should expect that if either member is unavailable, there will be no primary: a two member replica set does not provide automatic fault tolerance.

If the status is to change, I have already tested it and it is not changing. How do I know that the secondary has become primary?

The replica set member state changes to reflect the current role of the replica set member. Your surviving secondary cannot become a primary without manual intervention to forcibly reconfigure the replica set. The recommended solution for production deployments is to add a third member to your replica set (ideally another data-bearing member hosted on a third machine) so your deployment can automatically recover from any single member being unavailable.

There are several ways to confirm member state via the mongo shell:

  • The default mongo shell prompt is prefixed with the replica set name and member state of the MongoDB process you are connected to, for example: replset:PRIMARY>. If the member state has changed, hitting <enter> should re-establish a connection and refresh the shell prompt.
  • Check via db.isMaster().primary. This status value should be set to the current host (equivalent to db.isMaster().me) if it is primary.
  • Check the member state in rs.status().myState. A value of 1 indicates the current member has the state PRIMARY.

You can find out more information about the election process by searching for MongoDB log lines with the REPL log component. When you shutdown the primary on your two member replica set, you should see log messages similar to the following on your remaining secondary:

# Checking from a bash shell (note the intentional space after "REPL ")
grep "REPL " mongod.log | tail -1

2018-12-24T12:40:01.894+1100 I REPL     [replexec-2] Not starting an election, since we are not electable due to: Not standing for election because I cannot see a majority

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.