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

Mongodb supports failover and redundancy through asynchronous replication in multiple machines, and only one of the multiple machines is used for write operations at a time. It is precisely because of this feature that data consistency is guaranteed for mongodb, and machines that play the role of primary can distribute read operations to slave.

There are two types of Mongodb high availability:

Master-slave master-slave replication

Synchronization can be achieved by adding-- master parameters to one service and-slave and-source parameters to another service. This scheme is no longer supported in the latest version of mongodb.

Replica sets replication set:

Mongodb developed a new function replica sets from version 1.6, which is more powerful than master-slave. It adds automatic failover and automatic repair of member nodes, and the data between each DB is completely consistent, which greatly reduces the maintenance cost. Auto shared has made it clear that replication paris is no longer supported. It is recommended that replica set,replica set failover be fully automated.

Suppose a three-node mongodb cluster

Three nodes server-1,-2,-3 whichever node fails, the other nodes will immediately transfer the business without downtime

Focus on learning replica set replication sets

Replica set can implement automatic failover and automatic recovery.

Replica set consists of two or more nodes that replicate each other.

Replica set automatically selects primary nodes, none of which is a fixed primary.

Mongos automatically detects a change in the primary node of a replica set and sends the write to the new primary node.

It is usually used in the following scenarios

Data redundancy.

Automatic failover to provide high availability services.

Spread the load of reading.

Simplify maintenance (as opposed to master-slave).

Disaster recovery.

First, start mongod. There are two parameters for replica set:

-- replSet, the name of the replication set.

-- oplogSize, the size of the operation log in MB. (usually 5% of disk space)

Version of Mongodb:

[root@anenjoy mongodb] # / usr/local/mongodb/bin/mongo-version

MongoDB shell version: 2.4.8

IP of three virtual machines in the lab:

192.168.1.247

192.168.1.248

192.168.1.250

First set up the installation of mongodb on each server host and configure the storage path

Installation is the unzipping package, which will not be described in detail.

Step 3: start mongodb

Command parameters:

SERVER-1

/ usr/local/mongodb/bin/mongod-- port 27017-- replSet res1-- keyFile / data/mon_db/key/res1-- oplogSize 27017-- dbpath=/data/mon_db/res1/-- logpath=/usr/local/mongodb/log/mongodb.log-- logappend-- fork

Parameter description:-- port is the port number

-- replSet is the identification parameter of replica set, followed by the name of set

-- keyFile is the private key file that identifies joining the group.

-- logs for oplogSize replica operations, which can be crapped collection and recycled, with a size of 100MB

-- the storage path of the dbpath data file

-- logpath log file path-- logappend is log append

-- fork background running program

SERVER-2

/ usr/local/mongodb/bin/mongod-- port 27018-- replSet res1-- keyFile / data/mon_db/key/res2-- oplogSize 27018-- dbpath=/data/mon_db/res2/-- logpath=/usr/local/mongodb/log/mongodb.log-- logappend-- fork

SERVER-3

/ usr/local/mongodb/bin/mongod-- port 27019-- replSet res1-- keyFile / data/mon_db/key/res3-- oplogSize 27019-- dbpath=/data/mon_db/res3/-- logpath=/usr/local/mongodb/log/mongodb.log-- logappend-- fork

Start separately and observe the changes of log files in real time to see if there are any problems (tail mongodb.log-f)

If you encounter error information:

[rsStart] replSet can't get local.system.replset config from self or any seed (EMPTYCONFIG)

It means you haven't initialized yet, so you don't have to consider this for the time being.

Step 4: initialize

Log in to any mongodb database of server

[root@test02 bin] # / usr/local/mongodb/bin/mongo-- port 27017

MongoDB shell version: 2.4.8

Connecting to: 127.0.0.1:27017/test

>

Configuration initialization file

Config_res1= {_ id:'res1',members: [

{_ id:0,host:'192.168.1.248:27017',priority:2}

{_ id:1,host:'192.168.1.247:27018',priority:0}

{_ id:2,host:'192.168.1.250:27019',priority:1}]

}

"_ id": "res1"

"members": [

{

"_ id": 0

"host": "192.168.1.248purl 27017"

"priority": 2

}

{

"_ id": 1

"host": "192.168.1.247 purl 27018"

"priority": 0

}

{

"_ id": 2

"host": "192.168.1.250 purl 27019"

"priority": 1

}

]

}

Priority priority. The higher the value, it means primary. When the primary is down, the priority value is the second when the primary role

> rs.initiate (config_res1)

{

Info: "Config now saved locally. Should come online in about a minute."

"ok": 1

}

