MongoDB Data Replication shard

MongoDB Data Replication shard

I. MongoDB introduction:

MongoDB is a high-performance, open-source, and non-pattern document-based database. It is a popular NoSql database. It can be used in many scenarios to replace traditional relational databases or key/value storage methods. It can easily be combined with JSON data. It does not support transactions, but supports automatic sharding, which plays an important role in Distributed Storage of big data.

Ii. MongoDB index type:

Single field index:

Composite Index (Multi-field index): Index multiple keys

Multi-key Index: index the key in the key and value

Spatial Index: location-based index

Text Index: full-text search

Hash index: supports exact search only

Sparse index (sparse): A sparse index can be performed only when it is discharged sequentially without indexing each value.

Iii. MongoDB replication:

MongoDB has two types of replication: Master/Slave and replica set replication. However, due to the characteristics of MongoDB, the Master-Slave replication architecture has basically been abandoned, and the common mode is replica set replication.

Features of replica set:

1. The replica set can realize automatic transfer heartbeat timeout and automatic failover (achieved through election)

2. There are at least three nodes and an odd number of nodes. You can use arbiter to participate in the election.

Special types of nodes in the replica set:

Zero-priority nodes: Cold Standby nodes are not elected as master nodes, but can participate in the election.

Hidden slave node: first, a slave node with a zero priority. It has the right to vote and will not be directly accessed by the client.

Slave node with delayed replication: A slave node with a zero priority. It cannot be selected as the master node, and the replication time lags behind the master node for a fixed duration.

Arbiter: the arbitrator. Without data, it is impossible to become the master node.

CentOS compilation and installation of MongoDB

CentOS compilation and installation of php extensions for MongoDB and mongoDB

CentOS 6 install MongoDB and server configuration using yum

Install MongoDB2.4.3 in Ubuntu 13.04

MongoDB beginners must read (both concepts and practices)

MongoDB Installation Guide for Ubunu 14.04

MongoDB authoritative Guide (The Definitive Guide) in English [PDF]

Nagios monitoring MongoDB sharded cluster service practice

Lab content:

1. MongoDB Data Replication

Experiment Model:

Lab environment:

Node1: 172.16.18.1 MongoDB centos6.5

Node2: 172.16.18.2 MongoDB centos6.5

Node3: 172.16.18.3 MongoDB centos6.5

Lab content:

First, make sure that the time of each node is consistent.

1.1 install MongoDB: install three packages on node1, node2, and node3 nodes respectively.

Mogodb installation needs: three packages

Mongodb-org-shell-2.6.4-1.x86_64.rpm

Mongodb-org-tools-2.6.4-1.x86_64.rpm

Mongodb-org-server-2.6.4-1.x86_64.rpm

Edit the configuration file of the server,/etc/mongod. conf

Logpath =/var/log/mongodb/mongod. log # log Path
Logappend = true # enable log
Fork = true
# Port = 27017 # default listening port
# Dbpath =/var/lib/mongo # default data path
Dbpath =/mongodb/data # custom data path
Pidfilepath =/var/run/mongodb/mongod. pid
# Bind_ip = 127.0.0.1 # define the bound IP address, that is, listen to the IP addresses that can be used to connect to the server. logout allows all IP addresses.
Httpinterface = true # Open a web page,
Rest = true
ReplSet = testset
ReplIndexPrefetch = _ id_only

After configuration, the configuration is sent to the other two nodes, and the data directory is created and the permissions are modified.

Mkdir/mongodb/data/-pv
Chown-R mongod. mongod/mongodb/

Start all: the startup may be slow because data needs to be initialized.

1.2 link to database

[Root @ node2 ~] # Mongo
MongoDB shell version: 2.6.4
Connecting to: test
> Rs. status ()
{
"StartupStatus": 3,
"Info": "run rs. initiate (...) if not yet done for the set ",
"OK": 0,
"Errmsg": "can't get local. system. replset config from self or any seed (EMPTYCONFIG )"
}

 

Use rs. status () to view the status. There are three nodes, but none of them have the Initialization Configuration. You need to run rs. initiate ()

 

1.3 run rs. initiate ()

