is it possible to have One mongodb instance belong to one or more replica sets ?
I am using Replica Set - mongodb replication scheme.
No.
With Master-Slave you could hack this to make it work, but not with Replica Sets. However, you can run two instances on a single machine. Simply run them on different ports.
Please note that this is generally not advised. If you are sharing replicas, this typically means that you do not have enough hardware.
Related
I am trying to find an authoritative answer to the following question: Is a single member replica set a supported deployment setup?
While this question may seems weird or silly, my specific use case follows:
A team wants to upgrade from Mongo 2 to Mongo 4 and they foresee that transactions might be useful to them. They currently run a single mongod instance. MongoDB documentation leads them to believe that to use transactions they must activate replica sets and deploy at least 3 mongod instances. Interesting documentation bits are:
https://docs.mongodb.com/manual/core/transactions/#transactions-and-replica-sets
Multi-document transactions are available for replica sets only. Transactions for sharded clusters are scheduled for MongoDB 4.2 [1].
https://docs.mongodb.com/manual/core/replica-set-members/
The minimum recommended configuration for a replica set is a three member replica set with three data-bearing members: one primary and two secondary members. You may alternatively deploy a three member replica set with two data-bearing members: a primary, a secondary, and an arbiter, but replica sets with at least three data-bearing members offer better redundancy.
My point of view is that:
Replica sets aim to increase redundancy and availability through a typical primary - secondaries design
Replica set documentation focuses on what make sense for its initial orginal purpose. It documents traditional and sane deployment setups fo HA (>= 3 and odd number of voter, separate machines, how to deal with multiple DC etc.)
Team is not interested in HA but must switch to replica sets in order to use TX (alternative path being to forgo TX and deploy a single mongod)
According to replica set documentation and my distributed systems background, I don't see why a single member replica set would be an issue if you don't care about HA. With a single member a primary can be elected, replication is NOOP and default and majority write concern are just w: 1.
Am I right?
I know Mongodb suggest the replication set minimum is 3
Can I use two servers to install Mongodb with 4 replication sets in order to prevent Write failure when one node down?
My idea is to install two more instances on each server to fake/get rid of it:
Mongodb 1
Replcation set 1 (Master)
Replcation set 2 (Secondary)
Mongodb 2
Replcation set 3 (Secondary)
Replcation set 4 (Arbiter)
If one server down, it still has two replication sets for it.
Can anyone can comment my idea?
I would like to know is there any issue/risk needed to consider?
Thanks!
This is a bad idea. Your suggested configuration would be counter-productive for two main reasons:
Running two instances of MongoDB on the same hosts will lead to them both running slowly and awkwardly, competing for memory, cpu, disk i/o, etc.
If one of the hosts goes down, the two nodes on the other will not be able to continue the replica set because with only two nodes running out of four, you don't have the majority necessary to become primary.
MongoDB is intended to be run effectively on multiple hosts, so it is designed for that; even if you could find a way to shoe-horn a functioning replica set onto only two hosts, you would be working against MongoDB's design and struggling to make it work effectively.
Really, your best option is to run a single mongod instance on each of your two hosts, and to run an arbiter on a third (separate) host; that kind of normal 3-host configuration is an effective and straightforward way of achieving both data replication and high availability.
Please read https://docs.mongodb.com/manual/replication/
Even number of members in a set is not recommended. The only reason to add an Arbiter is to resolve this issue and increase number of members by 1 to make it odd. It makes no sense to add 2 Arbiters at all.
Similarly there is no point to put an Arbiter to the same server with any other member. It is quite lightweight, so you can co-locate it with an application server for example.
Having 2 db servers the best replica set configuration would be:
Mongodb 1
Master
Mongodb 2
Secondary
Any other server
Arbiter
Simple answer is, no you cannot do it..
Reason is "majority". If you loose one server of those two, you don't have majority of votes online.
This is reason, why 3 is minimum. It can be 3 data bearing nodes or 2 data bearing nodes and one arbiter. All of those have one vote and if you loose one of those, replica set still have 2/3 votes what is majority. Like 3/5 or 4/7.
Values 1/2 (or 2/4) are not majority.
I'm new to Mongo, have been using Cassandra for a while. I didn't find any clear answers from Mongo's docs. My questions below are all closely related.
1) How to specify the replication factors in Mongo?
In C* you can define replication factors (how many replicas) for the entire database and/or for each table. Mongo's newer replica set concept is similar to C*'s idea. But, I don't see how I can define the replication factors for each table/collection in Mongo. Where to define that in Mongo?
2) Replica sets and replication factors?
It seems you can define multiple replica sets in a Mongo cluster for your databases. A replica set can have up to 7 voting members. Does a 5-member replica set means the data is replicated 5 times? Or replica sets are only for voting the primary?
3) Replica sets for what collections?
The replica set configuration doc didn't mention anything about databases or collections. Is there a way to specify what collections a replica set is intended for?
4) Replica sets definition?
If I wanted to create a 15-node Mongo cluster and keeping 3 copies of each record, how to partition the nodes into multiple replica sets?
Thanks.
Mongo replication works by replicating the entire instance. It is not done at the individual database or collection level. All replicas contain a copy of the data except for arbiters. Arbiters do not hold any data and only participate in elections of a new primary. They are usually deployed to create enough of a majority that if an instance goes down a new instance can be elected as the primary.
Its pretty well explained here https://docs.mongodb.com/manual/replication/
Replication is referred to the process of ensuring that the same data is available on more than one Mongo DB Server. This is sometimes required for the purpose of increasing data availability.
Because if your main MongoDB Server goes down for any reason, there will be no access to the data. But if you had the data replicated to another server at regular intervals, you will be able to access the data from another server even if the primary server fails.
Another purpose of replication is the possibility of load balancing. If there are many users connecting to the system, instead of having everyone connect to one system, users can be connected to multiple servers so that there is an equal distribution of the load.
In MongoDB, multiple MongDB Servers are grouped in sets called Replica sets. The Replica set will have a primary server which will accept all the write operation from clients. All other instances added to the set after this will be called the secondary instances which can be used primarily for all read operations.
I currently have 2 physical servers and one arbiter configured as a replica set. I would like to try sharing with this configuration. I know it is possible to run two mongod instances on the same server, one as master of replica 1, the other as slave of replica 2: can these two processes (master of replica 1 and slave of replica 2) point to the same database? Isn't there the danger of a sort of loop?
Hmm I am unsure if you know what replication really is.
All members in the replica set will share the same database(s), they will replicate the database(s) between them and maintain them.
Replicas are exactly that, they are copies of each other, including database.
I suggest you read: http://docs.mongodb.org/manual/replication/
Edit
There could be another meaning here as in to the same files since you mention running the master and slaves on the same node.
First off running two replicas on the same node is pointless. You will get no benefit and if anything you will get a performance problem since that IO is now taking double the strain it normally would.
So I would begin by saying that your idea would be really bad design even if it was feasible which it is not, the physical files cannot have multiple file locks on them.
Is there any advantage or disadvantage to using mongos in front of just a replica set (as opposed to a sharded cluster)? Having to specify the same replica set members in multiple apps doesn't feel right to me -- I'd rather do it in one central place.
If anything, sharding in the future would be more straight-forward. Right?
Thanks in advance!
Harry.
The downside is that you've likely introduced a single point of failure into your application. If the mongos goes down then the mongods are no longer accessible - you've defeated the high availability of replica sets.
You could set up multiple mongos instances but then you're back in the same boat. You could theoretically set up a load balancer in front of your mongos instances so that you only have to list one address and can still have high availability.
There is nothing wrong and in fact this is a typically good idea, mainly because it allows you to scale onto sharding with no downtime.
Of course for redundancy sake you would have more than one mongos. You would define, in each app, a list of load balanced mongos instances (in a more serious setup) which then back onto your cluster of replica set shards.