MongoDB master-Slave Copy instance explanation _mongodb

Master-slave replication can be used to do database backup, failure recovery, read and write separation.

This experiment uses MONGODB 3.2 version, we first look at Mongod's help

[Root@localhost mongodb]# Mongod--help .....
Omit
master/slave options (old; replica sets instead):
 --master               Master mode
 --slave slave                mode
 --source Arg when             slave:specify Master as 
                    <server:port>
 --only arg when              slave:specify a Single database to 
                    replicate
 --slavedelay arg           specify delay (in seconds) to is used when 
                    applying MAS ter Ops to slave
 --autoresync             automatically resync if slave the data is 
                    stale
..... Omitted

Master-slave replication is already an outdated feature and is currently replaced with a replica set. Master-slave replication and replica set differences, can be simply understood as master-slave replication can not automatically failover, the cluster in the replica set after the main node down, you can use the election strategy to select a new master node out. Implement automatic failover.

From a node can be one, or multiple.

Here we do a master-slave replication on a single machine using two instances.

Create a database directory

[Root@localhost data]# mkdir-p/application/mongodb/data/{master,slave}

2. Start Master Instance

[Root@localhost data]# mongod--dbpath=/application/mongodb/data/master/--port 27017

--master Specifies that this instance is the primary server.

3. Start from instance

[Root@localhost ~]# mongod--dbpath=/application/mongodb/data/slave/--port 27018--slave--source 127.0.0.1:27017

--slave Specifies that the instance is from the server
--source specify who is the primary server?

After the server is started, that is, constantly want the primary server to request synchronization data

2016-01-16t10:30:10.208+0800 I REPL   [replslave] syncing from host:127.0.0.1:27017
2016-01-16t10:30:11.210+ 0800 i REPL   [replslave] syncing from host:127.0.0.1:27017 2016-01-16t10:30:12.211+0800
I REPL   [Replslave] Syncing from host:127.0.0.1:27017
2016-01-16t10:30:14.196+0800 I REPL   [Replslave] syncing from host : 127.0.0.1:27017
2016-01-16t10:30:15.197+0800 I REPL   [replslave] syncing from host:127.0.0.1:27017
2016-01-16t10:30:16.199+0800 I REPL   [replslave] syncing from host:127.0.0.1:27017
2016-01-16t10:30:17.202 +0800 i REPL   [replslave] syncing from host:127.0.0.1:27017
2016-01-16t10:30:18.204+0800 i REPL   [ Replslave] Syncing from host:127.0.0.1:27017
2016-01-16t10:30:19.207+0800 I REPL   [Replslave] syncing from host:127.0.0.1:27017
2016-01-16t10:30:20.209+0800 I REPL   [replslave] syncing from host:127.0.0.1:27017

At this point, master-slave replication has been configured to complete, is so simple.

There are three more parameters to explain from the server.

--only Arg

To specify that only one particular database is replicated from a node (by default, all databases are replicated)

--slavedelay Arg

Specifies how long to defer synchronization from the server, which is useful when the primary server has a human error. There was no sync error from the server when an error was found. This prevents errors from occurring.

--autoresync

If the data from the node breaks from the primary node (the data in some oplog is overwritten), then the option is to automatically synchronize the database from the node from the beginning.

Let's verify that the data synchronization is valid.
Inserts data into the main library.

[Root@localhost ~]# MONGO 127.0.0.1:27017
MongoDB shell version:3.2.1
connecting
> Db.user.insert ({"Name": "Jack", "Age":, "Job": "Moive Star"})
Writeresult ({"ninserted": 1})
> Db.user.insert ({"Name": "Vicent", "Age":, "job": "Teacher"})
Writeresult ({"ninserted": 1})

Log in from the database and check that the data is synchronized

[Root@localhost ~]# MONGO 127.0.0.1:27018
MongoDB shell version:3.2.1
connecting
> > Db.user.find ()
{"_id": ObjectId ("5699af720102a61caffb76e8"), "name": "Jack", "Age": ", Job": "Moive Star"}
{"_id": ObjectId ("5699af920102a61caffb76e9"), "name": "Vicent", "Age": ", Job": "Teacher"}