> Rs. initiate ()
{
"Info2": "no configuration explicitly specified -- making one ",
"Me": "node2.bkjia.com: 27017 ",
"Info": "Config now saved locally. shocould come online in about a minute .",
"OK": 1
}
Testset: OTHER> rs. status ()
{
"Set": "testset ",
"Date": ISODate ("2014-10-12T07: 51: 58Z "),
"MyState": 1,
"Members ":[
{
"_ Id": 0,
"Name": "node2.bkjia.com: 27017 ",
"Health": 1,
"State": 1,
"StateStr": "PRIMARY ",
"Uptime": 920,
"Optime": Timestamp (1413100302, 1 ),
"OptimeDate": ISODate ("2014-10-12T07: 51: 42Z "),
"ElectionTime": Timestamp (1413100302, 2 ),
"ElectionDate": ISODate ("2014-10-12T07: 51: 42Z "),
"Self": true
}
],
"OK": 1
}
Testset: PRIMARY>

 

You can see that a node node2 is added, that is, itself, and is a primary node. And all statuses

 

1.4 add two other nodes

Testset: PRIMARY> rs. add ("node1.bkjia.com ")
{"OK": 1}
Testset: PRIMARY> rs. add ("node3.bkjia.com ")
{"OK": 1}
View with rs. status ()
Testset: PRIMARY> rs. status ()
{
"Set": "testset ",
"Date": ISODate ("2014-10-12T08: 03: 48Z "),
"MyState": 1,
"Members ":[
{
"_ Id": 0,
"Name": "node2.bkjia.com: 27017 ",
"Health": 1,
"State": 1,
"StateStr": "PRIMARY ",
"Uptime": 1630,
"Optime": Timestamp (1413101019, 1 ),
"OptimeDate": ISODate ("2014-10-12T08: 03: 39Z "),
"ElectionTime": Timestamp (1413100302, 2 ),
"ElectionDate": ISODate ("2014-10-12T07: 51: 42Z "),
"Self": true
},
{
"_ Id": 1,
"Name": "node1.bkjia.com: 27017 ",
"Health": 1,
"State": 5,
"StateStr": "STARTUP2 ",
"Uptime": 17,
"Optime": Timestamp (0, 0 ),
"OptimeDate": ISODate ("1970-01-01T00: 00: 00Z "),
"LastHeartbeat": ISODate ("2014-10-12T08: 03: 46Z "),
"LastHeartbeatRecv": ISODate ("2014-10-12T08: 03: 47Z "),
"PingMs": 224
},
{
"_ Id": 2,
"Name": "node3.bkjia.com: 27017 ",
"Health": 1,
"State": 6,
"StateStr": "UNKNOWN ",
"Uptime": 8,
"Optime": Timestamp (0, 0 ),
"OptimeDate": ISODate ("1970-01-01T00: 00: 00Z "),
"LastHeartbeat": ISODate ("2014-10-12T08: 03: 47Z "),
"LastHeartbeatRecv": ISODate ("1970-01-01T00: 00: 00Z "),
"PingMs": 905,
"LastHeartbeatMessage": "still initializing"
}
],
"OK": 1
}

Have you found that the status of the newly added nodes is incorrect? It doesn't matter. Maybe it hasn't been synchronized yet. Please try refreshing it later.

"Name": "node1.bkjia.com: 27017 ",

"StateStr": "SECONDARY ",

"Name": "node3.bkjia.com: 27017 ",

"StateStr": "SECONDARY ",

The two nodes added during refresh become secondary.

1.5 create some data on the master node

