Set up highly available MongoDB cluster (above): MongoDB configuration and copy set

The traditional relational database has good performance and stability, at the same time, the historical test, many excellent database precipitation, such as MySQL. However, with the explosive growth of data volume and the increasing number of data types, many traditional relational database extensions have erupted. NoSQL database has emerged. However, different from the previous use of many NoSQL have their own limitations, which also led to the difficult entry. Here we share with you Yanlan Lan, director of Shanghai Science and Technology Innovation Bowen blog - how to build efficient MongoDB cluster.

The following is the original

In the era of big data, the traditional relational database to be able to higher service must solve the high concurrency read and write, mass data efficient storage, high scalability and high availability of these problems. However, Nosql was born because of these problems.

NOSQL has these advantages:

Large amount of data, you can store large amounts of data through cheap server, easy to get rid of the traditional mysql single table storage size limit.

High scalability, Nosql removed the relational database relational characteristics, it is easy to scale-out, get rid of the old vertical expansion of the criticism.

High performance, Nosql gets data in a simple key-value way, very fast. There is noSQL Cache record-level, is a fine-grained Cache, so NoSQL at this level will be much higher performance.

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

High availability, NoSQL is not affected in the performance of the situation, you can easily achieve high availability architecture. For example mongodb through mongos, mongo slice can quickly configure the high availability configuration.

In the nosql database, most of the queries are key-value (key, value) way. MongoDB is a product between a relational database and a non-relational database, which is most like a relational database among non-relational databases. Support for object-oriented query language, almost to achieve a similar relational database single table query most of the features, but also supports the indexing of data. So this is very convenient, we can use MongoDB sql operation, migrating from a relational database, developers will greatly reduce the cost of learning. If the bottom of the sql API to do a layer of packaging, the development can not feel the difference between mongodb and relational database. Similarly MongoDB is also claimed to be able to quickly build a highly available scalable distributed cluster, there are many articles to build the network, we also need to find a lot of things to change when building, so my actual steps recorded for memo. Let's see how to build this stuff step by step.

First, mongodb single instance. This configuration is only suitable for simple development, production use not, because the single node hangs the entire data service hanging, as shown below.

Although it can not be used for production, this model can be quickly set up to start, and can use mongodb command to operate the database. Listed below are the steps to install single-node mongodb under linux

1. Create mongodb test folder

2. Download mongodb installation package

3 start a single instance mongodb

Output log below, success!

[initandlisten] db version v2.4.6

...

[initandlisten] waiting for connections on port 27017

[websvr] admin web console waiting for connections on port 28017

mongodb comes with a default web access interface, through the form of IP + port can be accessed.

http://192.168.0.1:28017/

Second, the master-slave mode. Mysql database is widely used when you use the main backup node after the dual-hung from the node can take over the host to continue to service. So this model is much better than a single node high availability.

Here's how to step by step to build a master-slave mongodb copy node:

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

2. Download mongodb installation package separately. Create a folder on the 192.168.0.1 /data/mongodbtest/master,192.168.0.2 Create folder / data / mongodbtest / slave.

3. In 192.168.0.1 start mongodb master node program. Note the back of this "-master" parameter, marking the main node.

mongod -dbpath / data / mongodbtest / master-master

Output log below, success!

[initandlisten] MongoDB starting: pid = 18285 port = 27017 dbpath = / data / mongodbtest / master master = 1

# Log shows the main node parameters

[initandlisten] options: {dbpath: "/ data / mongodbtest / master", master: true}

...

[initandlisten] waiting for connections on port 27017

Start the mongodb slave program at 192.168.0.2. Key configuration, specify the master node ip address and port-source 192.168.0.1:27017 and mark the slave-source parameter.

mongod -dbpath / data / mongodbtest / slave -slave -source 192.168.0.1:27017

Output log below, success!

[initandlisten] MongoDB starting: pid = 17888 port = 27017 dbpath = / data / mongodbtest / slave slave = 1

...

# Log shows the slave node parameters

[initandlisten] options: {dbpath: "/ data / mongodbtest / slave", slave: true, source: "192.168.0.1:27017"}

...

[initandlisten] waiting for connections on port 27017

# The log shows that the slave node replicates data from the master node synchronously

[replslave] repl: from host: 192.168.0.1: 27017

5. Test master-slave replication.

Connect to the terminal on the primary node:

You can see the host's synchronization log

[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 the data from the host.

mongo 127.0.0.1

View the current database.

After the query data has been synchronized. Take a look at the log and found that the data from the host did indeed sync from the host.

Check the service status

To this master from the structure mongodb set up.

Failover test, now two servers if the main server hangs up, from the server can be normal operation?

A first test from the server can be regarded as the main server, that is, to write from the server to synchronize the main server? Connect mongodb at 192.168.0.2.

You can see mongodb from the node can not provide write operations, can only provide read operations.

b. If you hang from the server, the main server can also provide services. If the main server hangs from the server automatically become writable.

have a test!

First kill the original mongodb master server.

Test whether the server can write. Connect mongodb test on 192.168.0.2.

Looks like the server does not automatically take over from the main server function, only manual processing!

Stop from the server, start the original data file and add the main server logo.

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

success!

Multiple slave nodes. Now just a database server also provides write and read, there will be a bottleneck in the machine bearing. We still remember mysql read and write separation? Put 20% of the write to the master node, 80% read from the node to reduce the load on the server. However, most applications are the pressure of read operations, a slave stress can not load, you can change from a node to multiple nodes. That mongodb master more from the support? The answer is yes.

In order to facilitate testing, in the 192.168.0.2 and then create a folder / data / mongodbtest / slave1 as another slave server. Start slave2 service,

After successful start mongodb connection test:

Set up this master-slave replication system is not very robust, it is not. . . Look at these questions?

The main node linked automatically switched connection? Currently need to manually switch.

The main node write pressure is too large how to solve?

Each node from the above data is a full copy of the database from the node pressure will not be too large?

Even if the implementation of routing from the node routing strategy can be automatically extended?

There are so many questions, there are other solutions? Please visit the next page.