A copy set of a MongoDB cluster

We left a few questions in the last chapter.

1 whether the primary node can actively switch connections on its own ?

Need to switch manually now

2 master node read and write pressure too big how to solve

3 each of the above data from the node is a full copy of the database, the pressure from the node will not be too large

4 data pressure to reach the machine can not support the time to expand their own initiative?

Nosql is to solve the large data volume. High-scale, high-performance, flexible data model. High availability. But the structure of light through the master-slave model is far from the above points. So. MongoDB has designed the capabilities of replica sets and shards. Let's just say the following. Replica set

MongoDB It is not recommended to use master-slave mode, but instead of replica set.

IMPORTANT

Replica Sets Replace Master - slave Replication for most use cases. If possible, use replicasets rather than master-slave replication for all new production deployments. This documentation remains to support legacy deployments and for Archivalpurposes only.

from < http://docs.mongodb.org/master/core/master-slave/ >

What is a replica set

Replica Collection ( replicasets) . is a replication feature based on the master / slave replication mechanism. However, it adds its own proactive failover and recovery features. A cluster can support a maximum of 7 servers. And the arbitrary node can be the master node.

All write operations are distributed to the master node. The read operation can be performed on whatever node.

The ability to discover that the client is connected to the entire replica set does not matter which server is down. The primary server is responsible for reading and writing the entire replica set.

The replica set synchronizes data periodically. Once the master node is hung. The replica node will elect a new host as the primary node.

When the broken node is repaired, it will actively expand itself to the replica node.

How to configure a replica set

Create three files on one machine the user holds three databases, and then three databases are configured to configure the startup database for their replset(the replication set forms a closed loop, respectively) .

Configuring Startup Parameters

Startup configuration file

Mongoa.batmongod--configa.confmongob.batmongod--configb.confmongodbc.batmongod--config c.conf

Log in to Database

Ashell.batmongo 127.0.0.1:9000b.shell.batmongo 127.0.0.1:9001c.shell.batmongo 127.0.0.1:9002

Initializing a replica set

Randomly log on to a machine on three machines input such as the following name return

Use Admindb.runcommand ({"replsetinitiate": {"_id": ' Child ', "members": [{"_id": 1, "host": "127.0.0.1:9000"},{"_id": 2, "Host": "127.0.0.1:9001"},{"_id": 3, "host": "127.0.0.1:9002",},]})

View cluster status

Child:secondary> Rs.status () {"Set": "Child", "date": Isodate ("2015-08-16t07:43:36z"), "MyState"                        : 2, "syncingto": "127.0.0.1:9002", "members": [{"_id": 1,                        "Name": "127.0.0.1:9000", "Health": 1, "state": 2, "Statestr": "Secondary", "uptime": 182, "Optime": Time Stamp (1439170908, 1), "Optimedate": Isodate ("2015-08-10t01:41:48z"), "infom                        Essage ":" Syncing to:127.0.0.1:9002 "," Self ": true}, {                        "_id": 2, "name": "127.0.0.1:9001", "Health": 1,                        "State": 2, "statestr": "Secondary", "uptime": 7, "Optime": TImestamp (1439170908, 1), "Optimedate": Isodate ("2015-08-10t01:41:48z"), "LA Stheartbeat ": Isodate (" 2015-08-16t07:43:36z ")," Lastheartbeatrecv ": Isodate (" 2015-08-16t07:43:35z                        ")," Pingms ": 2," lastheartbeatmessage ":" Syncing to:127.0.0.1:9002 ",                        "Syncingto": "127.0.0.1:9002"}, {"_id": 3,                        "Name": "127.0.0.1:9002", "Health": 1, "state": 1, "Statestr": "PRIMARY", "uptime": 8, "optime": Times Tamp (1439170908, 1), "Optimedate": Isodate ("2015-08-10t01:41:48z"), "lasthe                        Artbeat ": Isodate (" 2015-08-16t07:43:35z ")," Lastheartbeatrecv ": Isodate (" 2015-08-16t07:43:36z "), "Pingms ": 772," Electiontime ": Timestamp (1439711010, 1)," electiondate ": I Sodate ("2015-08-16t07:43:30z")}], "OK": 1}

The entire section was created successfully

Replica set Database test

Start three databases view only one active node other is a replica node

Stop the active point , we check the active point

Child:primary>show DBS

2015-08-16t15:51:21.667+0800socket recv () errno:10053 The software on your console has aborted a

an established connection. 127.0.0.1:9002

2015-08-16t15:51:21.669+0800socketexception:remote:127.0.0.1:9002 error:9001

Connect to database discovery again Active Point has been transferred to 9000Port

then the 9002 Database Open

View Status 9002 database is a backup point

The above indicates that our replica set has been built.

Summary:

the replica set solution overcomes our fault escape function. But we still have a few questions . Each of the above data from the node is a full-volume copy of the database. Will the pressure from the node be too large?

Data pressure to the machine can not support the time to do their own initiative to expand?

A replica set of a MongoDB cluster