The value of _ id:'res1' this _ id: must be the name of your set collection, that is, the name of the replSet collection, otherwise it will prompt you

Error message information

"errmsg": "couldn't initiate: set name does not match the set name host 192.168.1.247 expects 27018"

Check the status later

Rs.status ()

{

"set": "res1", # set set name

"date": ISODate ("2013-12-04T00:37:08Z"), creation date

"myState": 1

"members": [

{

"_ id": 0

"name": "192.168.1.248purl 27017"

"health": 1, 1 means normal access, 0 exception

"state": 1,1 for primary, 2 for secondary

"stateStr": "PRIMARY", primary main library

"uptime": 1632

Optime: Timestamp (1386116964, 1)

OptimeDate: ISODate ("2013-12-04T00:29:24Z")

"self": true

}

{

"_ id": 1

"name": "192.168.1.247 purl 27018"

"health": 1

"state": 2

"stateStr": "SECONDARY"

Uptime: 461

Optime: Timestamp (1386116964, 1)

OptimeDate: ISODate ("2013-12-04T00:29:24Z")

LastHeartbeat: ISODate ("2013-12-04T00:37:07Z")

LastHeartbeatRecv: ISODate ("2013-12-04T00:37:07Z")

"pingMs": 0

"syncingTo": "192.168.1.248purl 27017"

}

{

"_ id": 2

"name": "192.168.1.250 purl 27019"

"health": 1

"state": 2

"stateStr": "SECONDARY"

Uptime: 461

Optime: Timestamp (1386116964, 1)

OptimeDate: ISODate ("2013-12-04T00:29:24Z")

LastHeartbeat: ISODate ("2013-12-04T00:37:08Z")

LastHeartbeatRecv: ISODate ("2013-12-04T00:37:08Z")

"pingMs": 1

"syncingTo": "192.168.1.248purl 27017"

}

]

"ok": 1

}

After synchronizing the information, check the logs of the other two mongodb, and you will find that

Fri Dec 6 15 connection now open 48 connection now open 48.380 [conn33] end connection 192.168.1.247

Fri Dec 6 15 connections now open 48 connections now open 48.381 [initandlisten] connection accepted from 192.168.1.247 Fraser 25635 # 35

Fri Dec 6 15 authenticate db 48 [conn35] authenticate db: local {authenticate: 1, nonce: "6d6fb8a5d540c164", user: "_ _ system", key: "51b0f27144ec17860f1ca2bd245807ce"}

Indicating normal.

You can also use the

Res1:PRIMARY > rs.isMaster (); view the information of replica set

