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

First of all, let's take a look at the above figure to see what mechanisms mongodb uses to achieve routing and fragmentation:

You can see from the figure that there are four components: mongos, config server, shard, and replica set.

Mongos, the entry of database cluster requests, all requests are coordinated through mongos. There is no need to add a route selector in the application. Mongos itself is a request distribution center, which is responsible for forwarding the corresponding data requests to the corresponding shard server. In a production environment, there is usually multiple mongos as the entry point for requests, and there is no way to prevent one of them from hanging up all mongodb requests.

Config server, as its name implies, is the configuration server that stores all database meta-information (routing, sharding) configuration. Mongos itself does not physically store sharding server and data routing information, but caches it in memory, while the configuration server actually stores the data. The first time mongos starts or shuts down and restarts, the configuration information will be loaded from config server, and then all mongos will be notified to update their status if the configuration server information changes, so that mongos can continue to route accurately. There are usually multiple config server configuration servers in a production environment because it stores sharded routing metadata, which cannot be lost! Even if one of them is hung up, the mongodb cluster will not fail as long as it is still in stock.

Shard, this is the legendary slice. It is mentioned above that no matter how powerful the machine is, it still has a ceiling, just like the army fighting a war, no matter how hard a person drinks blood bottles, he can't compete with one of the other's divisions. As the saying goes, three cobblers stand out as Zhuge Liang, and the strength of the team is highlighted at this time. The same is true on the Internet, where multiple machines cannot be done by an ordinary machine, as shown below:

A data sheet of a machine Collection1 stores 1T of data, the pressure is too great! After being divided into four machines, each machine is 256G, so the pressure on one machine is shared. Some people may ask that one machine's hard disk should be enlarged a little bit, but why should it be divided among four machines? Don't just think about storage space, the actual running database also has hard disk read and write, network IO, CPU and memory bottlenecks. As long as the sharding rule is set in the mongodb cluster, the corresponding data operation request can be automatically forwarded to the corresponding sharding machine by operating the database through mongos. In the production environment, the slicing key should be set properly, which affects how to distribute the data evenly to multiple slicing machines, so that one of the machines has divided 1T and the other machines have not, so it is better not to slice!

Replica set, we have talked about this thing in detail in the last two sections, so why are you here to join the fun again? In fact, the above four shards without replica set is an incomplete architecture, assuming that 1/4 of the data will be lost if one shard dies. Therefore, in the highly available shard architecture, you also need to build a replica set replica set for each shard to ensure the reliability of shards. The production environment is usually 2 copies + 1 arbitration.

Having said that, let's take a look at how to build a highly available mongodb cluster:

First of all, determine the number of components: 3 mongos, 3 config server, 3 shard server data, one copy and one arbitration for each shard, that is, 3 * 2 = 6. A total of 15 instances need to be deployed. These instances can be deployed on either a stand-alone machine or a single machine. We have limited test resources here, and only 3 machines have been prepared. As long as the ports are different on the same machine, take a look at the physical deployment diagram:

1. To prepare the machine, the IP is set to 192.168.5.100,192.168.5.101 and 192.168.5.102 respectively.

2. Pre-preparation "all three machines need to be operated"

# create the mongodbtest home directory and the executor directory where mongodb is stored, mkdir-p / data/mongodbtest/ data/mongodbtest/bin#, enter the execution directory to extract the mongodb package and rename cd / data/mongodbtest/bintar-zxvf mongodb-linux-x86_64-2.6.1.tgzmv mongodb-linux-x86_64-2.6.1 / mongodb-2.6.1/# to add environment variables to the / etc/profile file export PATH=$PATH:/data/mongodbtest / bin/mongodb-2.6.1/bin/# to make the configuration effective source / etc/profile

3. Medium-term preparation "all three machines need to be operated"

# create mongos log file mkdir-p / data/mongodbtest/mongos/log# establish config server data file storage directory and log directory mkdir-p / data/mongodbtest/config/data / data/mongodbtest/config/log# establish shard1 data file storage directory and log directory mkdir-p / data/mongodbtest/shard1/data / data/mongodbtest/shard1/log# establish shard2 data file storage directory and log directory mkdir-p / log / data/mongodbtest/shard2/log# establish shard3 data file storage directory and log directory mkdir-p / data/mongodbtest/shard3/data / data/mongodbtest/shard3/log

4. Medium-term preparation for "planning ports"

