Convert arbiter into Secondary

Ops and Admin
1

Hello! i have a PSA replica set on production deployment

mongodb-01 - primary
mongodb-02 - secondary
mongodb-03 - arbiter

i want to convert mongodb-03 - arbiter to secondary node
i’ve test this scenario on my local vagrant env using this steps

1) shutdown Mongodb process on arbiter and remove everything from /var/lib /mongo
  2)  from the master remove the arbiter from the rs.remove set ("arbiter-node: 27017") 
3) turn on mongo process
4) add the former arbiter to the replication set with the rs.add command ({host: "arbiter-node: 27017"})

is this right steps? I want to do this without stopping the application that writes to mongodb, will the data lost? we write with simple inserts
or i need to stop the application then do steps above

2

Did it work in your test env?
Arbiter cannot be a primary or secondary as it is non data bearing and used only for election.Also it has lesser resources

3

i don’t have a test env for this project ;( yeah i know about that, but my arbiter have equal resources as other nodes

4

Hi @Gregory_Rybalka,

In your example you aren’t directly converting an arbiter to a secondary. If you stop mongod on the arbiter, move (or remove) the contents of the dbPath, remove the arbiter from the current replica set config, and reconfigure this instance as a new secondary your procedure would be equivalent to adding a new secondary member.

If your arbiter node is currently called arbiter-node, I would update the name before adding to your replica set to avoid confusion :slight_smile: .

I want to do this without stopping the application that writes to mongodb, will the data lost? we write with simple inserts

If you are reconfiguring a replica set you do not have to stop application writes as long as your application correctly handles failover scenarios and you keep a strict majority of your voting replica set members available so a primary can be elected or sustained. For example, with your starting PSA configuration (assuming the S is voting) you have a fault tolerance that allows 1 member of the replica set to be unavailable.

If you are using a MongoDB 3.6+ driver & server, the retryable writes feature can retry write operations that fail due to transient network errors and replica set elections. Official MongoDB 4.2+ drivers enable retryable writes by default.

Regards,
Stennie

1 Like