You can see the data is synchronized ~

By default, to open the query function from the library, you must inform the server that you accept data from the server (there may be delays in synchronization, inconsistent data, and you can accept this inconsistency).

> Show Collections
2016-01-16t10:52:04.363+0800 e QUERY  [Thread1] Error:listcollections failed: {"OK": 0, "E Rrmsg ": Not Master and Slaveok=false", "Code": 13435}:
_geterrorwithcode@src/mongo/shell/utils.js:23:13
Db.prototype._getcollectioninfoscommand@src/mongo/shell/db.js:746:1
db.prototype.getcollectioninfos@src/ Mongo/shell/db.js:758:15
db.prototype.getcollectionnames@src/mongo/shell/db.js:769:12
shellHelper.show @src/mongo/shell/utils.js:695:9
shellhelper@src/mongo/shell/utils.js:594:15
@ (SHELLHELP2): 1:1

Execute Rs.slaveok

> Rs.slaveok ()
> Show Collections
User
>

There is a sources collection from the service's local database that records the main service information

> use ' local
switched to DB ' > show
collections
me
sources
startup_log
> Db.sources.find (). Pretty ()
{
  "_id": ObjectId ("5699AAAFA33311C25AB793DF"),
  "host": "127.0.0.1:27017",
  "source": "Main",
  "Syncedto": Timestamp (1452913003, 1)
}

When we start from the library again, we don't need to specify the source parameter.

[Root@localhost ~]# mongod--dbpath=/application/mongodb/data/slave/--port 27018--slave 2016-01-16T10:57:45.965+ 0800 I control [Initandlisten] MongoDB starting:pid=21820 port=27018 dbpath=/application/mongodb/data/slave/slave=1 64 -bit host=localhost.localdomain 2016-01-16t10:57:45.967+0800 I control [Initandlisten] DB version v3.2.1 2016-01-16t10 : 57:45.968+0800 I control [initandlisten] git version:a14d55980c2cdc565d4704a7e3ad37e4e535c1b2 2016-01-16T10 : 57:45.969+0800 i control [Initandlisten] OpenSSL version:openssl 1.0.1e-fips-Feb 2013 I control [Initandlisten] allocator:tcmalloc 2016-01-16t10:57:45.969+0800 I control [Initandlisten] Modules:none 2016-01 -16t10:57:45.969+0800 I control [Initandlisten] builds environment:2016-01-16t10:57:45.969+0800 i control [ Initandlisten] distmod:rhel62 2016-01-16t10:57:45.969+0800 I control [Initandlisten] distarch:x86_64 2016-01-16T10:5 7:45.969+0800 I control [Initandlisten] target_arch:x86_64 2016-01-16t10:57:45.969+0800 I control [Initandlisten] options: {net: {port:27018}, Slave:true, storage: {dbpath: "/appl ication/mongodb/data/slave/"}} 2016-01-16t10:57:46.010+0800 I-[Initandlisten] detected data files in/application/m
Ongodb/data/slave/created by the ' Wiredtiger ' storage engine and so setting the active storage engine to ' Wiredtiger '. 2016-01-16t10:57:46.011+0800 I STORAGE [Initandlisten] Wiredtiger_open config:create,cache_size=1g,session_max= 20000,eviction= (threads_max=4), config_base=false,statistics= (FAST), log= (enabled=true,archive=true,path=journal , Compressor=snappy), file_manager= (close_idle_time=100000), checkpoint= (WAIT=60,LOG_SIZE=2GB), statistics_log= (  wait=0), 2016-01-16t10:57:48.485+0800 I control [Initandlisten] * * Warning:you are running this process as the root user,
Which is not recommended. 
2016-01-16t10:57:48.486+0800 I control [Initandlisten] 2016-01-16t10:57:48.488+0800 i control [Initandlisten] 2016-01-16t10:57:48.490+0800 I Control [InitandlIsten] * * WARNING:/sys/kernel/mm/transparent_hugepage/enabled is ' always '.  2016-01-16t10:57:48.490+0800 I control [Initandlisten] * * We suggest setting it to ' Never ' 2016-01-16t10:57:48.490+0800 I control [Initandlisten] 2016-01-16t10:57:48.490+0800 i control [initandlisten] * * WARNING:/sys/kernel/mm/transparent
_hugepage/defrag is ' always '.  2016-01-16t10:57:48.490+0800 I control [Initandlisten] * * We suggest setting it to ' Never ' 2016-01-16t10:57:48.490+0800 I control [Initandlisten] 2016-01-16t10:57:48.493+0800 i ftdc [Initandlisten] Initializing full-time diagnostic data C Apture with directory '/application/mongodb/data/slave/diagnostic.data ' 2016-01-16t10:57:48.494+0800 I NETWORK [ Initandlisten] Waiting for connections on port 27018 2016-01-16t10:57:48.495+0800 I Network [ Hostnamecanonicalizationworker] Starting hostname canonicalization worker 2016-01-16t10:57:49.497+0800 I REPL [ Replslave] Syncing from host:127.0.0.1:27017 2016-01-16t10:57:50.503+0800 I REPL [ReplsLave] Sleep 1 sec before next pass 2016-01-16t10:57:51.504+0800 I REPL [replslave] syncing from host:127.0.0.1:27017 201 6-01-16t10:57:52.505+0800 i REPL [replslave] syncing from host:127.0.0.1:27017 2016-01-16t10:57:54.295+0800 I REPL [re Plslave] Syncing from host:127.0.0.1:27017 2016-01-16t10:57:55.296+0800 I REPL [replslave] syncing from Host:127.0.0.1:2
 7017

The Oplog log is used to synchronize between the master and slave libraries. Oplog exists in the local database of the main library, Oplog. $main collection.

> Use local switched to DB local > Db.oplog. $main. Find ({"OP": "I"}). Sort ({"TS": -1}). Pretty () {"TS": Timestamp (14 52916694, 1), "H": Numberlong (0), "V": 2, "OP": "I", "ns": "Test.user", "O": {"_id": ObjectId ("5699BF D6647c735cb3a50e0c ")," name ":" Zhangcong "} {" TS ": Timestamp (1452913156, 1)," H ": Numberlong (0)," V ": 2
    , "OP": "I", "ns": "Test.user", "O": {"_id": ObjectId ("5699b204358c4672cad1cc6e"), "name": "Zhangdd", "Age": "Job": "Teacher"} {"TS": Timestamp (1452912530, 1), "H": Numberlong (0), "V": 2, "OP" : "I", "ns": "Test.user", "O": {"_id": ObjectId ("5699af920102a61caffb76e9"), "name": "Vicent", "Age" : "Job": "Teacher"} {"TS": Timestamp (1452912498, 2), "H": Numberlong (0), "V": 2, "OP": "I", " NS ":" Test.user "," O ": {" _id ": ObjectId (" 5699af720102a61caffb76e8 ")," name ":" Jack "," Age ":" J " OB ":" Moive Star}}
 

The collection belongs to a fixed collection. The old log will be overwritten after a certain amount of time. If the log has been overwritten, from the library has not come and synchronized. Then the data can no longer be synchronized from the library. Only use--autoresync to resynchronize the data.

Note: The parameter value specified by the command-line parameter can be written to the config file and used at startup.

Mongod--config/path/to/file.conf

The Mongod 2.4 version uses the YAML format to write the configuration file. The official file does not provide a method for how the master-slave copy configuration is declared in the configuration file. Try several kinds of writing are not correct. Because MongoDB uses replica sets instead of master-slave replication, the configuration file may no longer support master-slave replication.

Thank you for reading, I hope to help you, thank you for your support for this site!