MongoDB.live, free & fully virtual. June 9th - 10th. Register Now

Programmatically add replica set member when it comes online

Let’s suppose i have a Replica Set (primary and a bunch of secondaries)… I want to automate registering a new mongodb node as part of the replica set. In other words, as a new node comes online, I would like to be able to self register to the Replica Set.

Is it possible to add a new member to a mongodb Replica Set without executing the rs.add() shell command from the primary node’s side?

What does the mongo community recommend as a best solution to this issue? The problem I’m trying to solve is data replication across multiple nodes, but the nodes come and go dynamically. I’m trying to use mongodb replication as an alternative to data replication at the application layer (e.g. not necessarily using replication as a fault tolerance mechanism but more as a data sourcing mechanism).

Bumping this. Anyone have any suggestions?

In my opinion, if the following was possible it could be a security risk.

However, I am sure it would be very easy to write a script that call mongo shell with the appropriate --eval.

Hi Jonathan,

You cannot change the replica set configuration without sending a reconfiguration command to the current primary.

However, if you want to add/remove members programatically to a self-hosted deployment (rather than using the mongo shell), you can use the replSetReconfig command. Shell helpers like rs.add(), rs.remove(), and rs.reconfig() are all wrappers around building a replica set configuration document to be applied with this server command.

As @steevej noted, there are security considerations if new instances have access to reconfigure the replica set. You would typically want to perform admin activities using automation tooling rather than having your application self-register. In the unfortunate event someone is able to compromise your application, you would not want an attacker to also gain admin access to your deployment.

This approach may also cause performance or stability issues depending on the size of your data, how frequently you are thinking of adding/removing members, and your read preferences / write concerns.

I recommend having a stable core of voting replica set members, with additional casual members configured as non-voting secondaries.

Regards,
Stennie

When the topic was first posted I asked my self what possible use case could be accomplished with such a procedure. So I came up with the following.

Could this be a good backup strategy?

For example, every day you bring up a different member which get re-synced. Once it catches up with the oplog (hopefully it does) it is shutdown and restarted as a non member. Now you have live backups You could have other secondaries but everything gets replicated all the time. Now you have a secondary but that is frozen in time. Kind of a mongodump but potential more efficient as the sync process might be better that the dump. Kind of an analytic node with infinite slaveDelay.

What’s your thoughts?

May be Jonathan_Whitaker could give us some clues on his own use-case.