Because a machine needs to deploy mongos, config server, shard1, shard2, and shard3 at the same time, it needs to be distinguished by port. This port can be defined freely. In this article, mongos is 20000, config server is 21000, shard1 is 22001, shard2 is 22002, and shard3 is 22003.

5. Start the corresponding service "service startup" in sequence

# conf servermongod that starts three machines separately-- configsvr-- dbpath / data/mongodbtest/config/data-- port 21000-- logpath / data/mongodbtest/config/log/config.log-- fork# starts the mongosmongos of three machines respectively-- configdb 192.168.5.100 configdb 21000192.168.5.101dbpath 21000-- port 20000-- logpath / data/mongodbtest/mongos/log/mongos.log-- fork# configuration share1 copy set In order to start quickly and save the storage space of the test environment Nojournal is added here to turn off log information. There is no need to initialize such a large redo log in our test environment. Oplogsize is also set to reduce the size of the local file. Oplog is a fixed-length capped collection that exists in the "local" database and is used to log Replica Sets operations. Note that the setting here is to test mongod-- shardsvr-- replSet shard1-- port 22001-- dbpath / data/mongodbtest/shard1/data-- logpath / data/mongodbtest/shard1/log/shard1.log-- fork-- nojournal-- oplogSize 1 configure the copy set of share2. In order to quickly start and save storage space in the test environment, nojournal is added here to close the log information. There is no need to initialize such a large redo log in our test environment. Oplogsize is also set to reduce the size of the local file. Oplog is a fixed-length capped collection that exists in the "local" database and is used to log Replica Sets operations. Note that the setting here is to test mongod-- shardsvr-- replSet shard2-- port 22002-- dbpath / data/mongodbtest/shard2/data-- logpath / data/mongodbtest/shard2/log/shard2.log-- fork-- nojournal-- oplogSize 1 configure the copy set of share3. In order to quickly start and save storage space in the test environment, nojournal is added here to close the log information. There is no need to initialize such a large redo log in our test environment. Oplogsize is also set to reduce the size of the local file. Oplog is a fixed-length capped collection that exists in the "local" database and is used to log Replica Sets operations. Note that the setting here is to test mongod-- shardsvr-- replSet shard3-- port 22003-- dbpath / data/mongodbtest/shard3/data-- logpath / data/mongodbtest/shard3/log/shard3.log-- fork-- nojournal-- oplogSize 10

6. Configure each shard replica set "configuration replica set"

# Log in to the 192.168.5.100 shard1 mongo instance to set the share1 replica set mongo 192.168.5.100:22001use adminconfig = {_ id: "shard1", members: [{_ id:0,host: "192.168.5.100 mongo 192.168.5.100:22001use adminconfig 22001"}, {_ id:1,host: "192.168.5.101 mongo 192.168.5.100:22001use adminconfig 22001"}, {_ id:2 Host: "192.168.5.102 rs.initiate 22001", arbiterOnly:true}]} # initialize replica set configuration rs.initiate (config) # Log in to the 192.168.5.100 shard2 mongo instance to set the share2 replica set mongo 192.168.5.100:22002use adminconfig = {_ id: "shard2", members: [{_ id:0,host: "192.168.5.100 mongo 192.168.5.100:22002use adminconfig 22002"}, {_ id:1,host: "192.168.5.101 mongo 192.168.5.100:22002use adminconfig 22002"}, {_ id:2 Host: "192.168.5.102 rs.initiate 22002", arbiterOnly:true}]} # initialize replica set configuration rs.initiate (config) # Log in to the shard3 mongo instance of 192.168.5.100 to set the share3 replica set connection mongo 192.168.5.100:22003use adminconfig = {_ id: "shard3", members: [{_ id:0,host: "192.168.5.100 mongo 192.168.5.100:22003use adminconfig 22003"}, {_ id:1,host: "192.168.5.101 mongo 192.168.5.100:22003use adminconfig 22003"}, {_ id:2 Host: "192.168.5.102 rs.initiate 22003", arbiterOnly:true}]} # initialize replica set configuration rs.initiate (config)

7. Currently, mongodb configuration server, routing server and sharding server are built. However, sharding mechanism cannot be used when the application connects to mongos routing server. Sharding configuration needs to be set in the program to make sharding take effect.

