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

one, written 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, replica set replication, roles include primary and secondary.

MongoDB officially recommended the use of replica set mode , the replica set is the automatic recovery function of the master-slave cluster. The most obvious difference between a master-slave cluster and a replica set is that the replica set does not have a fixed master node: The entire cluster elects a master node and changes to other nodes when it is not working. The replica set always has an active node and one or more backup nodes. The best advantage of a replica set is its automation. Second, the replica set and cluster introduction

1. Node type
Standard: A regular node that stores a complete copy of the data, participates in an election vote, and is likely to become a primary node.
Passive: A full copy of the data is stored, participating in the voting, not being a primary node.
Arbiter: The quorum node, which only participates in voting, does not receive replicated data, and cannot become a primary node.
A Repica sets node number is preferably odd (odd).
2. Parameter
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 directly tangent to each other primary secondary).
A arbiter node, holding a ballot in its hand, determines which of the top two standard nodes can be primay. Third, the configuration step

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

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

Description: port=10001, representing the port number, if not specified, defaults to 27017
Replset=shard1 (the name of the replica set), which is the same parameter for each node in a replica sets
Logappend=true, log files are automatically cumulative, not overwritten
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
Login on any standard node mongdb, we choose h1 (ip:192.168.58.135)
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 indicates success.

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

4, view the status of replica set

hadoop@h1:~/mongodb$ Bin/mongo localhost:10001 mongodb Shell version:2.4.6 connecting to:localhost:10001/test: 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 }

Of the information in replica set, it is important to:
MyState, if the 1 represents the current login is primary, if 2 represents the current login is secondary.
The more important thing in member information is
State: 1 indicates that the host is currently available to read and write, 2: cannot read or write
Health: 1 indicates that the host is currently normal, 0: abnormal

5. Test replica 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 the error, no relationship, in secondary read the data also need us to do the last step, in the need to read the data on the secondary 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 the 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
        }
    ]
}