[mongodb-user] non voting member in even-number of replicaset members?

[Tim Arnold]

Hi,
I'm establishing a vm cluster with one master and five workers. The master,
besides being the mongodb primary, also is a webserver and jenkins master.
I want to be able to make one worker into a master if the master fails.

So my thought is to duplicate the webserver and jenkins on on of the
workers; if the master goes down, I can switch this worker to be the master
and all is well again.
My problem of course is that I have an even number of members. I read about
non-voting members and wonder if that is my answer.

First, is this a bad design?
Second, if I make worker01 a non-voting member will that solve my problem?
I guess that when I have to switch worker01 to be master, I'd have to
change it to a voting member.

What's the best practice for this scenario?
thanks,
--Tim
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/fd125c3a-1aa0-4296-a5be-df8673879b7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

['Kevin Adistambha' via mongodb-user]

Hi Tim,

There are some suggestions that I can probably make:

The master, besides being the mongodb primary, also is a webserver and
jenkins master.

For best performance, it’s not recommended to run other resource-heavy
processes in the same machine as the MongoDB server. This will create
resource contention, and will lead to suboptimal performance for all
processes involved.

if the master goes down, I can switch this worker to be the master and all
is well again.

This sounds like a manual process. MongoDB replica set was designed to
automatically failover so your database can keep functioning in the face of
failures. This is probably another point to consider regarding separating
your application and the MongoDB servers, as this could be an operational
burden for you.

if I make worker01 a non-voting member will that solve my problem?

If you have an even-number of replica set members, you can make one of them
non-voting. The important thing is to have an odd number of voting members
so there is a clear majority.

I guess that when I have to switch worker01 to be master, I’d have to
change it to a voting member.

An offline replica set member is considered a “no” vote in elections. You
don’t need to reconfig the replica set if one of them is offline, and
generally there’s no need to reconfig the replica set constantly. The
replica set can elect a new primary as long as the majority of voting
members are online.

For best practices in setting up MongoDB, please see the Production Notes
<https://docs.mongodb.com/manual/administration/production-notes/>. For
details on replication, please see Replication
<https://docs.mongodb.com/manual/replication/>.

Best regards,
Kevin
​
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/31ddfb79-0173-4aa5-8316-2299aecc37d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Arnold]

Hi Kevin,
That makes sense. I'll rethink what I was about to do--I was making it
harder.

thanks for the detailed suggestions.
--Tim

Post by 'Kevin Adistambha' via mongodb-user
Hi Tim,
The master, besides being the mongodb primary, also is a webserver and
jenkins master.
For best performance, it’s not recommended to run other resource-heavy
processes in the same machine as the MongoDB server. This will create
resource contention, and will lead to suboptimal performance for all
processes involved.
if the master goes down, I can switch this worker to be the master and all
is well again.
This sounds like a manual process. MongoDB replica set was designed to
automatically failover so your database can keep functioning in the face of
failures. This is probably another point to consider regarding separating
your application and the MongoDB servers, as this could be an operational
burden for you.
if I make worker01 a non-voting member will that solve my problem?
If you have an even-number of replica set members, you can make one of
them non-voting. The important thing is to have an odd number of voting
members so there is a clear majority.
I guess that when I have to switch worker01 to be master, I’d have to
change it to a voting member.
An offline replica set member is considered a “no” vote in elections. You
don’t need to reconfig the replica set if one of them is offline, and
generally there’s no need to reconfig the replica set constantly. The
replica set can elect a new primary as long as the majority of voting
members are online.
For best practices in setting up MongoDB, please see the Production Notes
<https://docs.mongodb.com/manual/administration/production-notes/>. For
details on replication, please see Replication
<https://docs.mongodb.com/manual/replication/>.
Best regards,
Kevin
​

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/a0562e01-4720-4a03-a22e-af327f3bfcad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.