Stop Replica Set Mongodb

Stop Replica Set MongoDB

It all depends on what your goal is. If you want to reuse the existing mongod as a standalone server rather than a replica set member then the steps to do that would be:

  1. Restart mongod process without --replSet argument.
  2. Drop the local database:

    use local;
    db.dropDatabase();

How to shut down replica set in mongodb?

Run the following commands from the Unix shell:

mongo --port 27017 --eval 'db.adminCommand("shutdown")'
mongo --port 27018 --eval 'db.adminCommand("shutdown")'
mongo --port 27019 --eval 'db.adminCommand("shutdown")'

Stop replica set on mongo and primary goes into recovery status

Note: This solution is Windows specific but can be ported to *nix based systems easily.

You'll need to take steps in sequence. First of all, start your mongod instances.

start "29001" mongod --dbpath "C:\data\db\r1" --port 29001
start "29002" mongod --dbpath "C:\data\db\r2" --port 29002
start "29003" mongod --dbpath "C:\data\db\r3" --port 29003

Connect with mongo to each node and create an administrator user. I prefer creating super user.

> use admin
> db.createUser({user: "root", pwd: "123456", roles:["root"]})

You may create other users as deemed necessary.

Create key file. See documentation for valid key file contents.

Note: On *nix based systems, set chmod of key file to 400

In my case, I created key file as

echo mysecret==key > C:\data\key\key.txt

Now restart your MongoDB servers with --keyFile and --replSet flags enabled.

start "29001" mongod --dbpath "C:\data\db\r1" --port 29001 --replSet "rs1" --keyFile C:\data\key\key.txt
start "29002" mongod --dbpath "C:\data\db\r2" --port 29002 --replSet "rs1" --keyFile C:\data\key\key.txt
start "29003" mongod --dbpath "C:\data\db\r3" --port 29003 --replSet "rs1" --keyFile C:\data\key\key.txt

Once all mongod instances are up and running, connect any one with authentication.

mongo --port 29001 -u "root" -p "123456" --authenticationDatabase "admin"

Initiate replicaset,

> use admin
> rs.initiate()
> rs1:PRIMARY> rs.add("localhost:29002")
{ "ok" : 1 }
> rs1:PRIMARY> rs.add("localhost:29003")
{ "ok" : 1 }

Note: You may need to replace localhost with machine name or IP address.

How to remove all replication from a mongodb instance?

I usually do this by following these steps.

  1. Get replica set config. rs.config()

  2. Remove all members from config except primary itself.

  3. rs.reconfig(updated_config)

  4. remove all documents form system.replset --> db["system.replset"].deleteMany({})

See more information at MongoDb website

MongoDB: Stop from storing replica set settings

Running mongod as a standalone (no --replSet option) means you won't store oplog entries or replica set related information.

The local database will be created. The size of the local database should remain static in this case. The contents should be 2 collections:

startup_log which holds static information about your mongod instance, including version, start time and startup options.

system.indexes which contains index definitions for the collections in this database. In this case it would have a single entry defining the _id index for startup_log.

To confirm yourself that these are the only 2 collections run the following from the mongo shell:

use local;
show collections;

Shutdown of a single MongoDB replica set member

If you have 4x voting members and If you shutdown member that is SECONDARY , your PRIMARY will continue to be PRIMARY after you execute on the targeted SECONDARY:

 use admin
db.shutdownServer()

P.S.
This is in case you shutdown the member for a short time just for maintenance, in general 4x voting members allow only 1x member to be down at same time , if something happen with one more member you will have only 2 active voting members from 4 ( 50% < majority ) and PRIMARY will switch to SECONDARY.
For long term better follow the recommended steps in the comment by @Alex Blex and remove the member.

 Total members     Allowed to be down at once(default voting config -> 1x vote each member )
in replicaSet and still keeping PRIMARY online
1 0
2 0
3 1
4 1
5 2
6 2
7 3

Also it is best to reconfigure member in advance to HIDDEN state before shutting it down to hide the member from the application and reduce issues during start later. If you just want to stop it for short time it is not recommended to remove it since it will take some time to init sync it later if you add it again.

Restarting replication set MongoDB

If you shut down all the servers, the replication configuration will still be there so that if you restart the servers again, they will continue from the last state.
You don't have to reconfigure everything again if you want the same settings like the previous setup.

You just have to start the mongo server using the --replSet parameter the same way how you started in the first place.

mongod --replSet "rs0"

How to convert a MongoDB replica set to a stand alone server

Just remove a host from replica set (rs.remove('host:port')), relaunch it without replSet parameter and it's standalone again.

Need to change storage db path in mongo secondary node of replica set



Option 1: ( preserving the current already synced data )

  1. Stop the mongod service:

    mongo --host xxxx --port yyyy  
    use admin
    db.shutdownServer()
  2. Copy the data from old location to the new location:

    cp -R /oldPath/ /newPath/
  3. Change in the /etc/mongodb.conf the dbPath to point to the new location.

  4. Start the mongodb service.



Option 2) Init sync the member from the other members.

Same like option 1) , just ommit the point 2) just you will need to wait abit until the member init sync ( copy the data ) from the other members , it depends on data size and compression.



Option 3) Better high availability:

  1. From the PRIMARY member add another member on that will use the new path:

    rs.add("newMember:XXXX")
  2. Wait until the new member init sync.

  3. Remove the old SECONDARY member:

    rs.remove("oldMember:YYYY")
  4. Clean the old files and configuration.
    ( small disadvantage with this option that you will need to change the port for the new member if on the same host )

Option 2) seems best suitable for your case ...



Related Topics



Leave a reply



Submit