Build high usable MongoDB cluster (i)--Configure Mongodb__mongodb

reproduced from: http://www.lanceyan.com/tech/mongodb/mongodb_cluster_1.html build high usable MongoDB cluster (i)--Configure MongoDBPosted on 171 months, 2013 by Lanceyan | 8 Reviews

In the age of large data, the traditional relational database should be able to higher service must solve the problem of high concurrent read and write, massive data storage, high scalability and high availability. But it is because of these problems that NoSQL was born.

NoSQL has these advantages:

large amount of data , you can store large amounts of data through a low-cost server, easily get rid of the traditional MySQL single table storage scale limit.

High Scalability , NoSQL removed the relational database relationship characteristics, it is easy to spread horizontally, free from the past is always vertical expansion of the criticism.

High Performance , NoSQL through a simple key-value way to get data, very fast. There are NoSQL cache is record-level, is a fine-grained cache, so the NoSQL on this level will be a lot higher performance.

a flexible data model that allows you to store custom data formats at any time without having to establish fields for the data to be stored NoSQL. And in the relational database, adding and deleting fields is a very troublesome thing. If it's a very large amount of data, adding fields is a nightmare.

highly Available , NoSQL can easily implement highly available architectures without impacting performance. For example, MongoDB can quickly configure a highly available configuration via MONGOs, MONGO slices.

In the NoSQL database, most queries are the way of key value pairs (key, value). MongoDB is a product between relational and non relational databases, and is the most like relational database in a relational database. Supports an object-oriented query language that can achieve most of the functionality of similar relational database single table queries and also supports indexing of data. So this is very convenient, we can use SQL Operations MongoDB, from the relational database migration, the developer learning costs will be greatly reduced. If you do a layer of encapsulation of the underlying SQL API, development will basically not feel the difference between MongoDB and relational databases. The same MongoDB is also claimed to be able to quickly build a highly available scalable distributed cluster, there are many articles on the Internet, in our building when we need to find a lot of changes, so put their own actual steps to record down in order to forget. Let's take a look at how to build this stuff step-by-step.

First, MongoDB Single instance . This configuration is only suitable for easy development use, the production is not used, because the single node hangs the entire data business all hung, the following figure.

Although not available for production, this pattern can be quickly set up and able to operate the database with MONGODB commands. The following is a list of steps to install a single node MongoDB under Linux

1, establish the MongoDB Test folder #存放整个mongodb文件
Mkdir-p/data/mongodbtest/single

#存放mongodb数据文件
Mkdir-p/data/mongodbtest/single/data

#进入mongodb文件夹
Cd/data/mongodbtest/single

2. Download MongoDB installation package wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.4.6.tgz

#解压下载的压缩包
Tar xvzf mongodb-linux-x86_64-2.4.6.tgz

#进入mongodb程序执行文件夹
CD Mongodb-linux-x86_64-2.4.6/bin/

3. Start Single instance MongoDB Mongod--dbpath/data/mongodbtest/single/data

The output log is as follows, successful.

[Initandlisten] DB version v2.4.6
........
[Initandlisten] Waiting for connections on port 27017
[WEBSVR] Admin Web console waiting for connections on port 28017

The MongoDB default is provided with a web-access interface that can be accessed via IP + port form.

http://192.168.0.1:28017/

second, master-slave mode . The use of MySQL database is widely used, the two-computer backup after the main node hung off from the node can be replaced by the host service. So this pattern is much better than the high availability of a single node.

Let's take a look at how to build a MongoDB master-slave replication node in one step: 1, prepare two machines 192.168.0.1 and 192.168.0.2. 192.168.0.1 as the primary node , 192.168.0.2 as the from node . 2, download the MongoDB installation package separately. Create a folder on 192.168.0.1/data/mongodbtest/master, 192.168.0.2 Create a folder/data/mongodbtest/slave. 3, in 192.168.0.1 Start MongoDB Master node program. Note the following " –master " parameter, indicating the master node.

Mongod–dbpath/data/mongodbtest/master–master

The output log is as follows, successful.

[Initandlisten] MongoDB starting:pid=18285 port=27017 Dbpath=/data/mongodbtest/master master=1
#日志显示主节点参数
[Initandlisten] Options: {dbpath: "/data/mongodbtest/master", master:true }
........
[Initandlisten] Waiting for connections on port 27017

4, in the 192.168.0.2 start MongoDB from the node program. Critical configuration, specify the master node IP address and port –source 192.168.0.1:27017 and Mark –source parameters from the node.

