Ubuntu under the MongoDB cluster Build: Relica sets (replica set configuration)

first, write in front of the words

MongoDB supports asynchronous data replication between different services to implement failover (failover, failover, failback) and redundancy (data redundancy). At the same time, only one service node (primary or master) supports writing. MongoDB supports two modes of replication:

Master/slave, master-slave replication, roles include Master and Slave.
Replica Set, replication set replication, roles include primary and secondary.

MongoDB is officially recommended to use the replica set mode , which is the master-slave cluster with automatic failure recovery function. The most obvious difference between master and slave clusters and replica sets is that the replica set does not have a fixed master node: The entire cluster will elect a master node, and when it does not work, it changes to other nodes. A replica set always has an active node and one or more backup nodes. The best advantage of a replica set is that it is fully automated. Ii. Introduction to Replica sets and clusters

1. Node type
Standard: A regular node that stores a complete copy of the data, participates in an election poll, and is likely to become a primary node.
Passive: Stores a complete copy of the data, participates in voting, and cannot be a primary node.
Arbiter: The quorum node, which only participates in voting, does not receive replicated data, and cannot be a primary node.
A Repica sets node is preferably an odd number (odd).
2. Parameters
There are two parameters for the replica set:
–replset, the name of the replica set.
–oplogsize, the size of the operation log, in megabytes.
3, cluster three node distribution
Two standard nodes (these two nodes can be mutually tangent primary secondary directly).
A arbiter node, holding a ballot in its hand, determines which of the two standard nodes above can become primay. third, the configuration steps

1, referring to the previous blog post (http://blog.csdn.net/u012859691/article/details/44680249), three nodes mongodb.conf content modified as follows:

port=10001
dbpath=data/
logpath=log/mongodb.log
logappend=true
replset=shard1

Description: port=10001, represents the port number and defaults to 27017 if not specified
Replset=shard1 (the name of the replica set), this parameter is consistent for each node in a replica sets
Logappend=true, the log file automatically accumulates, not overwrite
2. Start the first standard node (ip:192.168.58.135)

hadoop@h1:~/mongodb$ bin/mongod-f mongodb.conf All
output going to:/home/hadoop/mongodb/log/mongodb.log

Start the first standard node (ip:192.168.58.136)

hadoop@h2:~/mongodb$ bin/mongod-f mongodb.conf All
output going to:/home/hadoop/mongodb/log/mongodb.log

3. Initialize the replica set
Log in to mongdb on any of the standard nodes, we choose H1 (ip:192.168.58.135) here
hadoop@h1:~/mongodb$ Bin/mongo localhost:10001
and execute the following command:

cfg={_id: ' Shard1 ', members:[ 
{_id:0,host: ' 192.168.58.135:10001 '}, 
{_id:1,host: ' 192.168.58.136:10001 '}] 
}

The following message appears to indicate success.

{ 
   "info": "Config now saved locally.  Should come online in about a minute. ", 
   " OK ": 1 
}

4. View the status of the replica set

hadoop@h1:~/mongodb$ Bin/mongo localhost:10001 mongodb shell version:2.4.6 connecting to:localhost:10001/test shard1: Secondary> Rs.status () {"Set": "Shard1", "date": Isodate ("2015-03-27t11:24:23z"), "MyState": 2, "sy Ncingto ":" 192.168.58.136:10001 "," members ": [{" _id ": 0," name ":" 192.168.58.135 : 10001 "," Health ": 1," state ": 2," statestr ":" Secondary "," uptime ": 4
            "Optime": Timestamp (1427446232, 1), "Optimedate": Isodate ("2015-03-27t08:50:32z"), "Self": true}, {"_id": 1, "name": "192.168.58.136:10001", "Hea Lth ": 1," state ": 1," Statestr ":" PRIMARY "," uptime ": 258," Optime ": Timestamp (1427446232, 1), "Optimedate": Isodate ("2015-03-27t08:50:32z"), "lastheartbeat": Isodat
E ("2015-03-27t11:24:23z"),            "Lastheartbeatrecv": Isodate ("2015-03-27t11:24:22z"), "Pingms": 0}], "OK": 1 }

Among the information in the replica set, it is important to:
MyState, if 1 is the current login is primary, if 2 represents the current login is secondary.
The more important part of the member information is
State: 1 indicates that the host is currently capable of reading and writing, 2: cannot read and write
Health: 1 indicates that the host is currently normal, 0: exception

5. Test copy Set data copy function
(1) Login primary Mongod, insert a piece of data

hadoop@h2:~/mongodb$ Bin/mongo localhost:10001
mongodb shell version:2.4.6
connecting to:localhost:10001/ Test
shard1:primary> Db.book.insert ({' title ': ' Computer '})

(2) Login secondary to see if there is any data

shard1:secondary> use test
switched to DB test
shard1:secondary> db.book.find ()
error: {"$err": "Not Master and Slaveok=false "," Code ": 13435}

Found an error, no relationship, read the data in secondary also need us to do a final step, in the need to read the data secondary on the execution

Shard1:secondary> Db.getmongo (). Setslaveok ()
shard1:secondary> db.book.find ()
{"_id": ObjectId (" 55153fd08ebbb2c6f1ad3a11 ")," title ":" Computer "}

OK, the test was successful.
6, add an Arbitration node, only responsible for arbitration, do not do data storage

Shard1:primary> Rs.addarb ("192.168.58.137:10001");
{"OK": 1}

7. View existing Environment

Shard1:primary> rs.conf ()
{
    "_id": "Shard1",
    "version": 3,
    "members": [
        {
            "_id": 0,
            "Host": "192.168.58.135:10001"
        },
        {
            "_id": 1,
            "host": "192.168.58.136:10001"
        },
        {
            "_id": 2,
            "host": "192.168.58.137:10001",
            "arbiteronly": True
        }
    ]
}