4

We think about moving from a master-slaves to MongoDB with replica-set. Now I wonder if MongoDB replicas are also set up like read-only slaves or if each mongos is able to write and sync the others like a master-master farm?

This might reduce the single source of error (master down) and also balance the write-load for scaling with best performance (not only for read, but also write...).

5

A replica set can only have one primary at any particular time (one master) with the other nodes being secondaries (slaves) and so they are nothing like master-master (i.e. multi-master) replication.

You definitely should move to a replica set from master/slave configuration because that is the preferred and recommended way to replicate. From MongoDB docs: "replica sets are a functional superset of master/slave, and newer, more robust code".

When a primary fails, one of the secondaries will be automatically elected as a new primary (you can see the docs to see the details of how that happens).

You cannot get write balancing from having a replica set - you can only distribute writes by sharding in MongoDB.

  • If i understand this correctly, it is only writing with one of the servers within the replica-set, but i do not have to care which one is the master? mongodb master-slaves do manage and failover or sync themselves, really possible? how inconvenient was mysql... – ledy Jun 21 '12 at 6:53
  • correct, the drivers keep track of which is primary and send writes to that one (and reads unless you specify slaveOk for the read). And automatic failover happens as long as the majority of the replica set is up. – Asya Kamsky Jun 21 '12 at 12:13
  • Trying the master slave replication by editing the config seems to work. But how can it automatically failover the master with the "hard-coded", strictly defined master=true/false in the config file on each mongos? – ledy Jun 21 '12 at 14:51
  • You need to use proper replica set configuration, not master/slave. See this page mongodb.org/display/DOCS/… – Asya Kamsky Jun 21 '12 at 22:58
0

It pretty much like "write and sync the others like a master-master farm". as MongoDB docs said "Replica sets are a form of asynchronous master/slave replication, adding automatic failover and automatic recovery of member nodes." Please check http://www.mongodb.org/display/DOCS/Replica+Sets

0

First of all i am not discarding anything of @Asya Kamsky. But i would like to write down something about replica Set : Mater vs Slave.

As per MongoDB documented source from the MongoDB the Definite Guide Master-slave replication is the most general replication mode supported by MongoDB.This mode is very flexible and can be used for backup, failover, read scaling. The basic setup is to start a master node and one or more slave nodes, each of which knows the address of the master. To start the master, run mongod --master. To start a slave, run mongod --slave --source master_address, where master_address is the address of the master node that was just started.

Suppose that First, create a directory for the master to store data in and choose a port (10000):

$ mkdir -p ~/dbs/master
$ ./mongod --dbpath ~/dbs/master --port 10000 --master

Now set up the slave, choosing a different data directory and port. For a slave, you also need to tell it who its master is with the --source option:

$ mkdir -p ~/dbs/slave
$ ./mongod --dbpath ~/dbs/slave --port 10001 --slave --source localhost:10000

All slaves must be replicated from a master node. There is currently no mechanism for replicating from a slave (daisy chaining), because slaves do not keep their own oplog.

There is no explicit limit on the number of slaves in a cluster, but having a thousand slaves querying a single master will likely overwhelm the master node.

Note : If you slave off of two different masters with the same collections, MongoDB will attempt to merge them, but correctly doing so is not guaranteed. If you are using a single slave with multiple different masters, it is best to make sure the masters use different namespaces.

A replica set is basically a master-slave cluster with automatic failover. The biggest difference between a master-slave cluster and a replica set is that a replica set does not have a single master: one is elected by the cluster and may change to another node if the current master goes down. However, they look very similar: a replica set always has a single master node (called a primary) and one or more slaves (called secondaries).

Note: When the primary server goes down, the secondary server will become master.

The record of operations kept by the master is called the oplog, short for operation log. The oplog is stored in a special database called local, in the oplog.$main collection. Each document in the oplog represents a single operation performed on the master server.

In Master-Slave in replica set in Failover and Primary Election scenario depends upon the condition and configuration between Master & Slave like that

  1. When the primary server goes down, the secondary server will become master.
  2. If the primary goes down, the highest-priority servers will compare how up-to-date they are.
  3. If the Primary Server goes down among the Secondaries the highest-priority most-up-to-date server will become the new primary.

Using slaves to scale reads in MongoDB is that replication is asynchronous. This means that when data is inserted or updated on the master, the data on the slave will be out-of-date momentarily. This is important to consider if you are serving some requests using queries to slaves.

Note: you should be sure never to write to any database on the slave that is being replicated from the master. The slave will not revert any such writes in order to properly mirror the master. The slave should also not have any of the databases that are being replicated when it first starts up. If it does, those databases will not ever be fully synced but will just update with new operations.

  • Apress and O'Reilly both have books called "The Definitive Guide" which are currently definitively out of date as of February, 2018. The true definitive guide is the online MongoDB manual, which is updated regularly. Master-Slave Replication pre-dates replica sets and should not be recommended for new deployments or modern versions of MongoDB. Master-Slave replication has been deprecated for components of sharded clusters since MongoDB 3.2 and generally deprecated in the MongoDB 3.6 release. – Stennie Feb 12 '18 at 10:44
  • 1
    The terms primary and secondary are intentionally used to describe replica set members as these are roles that can change based on elections and auto-failover (as opposed to the fixed roles and manual failover of master and slave deployments). Replica sets are a significant improvement in integrity, reliability, and support over the legacy Master-Slave replication. – Stennie Feb 12 '18 at 10:44
  • @Stennie,Yes you are right it's Deprecated since version 3.6: MongoDB 3.6 deprecates the use of master-slave replication. The Replica sets replace "master-slave" replication for most use cases. But the OP has asked about Replica set- master-slave. – Md Haidar Ali Khan Feb 12 '18 at 11:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.