How to deploy a highly available MongoDB cluster-1024programmer

In the era of big data, traditional relational databases must solve the problems of high concurrent reading and writing, efficient storage of massive data, high scalability and high availability in order to provide higher services. But it is because of these problems that Nosql was born.

NOSQL has these advantages:

Large data volume, you can store a large amount of data through cheap servers, and easily get rid of the traditional mysql single-table storage level limit.

High scalability, Nosql removes the relational features of relational databases, it is easy to expand horizontally, and gets rid of the criticism of vertical expansion in the past.

High performance, Nosql obtains data through a simple key-value method, which is very fast. In addition, NoSQL’s Cache is record-level, which is a fine-grained Cache, so NoSQL has much higher performance at this level.

Flexible data model, NoSQL does not need to create fields for the data to be stored in advance, and can store custom data formats at any time. In a relational database, adding and deleting fields is a very troublesome thing. If it is a table with a very large amount of data, adding fields is simply a nightmare.

High availability, NoSQL can easily implement a high-availability architecture without affecting performance. For example, mongodb can quickly configure a high-availability configuration through mongos and mongo fragmentation.

In the nosql database, most queries are in the form of key-value pairs (key, value). MongoDB is a product between relational databases and non-relational databases, and is the most similar to relational databases among non-relational databases. It supports an object-oriented query language, and can almost realize most of the functions similar to the single-table query of a relational database, and also supports indexing of data. So this is very convenient. We can use sql to operate MongoDB, and migrate from a relational database, and the learning cost of developers will be greatly reduced. If the underlying sql
The API is encapsulated in one layer, and the development can basically not feel the difference between mongodb and relational database. Similarly, MongoDB also claims to be able to quickly build a highly available and scalable distributed cluster. There are many articles about building it on the Internet. When we build it, we still need to find and modify a lot of things, so we record our actual steps for memo. Let’s see how to build this stuff step by step.

1. Mongodb single instance. This configuration is only suitable for simple development, but not for production use, because a single node hangs up the entire data service, as shown in the figure below.

Although it cannot be used in production, this mode can be quickly built and started, and the database can be operated with mongodb commands. The steps to install single-node mongodb under linux are listed below

1. Create a mongodb test folder

1# Store the entire mongodb file
2 mkdir -p /data/mongodbtest/single
3
4# Store mongodb data files
5mkdir -p /data/mongodbtest/single/data
6
7#Enter the mongodb folder
8 cd /data/mongodbtest/single

1wget
http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.4.6.tgz
2
3#Decompress the downloaded compressed package
4tar xvzf mongodb-linux-x86_64-2.4.6.tgz
5
6#Enter the mongodb program execution folder
7 cd mongodb-linux-x86_64-2.4.6/bin/

2. Download the mongodb installation package

3. Start single instance mongodb

1	mongod –dbpath /data/mongodbtest/single/data

The output log is as follows, success!

[initandlisten] db version v2.4.6
…..
[init and listen] waiting for connections on
port 27017
[websvr] admin web console waiting for connections on port
28017

By default, mongodb provides a web access interface, which can be accessed in the form of IP + port.

http://192.168.0.1:28017/

Second, master-slave mode. It is widely used when using the mysql database. After the dual-machine backup is adopted, the master node hangs up and the slave node can take over from the master to continue the service. So this mode 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 step by step:

1. Prepare two machines 192.168.0.1 and 192.168.0.2. 192.168.0.1
As master node, 192.168.0.2 as slave node.

2. Download the mongodb installation package separatelyyncedTo: Sun
Nov 17 2013 16:04:02 GMT+0800 (CST)
= -54 secs ago (-0.01hrs)

So far, the mongodb of the master-slave structure has been built.

Failover test, if the master server of the two servers is down, can the slave server work normally?

a. First test whether the slave server can be used as the master server, that is, can writing to the slave server synchronize the master server?

Connect mongodb on 192.168.0.2.

1 2 3	mongo 127.0.0.1:27017 > db.testdb.insert({“test3″:”testval3”}); not master

It can be seen that the slave node of mongodb cannot provide write operations, only read operations.

b. If the slave server hangs up, the master server can still provide services. If the master server hangs up, can the slave server become writable automatically.
have a test!

First kill the original mongodb master server.

1	kill -3 `ps -ef\|grep mongod\|grep -v grep\|awk ‘{print $2}’`

Test whether the slave server is writable. Connect mongodb test on 192.168.0.2.

1 2	> db.testdb.insert({“test3″:”testval3”}); not master

It seems that the slave server does not have the function of automatically taking over from the master server, only manual processing!

Stop the slave server, start and add the master server mark in the original data file.

1	mongod –dbpath /data/mongodbtest/slave –master

Wait until the boot is successful (a bit long). Connect on 192.168.0.2

1 2 3	> db.testdb.find(); { “_id” : ObjectId(“5288629e9b0318be4b20bd4c”), “test1” : “testval1” } { “_id” : ObjectId(“528862d69b0318be4b20bd4d”), “test2” : “testval2” }

success!

Multiple slave nodes. Now it’s just a database server that provides both writing and reading, and there will be a bottleneck in machine hosting. Do you still remember the separation of reading and writing in mysql? Putting 20% of the writes on the master node and 80% of the reads on the slave nodes can share and reduce the load on the server. But most applications are under the pressure of read operations. A slave node can’t bear the pressure, and one slave node can be turned into multiple nodes. Can one master and multiple slaves of mongodb support it? The answer is yes.

For the convenience of testing, create another folder /data/mongodbtest/slave2 on 192.168.0.2
As another slave server.
Start the slave2 service,

1	mongod –dbpath /data/mongodbtest/slave1 –slave –port 27017 –source 192.168.0.1:27017.

After successful startup, pass the mongodb connection test:

1 2 3	> db.testdb.find(); { “_id” : ObjectId(“5288629e9b0318be4b20bd4c”), “test1” : “testval1” } { “_id” : ObjectId(“528862d69b0318be4b20bd4d”), “test2” : “testval2” }