Converting standalone instance to replica set

MongoDB University M103: Basic Cluster Administration
#1

Hi Team,

What are the measures for converting existing mongo db instance, which is being used by application and contains application data in it.

Q1. Will converting instance into replica set persist application data?
Q2. Will adding new node into replica set make copy of existing data, which were stored before adding this node?
Q3. I s there any change in application connecting to mongo instance?

P.S. Is adding node for separating analytics and application db good example ?

Thanks in advance
Piyush

#2

Hey @Piyush_66733

https://docs.mongodb.com/manual/tutorial/convert-standalone-to-replica-set/#convert-a-standalone-to-a-replica-set

So for your questions

  1. Yes, as long as you do not destroy your database folder. Also making sure to upgrade the mongodb versions incrementally. To From 3.2 to 3.4 to 3.6 to 4.0 to 4.2. Not 3.2 to 4.2. This is because of the FeatureCompatibilityVersion

  2. Yes, for the most part. However, it can be configured as an arbiter

  3. Yes. To get the benefit of the replica set the application needs to know it is connected to a replica set. So if a PRIMARY goes down a SECONDARY can be elected in its place.

// standalone
"mongodb://mongodb0.example.com:27017/admin"
// replica set
"mongodb://mongodb0.example.com:27017,mongodb1.example.com:27017,mongodb2.example.com:27017/admin?replicaSet=myRepl"

However for administrative tasks with regards to the mongods you will still need to connect to each node individually with the first URI string to preform rolling upgrades

The main priority is to get High availability of the data in the event of failure. Therefore when going from a stand alone to a replica set of 3 nodes I would not advise to add any permanent SECONDARY for analytics purposes. From going over the courses my plan for in production environments is to have a 4 node set. With 3 of the nodes being able to vote and become PRIMARY and the forth node as a none voting delayed replicator, which I could then direct analytic queries to. This forth node also give the ‘hot’ backup ability.

Hope this helps.

3 Likes
#3

Hi natac13,
Thank you for the detailed answer.
Sorry for confusion; but I wanted to ask in Q2, if I introduce a new node later in my production server for analytics, it should be able to synced all data saved before addition and continue syncing after that.

#4

Again this depends on how you set it up. A server for analytics does not have to be a SECONDARY only read. It is only suggested as a use case for a situation to read only from a SECONDARY.

#5

Thank you. This is clear that arbiter in this case will not contain any data as per documentation, but need some pointers for

“and the forth node as a none voting delayed replicator”

In my use-case I have to introduce a new node to contain copy of application data for analytics also, which can act as High availability db if main db goes down.

It might be silly question to ask but if I am converting standalone to replica set in existing production application then introducing new node will take longer time to make copy of application data at the beginning?

#6

Well you would set up the code/app running the analytics queries to read only from a SECONDARY. You would need a 3 node replica set to achieve the high availability you desire.

Not silly, but yes it will take time for the added nodes to copy the database.

There is further info laid out in the docs.

https://docs.mongodb.com/manual/tutorial/convert-standalone-to-replica-set/

And this is what I was talking about as a non voting member.
https://docs.mongodb.com/manual/tutorial/configure-a-non-voting-replica-set-member/

2 Likes