Mongod–dbpath/data/mongodbtest/slave –slave–source 192.168.0.1:27017

The output log is as follows, successful.

[Initandlisten] MongoDB starting:pid=17888 port=27017 Dbpath=/data/mongodbtest/slave slave=1
........
#日志显示从节点参数
[Initandlisten] Options: {dbpath: "/data/mongodbtest/slave", slave:true, source: "192.168.0.1:27017″}"
........
[Initandlisten] Waiting for connections on port 27017
#日志显示从节点 replicate data from the primary node
[Replslave] Repl:from host:192.168.0.1:27017

5, test master copy.

Connecting to terminals on the primary node: MONGO 127.0.0.1

#建立test database.
Use test;

Inserts data into the TestDB table.
> Db.testdb.insert ({"Test1": "Testval1"})

Query TestDB data to see if it is successful.
> Db.testdb.find ();
{"_id": ObjectId ("5284e5cb1f4eb215b2ecc463"), "test1": "Testval1"}

You can see the synchronization log for the host

[Initandlisten] Connection accepted from 192.168.0.2:37285 #3 (2 connections now OPEN)
[slavetracking] Update local.slaves query: {_id:objectid (' 5284e6268ed115d6238bdb39′), config: {host: " 192.168.0.2:35271″, upgradeneeded:true}, NS: "Local.oplog. $main"} update: {$set: {syncedto:timestamp 1384441570000|1 } nscanned:1 nupdated:1 fastmod:1 keyupdates:0 Locks (micros) w:132015 132ms

Check data from the host.

MONGO 127.0.0.1

View the current database. > Show DBS;
Local 0.203125GB
Test 0.203125GB

Use test;
Db.testdb.find ();
{"_id": ObjectId ("5284e5cb1f4eb215b2ecc463"), "test1": "Testval1"}

The data has been synchronized after the query. Then look at the log and find that the data was actually synchronized from the host. Thu Nov 23:05:13 [Replslave] Repl:checkpoint applied
Thu Nov 23:05:13 [Replslave] Repl:syncedTo:Nov-23:08:10 5284e75a:1

View service status > Db.printreplicationinfo ();
This is a slave, printing slave replication info.
source:192.168.0.1:27017
Syncedto:sun Nov 2013 16:04:02 gmt+0800 (CST)
= -54 secs ago ( -0.01hrs)

To this master and subordinate structure of the MongoDB built.

failover Test , now two servers if the primary server is hung up, from the server can function correctly. A, the first test from the server can be used as a master server, that is, to write from the server can synchronize the master server.

Connect the MongoDB on the 192.168.0.2. MONGO 127.0.0.1:27017
> Db.testdb.insert ({"Test3": "Testval3"});
Not master

You can see that the MongoDB from the node is not able to provide write operations and can only provide read operations.

b, if you hang off the server, the primary server can also provide services. If the primary server hangs out from the server can automatically become writable.
Test it.

First kill the original MongoDB primary server. Kill-3 ' Ps-ef | grep Mongod | Grep-v grep | awk ' {print $} '

Whether the test can be writable from the server. Connect the MongoDB test on the 192.168.0.2. > Db.testdb.insert ({"Test3": "Testval3"});
Not master

It appears that there is no automatic replacement of the primary server from the server, only manual processing.

Stop from the server, start in the original data file and add the master server label. Mongod--dbpath/data/mongodbtest/slave--master

Wait until the startup succeeds (a little longer). Connect MONGO 192.168.0.2:27017 on 192.168.0.2

。 > Db.testdb.find ();
{"_id": ObjectId ("5288629e9b0318be4b20bd4c"), "test1": "Testval1"}
{"_id": ObjectId ("528862d69b0318be4b20bd4d"), "test2": "Testval2"}

Success.

multiple from Nodes . Now it's just a database server that provides both write and read, and there are bottlenecks in machine hosting. Do you remember the separation of reading and writing in MySQL? 20% of the write to the master node, 80% of the read to the from the node allocation to reduce the load on the server. But most applications are the pressure from the read operation, a load from the node can not be loaded, one from the node into multiple nodes. That MongoDB can support more than a master. The answer is yes.

To facilitate testing, create a second folder on the 192.168.0.2/data/mongodbtest/slave1 as another slave server.
Start the Slave2 service, Mongod--dbpath/data/mongodbtest/slave1--slave--port 27017.

After the successful launch through the MONGODB connection test: > Db.testdb.find ();
{"_id": ObjectId ("5288629e9b0318be4b20bd4c"), "test1": "Testval1"}
{"_id": ObjectId (