{

"setName": "res1"

"ismaster": true

"secondary": false

"hosts": [

"192.168.1.248purl 27017"

"192.168.1.250 fret 27019"

]

"passives": [

"192.168.1.247 purl 27018"

]

"primary": "192.168.1.248purl 27017"

"me": "192.168.1.248purl 27017"

"maxBsonObjectSize": 16777216

"maxMessageSizeBytes": 48000000

LocalTime: ISODate ("2013-12-04T00:42:57.347Z")

"ok": 1

The configuration file of Replica set can also be used to change and add node information

Res1:PRIMARY > rs.conf ()

{

"_ id": "res1"

"version": 1

"members": [

{

"_ id": 0

"host": "192.168.1.248purl 27017"

"priority": 2

}

{

"_ id": 1

"host": "192.168.1.247 purl 27018"

"priority": 0

}

{

"_ id": 2

"host": "192.168.1.250 purl 27019"

}

]

}

The above steps are a building process of replica set, followed by operation and verification

5: oplog log of master-slave operation

Mongodb's replica set architecture stores writes through a log, which is called 'oplog'. Oplog is a fixed-length capped collection, which is stored in the local database to record the operation records of replica sets. The log size of Oplog is adjustable, which is specified by the-- oplogSize parameter when we start it, in MB.

Res1:PRIMARY > show dbs

Admin (empty)

Local 0.203125GB (collection with oplog, with data)

First create a library on primary. Secondary cannot read or write (the problem of reading can be solved later)

Use test1

Db.appstore.save ({'eyed nameplate, classrooms, classics, etc.)

Db.appstore.find ()

{"_ id": ObjectId ("529e7c88d4d317e4bd3eece9"), "e_name": "frank", "e_id": 1101, "class_id": 1}

After that, you will see the changes in the log logs of the other two mongodb, with an addition:

Fri Dec 6 15:56:22.338 [FileAllocator] allocating new datafile / data/mon_db/res2/test1.ns, filling with zeroes...

Fri Dec 6 15:56:22.474 [FileAllocator] done allocating datafile / data/mon_db/res2/test1.ns, size: 16MB, took 0.136 secs

Fri Dec 6 15:56:22.474 [FileAllocator] allocating new datafile / data/mon_db/res2/test1.0, filling with zeroes...

Fri Dec 6 15:56:23.850 [FileAllocator] done allocating datafile / data/mon_db/res2/test1.0, size: 64MB, took 1.376 secs

Fri Dec 6 15:56:23.852 [repl writer worker 1] build index test1.appstore {_ id: 1}

Fri Dec 6 15:56:23.852 [FileAllocator] allocating new datafile / data/mon_db/res2/test1.1, filling with zeroes...

Fri Dec 6 15:56:23.853 [repl writer worker 1] build index done. Scanned 0 total records. 0 secs

Fri Dec 6 15:56:27.006 [FileAllocator] done allocating datafile / data/mon_db/res2/test1.1, size: 128MB, took 3.153 secs

Fri Dec 6 15:56:27.007 [rsSyncNotifier] repl: old cursor isDead, will initiate a new one

If you want to view data on secondary, by default:

[root@test04] # / usr/local/mongodb/bin/mongo-- port 27018

MongoDB shell version: 2.4.8

Connecting to: 127.0.0.1:27018/test

Res1:SECONDARY > show dbs;show dbs

Admin (empty)

Local 0.203125GB

Test1 0.203125GB

Ok, you can see the test1 library we just created

Res1:SECONDARY > use test1

Switched to db test1

Res1:SECONDARY > show collections

Fri Dec 6 15 not master and slaveOk=false 59 err 10.758 error: {"$err": "not master and slaveOk=false", "code": 13435} at src/mongo/shell/query.js:128

OK, prompt error

Solution:

Res1:SECONDARY > db.getMongo () .setSlaveOk (); (included function)

Res1:SECONDARY > show collections;show collections

Appstore

System.indexes

Res1:SECONDARY > db.appstore.find (); db.appstore.find ()

{"_ id": ObjectId ("529e7c88d4d317e4bd3eece9"), "e_name": "frank", "e_id": 1101, "class_id": 1}

If you want to write data, you will prompt not master.

Db.appstore.insert ({'eyed nameplate rides 1102})

Not master

OK. In this way, the separation of reading and writing can be realized.

How to view oplog's log

Use local

Show collections

Oplog.rs

Slaves

Startup_log

System.indexes

System.replset

Is to check oplog.rs collection.

Res1:PRIMARY > db.oplog.rs.find ()

{"ts": Timestamp (1386116964, 1), "h": NumberLong (0), "v": 2, "op": "n", "ns": "", "o": {"msg": "initiating set"}}

{"ts": Timestamp (1386118280, 1), "h": NumberLong ("8972935208244346897"), "v": 2, "op": "I", "ns": "test1.appstore", "o": {"_ id": ObjectId ("529e7c88d4d317e4bd3eece9"), "e_name": "frank", "e_id": 1101, "class_id": 1}

Related explanation:

Ts indicates the timestamp of an operation

Op: indicates the type of operation, which generally includes

I insert insert

D delete deletion

Uupdate update

The Ns namespace, that is, the name of the collection name you operate on

O document (document), which is the data information you insert

View oplog metadata information on Mster:

Res1:PRIMARY > db.printReplicationInfo ()

Configured oplog size: 100MB

Log length start to end: 1316secs (0.37hrs)

Oplog first event time: Wed Dec 04 2013 08:29:24 GMT+0800 (CST)

Oplog last event time: Wed Dec 04 2013 08:51:20 GMT+0800 (CST)

Now: Wed Dec 04 2013 09:14:20 GMT+0800 (CST)

Oplog size is the total size of your oplog and is recyclable

Enable time period of log length start to end oplog log (in second)

The time when the first transaction of oplog first event time was generated

The time when the last transaction of oplog last event time was generated

Now's current time

View the data synchronization status of slave

Res1:PRIMARY > db.printSlaveReplicationInfo ()

Source: 192.168.1.247:27018

SyncedTo: Wed Dec 04 2013 08:51:20 GMT+0800 (CST)

= 1620 secs ago (0.45hrs)

Source: 192.168.1.250:27019

SyncedTo: Wed Dec 04 2013 08:51:20 GMT+0800 (CST)

= 1620 secs ago (0.45hrs)

IP and port information for Source:slave

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

Within the local database, there is not only a collection of oplog, but also a collection that records set configuration information

Db.system.replset.find ()

Or rs.conf () can be found.

The above steps are the building process of replica set and related view statements. If there are any deficiencies, please give us some advice.

Add, delete, modify and fail over replica set nodes reference: http://1413570.blog.51cto.com/1403570/1337622

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.