# Connect mongosmongo 127.0.0.1 1db.runCommand 2000 please add a comma here with user admin;# concatenated router and sharded replica set 1db.runCommand ({addshard: "shard1/192.168.5.100:22001192.168.5.101:22001192.168.5.102:22001"}); # concatenated router and sharded replica set 2user admin Db.runCommand ({addshard: "shard2/192.168.5.100:22002192.168.5.101:22002192.168.5.102:22002"}); # concatenated router and sharded replica set 3user admin;db.runCommand ({addshard: "shard3/192.168.5.100:22003192.168.5.101:22003192.168.5.102:22003"}); # View sharding server configuration db.runCommand ({listshards: 1}) # content output {"shards": [{"_ id": "shard1", "host": "shard1/192.168.5.100:22001192.168.5.101:22001"}, {"_ id": "shard2" "host": "shard2/192.168.5.100:22002192.168.5.101:22002"}, {"_ id": "shard3" "host": "shard3/192.168.5.100:22003192.168.5.101:22003"}], "ok": 1}

Because 192.168.5.103 is the arbitration node for each shard copy set, the results are not listed above.

8. At present, the configuration service, routing service, sharding service and replica set service have all been connected in series, but our goal is to insert data and the data can be sliced automatically.

Connect to the mongos and prepare to make the specified database and the specified collection shard effective.

# specify the effective db.runCommand of testdb sharding ({enablesharding: "testdb"}); # specify the collection and key db.runCommand in the database that need sharding ({shardcollection: "testdb.table1", key: {id: 1}})

9. The test cycle inserts 200000 pieces of data to see the effect.

For (var I = 1) I db.printShardingStatus () db.printShardingStatus ()-- ShardingStatus-sharding version: {"_ id": 1, "version": 4, "minCompatibleVersion": 4, "currentVersion": 5, "clusterId": ObjectId ("5c79632ca881001461d466cb")} shards: {"_ id": "shard1" "host": "shard1/192.168.5.100:22001192.168.5.101:22001"} {"_ id": "shard2", "host": "shard2/192.168.5.100:22002192.168.5.101:22002"} {"_ id": "shard3" "host": "shard3/192.168.5.100:22003192.168.5.101:22003"} databases: {"_ id": "admin", "partitioned": false, "primary": "config"} {"_ id": "testdb", "partitioned": true "primary": "shard1"} testdb.table1 shard key: {"id": 1} chunks: shard3 5 shard1 5 shard2 6 # here is the chunk mentioned in the previous article {"id": {"$minKey": 1}}-- > {"id": 1} on: shard3 Timestamp (8 0) {"id": 1}-- > {"id": 4836} on: shard3 Timestamp (11,0) {"id": 4836}-- > {"id": 79734} on: shard1 Timestamp (11,1) {"id": 79734}-- > > {"id": 155925} on: shard3 Timestamp (5) 1) {"id": 155925}-- > {"id": 267774} on: shard3 Timestamp (4,2) {"id": 267774}-- > {"id": 435549} on: shard1 Timestamp (6,2) {"id": 435549}-- > > {"id": 603325} on: shard1 Timestamp (6) 4) {"id": 603325}-- > {"id": 687213} on: shard3 Timestamp (12,0) {"id": 687213}-- > {"id": 771101} on: shard2 Timestamp (12,1) {"id": 771101}-- > > {"id": 943497} on: shard2 Timestamp (8) 2) {"id": 943497}-- > {"id": 1093292} on: shard2 Timestamp (11,4) {"id": 1093292}-- > {"id": 1168190} on: shard2 Timestamp (11,6) {"id": 1168190}-- > > {"id": 1279045} on: shard2 Timestamp (11 7) {"id": 1279045}-- > {"id": 1624908} on: shard2 Timestamp (9,2) {"id": 1624908}-- > {"id": 1949761} on: shard1 Timestamp (11 2) {"id": 1949761}-> {"id": {"$maxKey": 1}} on: shard1 Timestamp (11,3) {"_ id": "test", "partitioned": false, "primary": "shard1"} {"_ id": "dbtest", "partitioned": false "primary": "shard1"} {"_ id": "noshare", "partitioned": false, "primary": "shard3"} {"_ id": "noshare2", "partitioned": true "primary": "shard3"} noshare2.table2 shard key: {"id": 1} chunks: shard2 1 shard3 2 shard1 1 {"id": {"$minKey": 1}}-- > {"id": 100000} on: shard2 Timestamp (3 0) {"id": 100000}-- > {"id": 137449} on: shard3 Timestamp (3,2) {"id": 137449}-- > {"id": 200000} on: shard3 Timestamp (3) 3) {"id": 200000}-- > {"id": {"$maxKey": 1}} on: shard1 Timestamp (2,0) {"_ id": "conf", "partitioned": false, "primary": "shard3"}

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.