1

I used to try a replica set demo in same db folder. The replica set name is "test". Then I tried to re-build repl set with different name "repl". After i reconfig, I get error message below:

{
        "ok" : 0,
        "errmsg" : "replSetReconfig should only be run on PRIMARY, but my state is REMOVED; use the \"force\" argument to override",
        "code" : 10107,
        "codeName" : "NotMaster"
}

So I follow the errmsg, and try to run the command below:

rs.reconfig(config,{"force":true})

Now I get following error message:

{
        "ok" : 0,
        "errmsg" : "New and old configurations differ in replica set name; old was test, and new is repl",
        "code" : 103,
        "codeName" : "NewReplicaSetConfigurationIncompatible"
}

too bad! So I use the previous name "test". But I get the error again.

{                                                                                                                       
        "ok" : 0,                                                                                                       
        "errmsg" : "New and old configurations differ in the setting of the arbiterOnly field for member 127.0.0.1:27020
; to make this change, remove then re-add the member",                                                                  
        "code" : 103,                                                                                                   
        "codeName" : "NewReplicaSetConfigurationIncompatible"                                                           
}  

I just really don't understand, if every configure information has to be consistent with the previous, why do we need to reconfig it?

Someone said you can drop local database, but this operation still doesn't work.

 {
            "ok" : 0,
            "errmsg" : "Cannot drop 'local' database while replication is active",
            "code" : 20,
            "codeName" : "IllegalOperation"
    } 

Oh, MGD! I just couldn't understand why it is so difficult to restart a replset in current db folder.

1
4

As per MongoDB BOL Here To Reconfigures an existing replica set, overwriting the existing replica set configuration. To run the method, you must connect to the primary of the replica set.

rs.reconfig(configuration, force)

To reconfigure an existing replica set, first retrieve the current configuration with rs.conf(), modify the configuration document as needed, and then pass the modified document to rs.reconfig().

rs.reconfig() provides a wrapper around the replSetReconfig command.

The force parameter allows a reconfiguration command to be issued to a non-primary node.

WARNING: Avoid reconfiguring replica sets that contain members of different MongoDB versions as validation rules may differ across MongoDB versions.

The rs.reconfig() shell method can trigger the current primary to step down in some situations. When the primary steps down, it forcibly closes all client connections. This is by design. Since it may take a period of time to elect a new primary, schedule reconfiguration changes during maintenance periods to minimize loss of write availability.

{ force: true }

WARNING: Using rs.reconfig() with { force: true } can lead to rollback of committed writes. Exercise caution when using this option.

Member Priority and Votes Changed in MongoDB version 3.2.

Members with priority greater than 0 cannot have 0 votes.

Non-voting members must have priority of 0.

For example A replica set named rs0 has the following configuration:

{
   "_id" : "rs0",
   "version" : 1,
   "protocolVersion" : NumberLong(1),
   "members" : [
      {
         "_id" : 0,
         "host" : "mongodb0.example.net:27017",
         "arbiterOnly" : false,
         "buildIndexes" : true,
         "hidden" : false,
         "priority" : 1,
         "tags" : {

         },
         "slaveDelay" : NumberLong(0),
         "votes" : 1
      },
      {
         "_id" : 1,
         "host" : "mongodb1.example.net:27017",
         "arbiterOnly" : false,
         "buildIndexes" : true,
         "hidden" : false,
         "priority" : 1,
         "tags" : {

         },
         "slaveDelay" : NumberLong(0),
         "votes" : 1
      },
      {
         "_id" : 2,
         "host" : "mongodb2.example.net:27017",
         "arbiterOnly" : false,
         "buildIndexes" : true,
         "hidden" : false,
         "priority" : 1,
         "tags" : {

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

      },
      "getLastErrorDefaults" : {
         "w" : 1,
         "wtimeout" : 0
      },
      "replicaSetId" : ObjectId("58858acc1f5609ed986b641b")
   }
}

The following sequence of operations updates the members[n].priority of the second member. The operations are issued through a mongo shell connected to the primary.

cfg = rs.conf();
cfg.members[1].priority = 2;
rs.reconfig(cfg);

As the above statement working in such as

  1. The first statement uses the rs.conf() method to retrieve a document containing the current configuration for the replica set and sets the document to the local variable cfg.

  2. The second statement sets a members[n].priority value to the second document in the members array. For additional settings, see replica set configuration settings.

    To access the member configuration document in the array, the
    statement uses the array index and not the replica set member’s
    `members[n]._id` field.
    
  3. The last statement calls the rs.reconfig() method with the modified cfg to initialize this new configuration. Upon successful reconfiguration, the replica set configuration will resemble the following:

    { "_id" : "rs0", "version" : 2, "protocolVersion" : NumberLong(1), "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : {

         },
         "slaveDelay" : NumberLong(0),
         "votes" : 1
      },
      {
         "_id" : 1,
         "host" : "mongodb1.example.net:27017",
         "arbiterOnly" : false,
         "buildIndexes" : true,
         "hidden" : false,
         "priority" : 2,
         "tags" : {
    
         },
         "slaveDelay" : NumberLong(0),
         "votes" : 1
      },
      {
         "_id" : 2,
         "host" : "mongodb2.example.net:27017",
         "arbiterOnly" : false,
         "buildIndexes" : true,
         "hidden" : false,
         "priority" : 1,
         "tags" : {
    
         },
         "slaveDelay" : NumberLong(0),
         "votes" : 1
      }
    

    ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : 2000, "getLastErrorModes" : {

      },
      "getLastErrorDefaults" : {
         "w" : 1,
         "wtimeout" : 0
      },
      "replicaSetId" : ObjectId("58858acc1f5609ed986b641b")
    

    } }

Note : When updating the replica configuration object, access the replica set members in the members array with the array index. The array index begins with 0. Do not confuse this index value with the value of the members[n]._id field in each document in the members array.

For help you can type in mongo shell rs.help().

> rs.help()
        rs.status()                                { replSetGetStatus : 1 } checks repl set status
        rs.initiate()                              { replSetInitiate : null } initiates set with default settings
        rs.initiate(cfg)                           { replSetInitiate : cfg } initiates set with configuration cfg
        rs.conf()                                  get the current configuration object from local.system.replset
        rs.reconfig(cfg)                           updates the configuration of a running replica set with cfg (disconnects)
        rs.add(hostportstr)                        add a new member to the set with default attributes (disconnects)
        rs.add(membercfgobj)                       add a new member to the set with extra attributes (disconnects)
        rs.addArb(hostportstr)                     add a new member which is arbiterOnly:true (disconnects)
        rs.stepDown([stepdownSecs, catchUpSecs])   step down as primary (disconnects)
        rs.syncFrom(hostportstr)                   make a secondary sync from the given member
        rs.freeze(secs)                            make a node ineligible to become primary for the time specified
        rs.remove(hostportstr)                     remove a host from the replica set (disconnects)
        rs.slaveOk()                               allow queries on secondary nodes

        rs.printReplicationInfo()                  check oplog size and time range
        rs.printSlaveReplicationInfo()             check replica set members and replication lag
        db.isMaster()                              check who is primary

        reconfiguration helpers disconnect from the database so the shell will display
        an error, even if the command succeeds.

For your further ref Here and Here

1

I think you need to remove all replicas configurations first. So basically you need to launch your instance without --replSet. Then go to db.system.replset collection to remove corresponding id. Then restart the replica instances.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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