Practices and precautions for upgrading and downgrading primary and secondary nodes in the mongodb replica set

Practices and precautions for upgrading and downgrading primary and secondary nodes in the mongodb replica set
Considerations and practices for upgrading and downgrading primary and secondary nodes in the mongodb replica set

• This article is based on the storage resizing record of mongodb3.0.7 to explain the Complete upgrade process;

• Solve the problems left over from above

  The reason for the last downgrade back to 3.0 is that the mongodb driver of some applications is too low and does not support mongodb3.4. Before this upgrade, we checked the drivers of all applications and performed the upgrade and passed the compatibility test.

Example:

Assume that there is a replica set consisting of a primary and three sencondary.

primary：10.0.1.32secondary：10.0.1.31 、10.0.1.33、192.168.1.230

Rs. status () display

rs.status(){    ......        "members" : [        {            "_id" : 0,            "name" : "10.0.1.31:27017",            "health" : 1,            "state" : 1,            "stateStr" : "SECONDARY",            ......        },        {            "_id" : 1,            "name" : "10.0.1.32:27017",            "health" : 1,            "state" : 5,            "stateStr" : "PRIMARY",            ......        },        {            "_id" : 2,            "name" : "192.168.1.230:27017",            "health" : 1,            "state" : 5,            "stateStr" : "SECONDARY",            ......        },        {            "_id" : 3,            "name" : "10.0.1.33:27017",            "health" : 1,            "state" : 2,            "stateStr" : "SECONDARY",            ......        }    ],    "ok" : 1}

Switch target: 31 to primary, 32 to secondary

primary：10.0.1.31secondary：10.0.1.32 、10.0.1.33、192.168.1.230

Switch steps (all executed on mongodb shell)

• 1. Set the priority of each node on primary

cfg = rs.conf()cfg.members[0].priority = 1cfg.members[1].priority = 0.5cfg.members[2].priority = 0.5cfg.members[3].priority = 0.5rs.reconfig(cfg)

• 2. Execute the rs. freeze (230) command on nodes 33 and 120 to organize them to become the primary node within 120 seconds.

rs.freeze(120) 

• 3. Run the downgrade command on primary to make it no longer a primary in 120 seconds.

rs.stepDown(120)

• 4. Observe the 31 nodes and find that they have become primary.

rs.status(){    ......        "members" : [        {            "_id" : 0,            "name" : "10.0.1.31:27017",            "health" : 1,            "state" : 1,            "stateStr" : "PRIMARY",            ......        },        {            "_id" : 1,            "name" : "10.0.1.32:27017",            "health" : 1,            "state" : 5,            "stateStr" : "SECONDARY",            ......        },        {            "_id" : 2,            "name" : "192.168.1.230:27017",            "health" : 1,            "state" : 5,            "stateStr" : "SECONDARY",            ......        },        {            "_id" : 3,            "name" : "10.0.1.33:27017",            "health" : 1,            "state" : 2,            "stateStr" : "SECONDARY",            ......        }    ],    "ok" : 1}

• 5. Upgrade 32-node mongodb to version 3.4.

  Detailed procedures mongodb3.0.7 resizing storage records

• 6. Add the 32 nodes to the replica set again.

  Copy the set configuration file from node 31, modify bindip to local 32, save and exit, and execute systemctl start mongod.

Notes

• To set the priority, you must first do so. Otherwise, after the primary release stepDown, the primary of each node is not necessarily the expected node.
• Prepare the commands and execution sequence of each host in advance, open a shell window for each node, and paste the prepared commands in order for execution.
• After the upgrade and downgrade are completed, the applications connected to mongodb need to restart the connection to the new primary. This command must be prepared in advance.