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

Master-slave pattern architecture diagram:

Master-slave configuration installation:

10.10.20.160 (master)-> 10.10.20.161 (slave)

Master:

Tar zxvf mongodb-linux-x86_64-2.2.2.tgz

Ln-s mongodb-linux-x86_64-2.2.2 mongodb

Mkdir-p / u01/mongodata/db/geomaster/

Mkdir-p / u01/mongodata/log/

/ usr/local/mongodb/bin/mongod-fork-port40000-dbpath / u01/mongodata/db/geomaster/-logpath/u01/mongodata/log/geomaster.log-logappend-master

Slave:

Tar zxvf mongodb-linux-x86_64-2.2.2.tgz

Ln-s mongodb-linux-x86_64-2.2.2 mongodb

Mkdir-p / u01/mongodata/db/geomaster/

Mkdir-p / u01/mongodata/log/

/ usr/local/mongodb/bin/mongod-- fork-- port40000-- dbpath / u01/mongodata/db/geoslave/-- logpath / u01/mongodata/log/geosalve.log-logappend-- slave-- source 10.10.20.160 Vol 40000

Parameter description:

Mongod is the server program of mongoDB, and the main startup parameters are as follows

-- fork fork produces a daemon process on the server side

-- port server listening port

-- dbpath data file directory

-- logpath log file path

-- logappend logs are appended to the log file instead of overwriting writes

The parameters that can be set by mongod in master-slave case are:

-- master master mode

-- salve salve mode

-- specify master in source salve mode

-- only replicates only one database

-- salvedelay slave library synchronizes latency from master library

-- autoresync if the slave data is not synchronized, it will be synchronized automatically.

Test after master-slave configuration:

Master:

/ usr/local/mongodb/bin/mongo-port 40000

Use test

Db.createCollection ("table1")

Db.test.table1.insert ({tag: "test"})

Db.test.table1.find ()

Slave:

/ usr/local/mongodb/bin/mongo-port 40000

Db.test.table1.find ()

If there is data, the synchronization is successful.

After synchronization, you can also see the thread of slave with db.currentOp () on master.

Master-slave related commands:

Db.isMaster (): both master and slave can be executed. Use this command to determine whether it is master or not.

Db.getReplicationInfo (): execute on the master to get master-slave information

Db.printReplicationInfo (): both master and slave can be executed to obtain master-slave information

Db.printSlaveReplicationInfo ();: execute from the library to view the master-slave delay

Synchronization failure handling method:

If synchronization fails, use the following command to synchronize all data:

If there is a problem with synchronization, the log will be recorded as follows

TueFeb 19 16:31:45 [replslave] all sources dead: data too stale haltedreplication, sleeping for 5 seconds

They all try again every 5 seconds and keep retrying, so if you want to solve the problem, you can only synchronize them all by executing the following command

Use admin

Db.runCommand ({"resync": 1})

You can also add the-- autoresync parameter when starting the slave library

Synchronization principle:

Synchronization is when changes to data are recorded in oplog on master, and then slave grabs the oplog execution of master. From this point of view, the function of Oplog and the mysql-bin of mysql. The function is similar. Mysql-bin exists as a binary log, but oplog exists as a table of mongodb, which is called oplog.$main in the local library table, which is written in a loop, so you don't have to clean it up regularly.

Modify the oplog size:

If we do not set the size of the oplog when we start the mongodb service for the first time, then its default value will be 5% of the hard disk where it is located. Then if we want to change the size, we must restart, and then set oplogsize at startup. However, there is a small problem, because the previous oplog already exists, so the startup will report an error after changing the size. Tue Feb 19 15:43:19 [initandlisten] cmdline oplogsize (10) different than existing (1779) The solution is to delete the local.* under the mongodb data directory, see: http://api.mongodb.org/wiki/current/Halted%20Replication.html

Because the oplog is rebuilt after deletion, and the time point information of the slave is smaller than the start time of the oplog on the master, the slave library can only do full synchronization to continue synchronization. But there is a problem, if there is a lot of data in the main database, it is very time-consuming to do a full synchronization, and the data is not lost. So here's a little trick:

Turn off the mongo service for slave

After we delete local.* on Master, do not rush to start the service. Use the date command of linux to change the system time so that the time is less than the last time of synchronization on slave, that is, the time seen when slave executes db.printSlaveReplicationInfo ().

Then the master library and slave library can continue to synchronize.

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.