Shulou(Shulou.com)06/01 Report--

MongoDB supports failover and redundancy through asynchronous replication across multiple machines. In multiple machines, only at the same time

One is for write operations. It is because of this situation that MongoDB provides a guarantee of data consistency. Bear the responsibility

The machine of the Primary role can distribute reads to slave.

There are two types of MongoDB high availability:

1. Master-Slave master-slave replication:

You only need to add the-master parameter when one service starts, and the-slave and-source parameters for the other service.

Synchronization can be achieved. This solution is no longer recommended in the latest version of MongoDB.

2. Replica Sets replication set:

MongoDB developed a new feature replica set in version 1.6, which is one more powerful than the previous replication.

Automatic failover and automatic repair of member nodes are added, and the data between each DB is completely consistent, which greatly reduces the dimension.

Protect it successfully. It is recommended that you use replica set,replica set to fail over completely automatically.

The structure of Replica Sets is very similar to a cluster. Yes, you can think of it as a cluster, because it really works the same as a cluster. If one node fails, the other nodes will immediately take over the business without downtime.

First, deploy Replica Sets

1. Create a data file storage path

Root@Jane:/home/jane# mkdir-p / data/data/r0root@Jane:/home/jane# mkdir-p / data/data/r1root@Jane:/home/jane# mkdir-p / data/data/r2

2. Create the log file path

Root@Jane:/home/jane# mkdir-p / data/log

3. Create a master-slave key file to identify the full path of the private key of the cluster. If the key file content of each instance is different,

As a result, the program will not work properly.

Root@Jane:/# mkdir-p / data/keyroot@Jane:/# echo 'this is rs1 super secret key' > / data/key/r0root@Jane:/# echo' this is rs1 super secret key' > / data/key/r1root@Jane:/# echo 'this is rs1 super secret key' > / data/key/r2root@Jane:/data/key# chmod 600 r *

4. Start 3 instances

Root@Jane:/# mongod-- replSet rs1-- keyFile / data/key/r0-- port 28010-- dbpath / data/data/r0-- logpath / data/log/r0.log-- logappend-- forkroot@Jane:/# mongod-- replSet rs1-- keyFile / data/key/r1-- port 28011-- dbpath / data/data/r1-- logpath / data/log/r1.log-logappend-- forkroot@Jane:/# mongod-replSet rs1-keyFile / data/key/r2 -port 28012-- dbpath / data/data/r2-- logpath / data/log/r2.log-- logappend-- fork

5. Configure and initialize Replica Sets

The {_ id:0,host:'127.0.0.1:28010',priority:1} among them explains:

-- member IP and port. Priority=1 refers to PRIMARY.

6. Initialize the configuration

> rs.initiate (config_rs1); {"info": "Config now saved locally. Should come online in about a minute.", "ok": 1}

7. View replication set status

Rs.status () {"set": "rs1", "date": ISODate ("2013-11-21T08:30:06Z"), "myState": 1, "members": [{"_ id": 0, "name": "127.0.0.1 state": "127.0.0.1 state" 1 indicates normal; 0 indicates abnormal "state": 1 indicates Primary; 2 indicates Secondary "stateStr": "PRIMARY", #-indicates that this machine is the main library "uptime": 9315, "optime": Timestamp (1385013939, 1), "optimeDate": ISODate ("2013-11-21T06:05:39Z"), "self": true}, {"_ id": 1, "name": "127.0.0.1 optime 28011", "health": 1, "state": 2, "stateStr": "SECONDARY", "uptime": 8662 "optime": Timestamp (1385013939, 1), "optimeDate": ISODate ("2013-11-21T06:05:39Z"), "lastHeartbeat": ISODate ("2013-11-21T08:30:04Z"), "lastHeartbeatRecv": ISODate ("2013-11-21T08:30:04Z"), "pingMs": 0, "syncingTo": "127.0.0.1ISODate 28010"}, {"_ id": 2, "name": "127.0.0.1 pingMs 28012", "health": 1 "state": 2, "stateStr": "SECONDARY", "uptime": 8660, "optime": Timestamp (1385013939, 1), "optimeDate": ISODate ("2013-11-21T06:05:39Z"), "lastHeartbeat": ISODate ("2013-11-21T08:30:04Z"), "lastHeartbeatRecv": ISODate ("2013-11-21T08:30:05Z"), "pingMs": 0, "syncingTo": "127.0.0.1 purse 28010"}], "ok": 1}

You can also use isMaster to view Replica Sets status.

Rs1:PRIMARY > rs.isMaster () {"setName": "rs1", "ismaster": true, "secondary": false, "hosts": ["127.0.0.1 setName 28010", "127.0.0.1 setName 28011"], "primary": "127.0.0.1 rs1 28010", "me": "127.0.0.1 setName 28010", "maxBsonObjectSize": 16777216, "maxMessageSizeBytes": 48000000 "localTime": ISODate ("2013-11-21T08:39:09.364Z"), "ok": 1}

2. Master-slave operation log oplog

MongoDB's Replica Set architecture stores writes through a log called "oplog".

Oplog.rs is a fixed-length capped collection that exists in the "local" database and is used to record Replica

Sets operation log. By default, the 64-bit MongoDB,oplog is relatively large, up to 5% magnetism

Disk space. The size of oplog can be changed by changing the log size of oplog through the parameter "- oplogSize" of mongod.

Take a specific look at the example:

Field description:

Ts: the timestamp of an operation

Op: operation type, as follows:

I: insert

D: delete

U: update

Ns: namespace, that is, the collection name of the operation

O: the content of document

View oplog metadata information for master:

Rs1:PRIMARY > db.printReplicationInfo () configured oplog size: 3694.1673828125004MBlog length start to end: 10772secs (2.99hrs) oplog first event time: Thu Nov 21 2013 14:05:39 GMT+0800 (CST) oplog last event time: Thu Nov 21 2013 17:05:11 GMT+0800 (CST) now: Thu Nov 21 2013 17:16:37 GMT+0800 (CST) rs1:PRIMARY >

Field description:

Configured oplog size: configured oplog file size

Enable time period for log length start to end:oplog logs

Oplog first event time: the time when the first transaction log was generated

Oplog last event time: the time when the last transaction log was generated

Now: the time now

View the synchronization status of slave:

Rs1:PRIMARY > db.printSlaveReplicationInfo () source: 127.0.0.1:28011syncedTo: Thu Nov 21 2013 17:05:11 GMT+0800 (CST) = 1644 secs ago (0.46hrs) source: 127.0.0.1:28012syncedTo: Thu Nov 21 2013 17:05:11 GMT+0800 (CST) = 1644 secs ago (0.46hrs) rs1:PRIMARY >

Field description:

Source: IP and port of slave library

SyncedTo: current synchronization situation, how long has been delayed and other information

Third, master-slave configuration information

In the local library, there is not only a master-slave log oplog collection, but also a collection for recording master-slave configuration information-

System.replset

As you can see from this collection, the configuration information of Replica Sets can also be executed rs.conf () on any member instance.

To view the configuration information.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.