Testset: PRIMARY> use test
Switched to db test
Testset: PRIMARY> for (I = 1; I <= 1000; I ++) db. students. insert ({name: "student" + I, age :( I % 100 )})
WriteResult ({"nInserted": 1 })
Connect to the slave node.
[Root @ node1 ~] # Mongo
MongoDB shell version: 2.6.4
Connecting to: test
Welcome to the MongoDB shell.
For interactive help, type "help ".
For more comprehensive documentation, see
Http://docs.mongodb.org/
Questions? Try the support group
Http://groups.google.com/group/mongodb-user
Testset: SECONDARY> use test
Switched to db test
Testset: SECONDARY> show collections
2014-10-11T14: 52: 57.103 + 0800 error: {"$ err": "not master and slaveOk = false", "code": 13435} at src/mongo/shell/query. js: 131
# The system prompts you that you do not need to be the master node. If there is no slaveOK, you can specify slaveOK on the current node.
Testset: SECONDARY> rs. slaveOk ()
Testset: SECONDARY> show collections
Students
System. indexes
You can use rs. isMaster () to query who is the master node.
Testset: SECONDARY> rs. isMaster ()
{
"SetName": "testset ",
"SetVersion": 3,
"Ismaster": false,
"Secondary": true,
"Hosts ":[
"Node1.bkjia.com: 27017 ",
"Node3.bkjia.com: 27017 ",
"Node2.bkjia.com: 27017"
],
"Primary": "node2.bkjia.com: 27017", # Who is the master node?
"Me": "node1.bkjia.com: 27017", # Who is it?
"Max bsonobjectsize": 16777216,
"MaxMessageSizeBytes": 48000000,
& Quot; maxWriteBatchSize & quot;: 1000,
"LocalTime": ISODate ("2014-10-11T07: 00: 03.533Z "),
"MaxWireVersion": 2,
"MinWireVersion": 0,
"OK": 1
}

1.6 If the master node is offline, the slave node automatically selects the master node

Testset: PRIMARY> rs. stepDown ()
2014-10-12T17: 00: 12.869 + 0800 DBClientCursor: init call () failed
2014-10-12T17: 00: 12.896 + 0800 Error: error doing query: failed at src/mongo/shell/query. js: 81
2014-10-12T17: 00: 12.914 + 0800 trying reconnect to 127.0.0.1: 27017 (127.0.0.1) failed
2014-10-12T17: 00: 12.945 + 0800 reconnect 127.0.0.1: 27017 (127.0.0.1) OK
Testset: SECONDARY>

We can see that the primary of the master node is changed to secondary.

One of the other two nodes becomes the master node, which means automatic transfer.

The re-election conditions of replica sets include mentality information, priority, optime, and network connection.

1.7 you can also modify the priority to implement master-slave switchover.

Testset: PRIMARY> rs. conf () # view Configuration
{
"_ Id": "testset ",
"Version": 3,
"Members ":[
{
"_ Id": 0,
"Host": "node2.bkjia.com: 27017"
},
{
"_ Id": 1,
"Host": "node1.bkjia.com: 27017"
},
{
"_ Id": 2,
"Host": "node3.bkjia.com: 27017"
}
]
}
Testset: PRIMARY> cfg = rs. conf () # Save the configuration information in the Variable
{
"_ Id": "testset ",
"Version": 3,
"Members ":[
{
"_ Id": 0,
"Host": "node2.bkjia.com: 27017"
},
{
"_ Id": 1,
"Host": "node1.bkjia.com: 27017"
},
{
"_ Id": 2,
"Host": "node3.bkjia.com: 27017"
}
]
}
Testset: PRIMARY> cfg. members [1]. priority = 2 # modify the host priority of id = 1 to 2
2
Testset: PRIMARY> rs. reconfig (cfg) # apply the cfg file
2014-10-12T05: 15: 59.916-0400 DBClientCursor: init call () failed
2014-10-12T05: 15: 59.988-0400 trying reconnect to 127.0.0.1: 27017 (127.0.0.1) failed
2014-10-12T05: 16: 00.015-0400 reconnect 127.0.0.1: 27017 (127.0.0.1) OK
Reconnected to server after rs command (which is normal)
Testset: SECONDARY> # change from active to slave Node
The node id = 1 is the node1.bkjia.com host, which is changed to the primary host.
Testset: SECONDARY>
Testset: PRIMARY>

1.8. How to set up arbitration nodes

Rs. addArb (hostportstr) indicates that when a node is added, it is the arbitration node.

We remove the current node3 node.

Testset: PRIMARY> rs. remove ("node3.bkjia.com ")

Delete data under/mongodb/data, reinitialize,

Testset: PRIMARY> rs. addArb ("node3.bkjia.com ")

For more details, please continue to read the highlights on the next page:

1 2 Next Page