mongodb master-slave主从复制

久违的太阳

6457人浏览 · 2016-06-07 00:24:18

久违的太阳 · 2016-06-07 00:24:18 发布

mongodb的复制使用的oplog,类似于mysql复制的binlog,不同的是oplog是保存在local数据库中的.

需要合理的设置oplog的大小,如果此大小没有设置那么mongodb将会使用可用空间的5%来存放oplog.官方建议64位系统至少分配1G大小.

当slave端落后太多master端的时候,复制会终止,此时需要管理员手工来重启mongodb然后使用resync来重新同步.

此外你可以设置autoresync参数,当复制终止10秒后mongodb会自动重启复制,slave端会每隔10分钟自动重新同步一次.

注意官方现在强烈不建议使用master-slave复制模式,建议使用replica sets复制.

1.参数介绍

这里介绍的mongodb的主从复制,并不是复制集replica sets,复制的参数如下:

   
    
     Replication options:
    
    
       --oplogSize arg                       操作日志大小,单位M
    
    
      
    
    
     Master/slave options (old; use replica sets instead):
    
    
       --master                              指定角色为master mode
    
    
       --slave                               指定角色为slave mode
    
    
       --source arg                          当角色为slave的时候使用,格式为:
     <
     server
     :
     port
     >
    
    
       --only arg                            当角色为slave的时候使用,指定单独同步的数据库,默认为同步所有数据库.
    
    
       --slavedelay arg                      指定一个应用日志的延时,单位秒
    
    
       --autoresync                          当数据为旧数据时自动同步

2.master参数配置

   
    
     [root@mongodb1 log]# cat /etc/mongod.conf 
    
    
     port=27017
    
    
     dbpath=/data/db
    
    
     logpath=/data/log/mongod.log
    
    
     fork = true
    
    
     master=true
    
    
     oplogSize=2048

3.slave端参数配置

   
    
     [root@mongodb2 ~]# cat /etc/mongod.conf 
    
    
     port=27017
    
    
     dbpath=/data/db
    
    
     logpath=/data/log/mongod.log
    
    
     fork = true
    
    
     slave = true
    
    
     source = 192.168.56.80:27017

4.启动slave

直接启动slave端:

   
    
     [root@mongodb2 data]# mongod -f /etc/mongod.conf 
    
    
     about to fork child process, waiting until server is ready for connections.
    
    
     forked process: 2297
    
    
     child process started successfully, parent exiting

当启动slave后,slave端会自动进行初始化resync同步,可以在日志查看到同步信息:

   
    
     2016-06-06T23:24:56.225+0800 I REPL     [replslave] resync: dropping database suq
    
    
     2016-06-06T23:24:56.225+0800 I REPL     [replslave] resync: cloning database suq to get an initial copy
    
    
     2016-06-06T23:24:56.251+0800 I INDEX    [replslave] build index on: suq.test2 properties: { v: 1, key: { _id: 1 }, name: "_id_", ns: "suq.test2" }
    
    
     2016-06-06T23:24:56.251+0800 I INDEX    [replslave]      building index using bulk method
    
    
     2016-06-06T23:24:56.256+0800 I INDEX    [replslave] build index done.  scanned 4 total records. 0 secs
    
    
     2016-06-06T23:24:56.277+0800 I INDEX    [replslave] build index on: suq.test3 properties: { v: 1, key: { _id: 1 }, name: "_id_", ns: "suq.test3" }
    
    
     2016-06-06T23:24:56.277+0800 I INDEX    [replslave]      building index using bulk method
    
    
     ...
    
    
     ...
    
    
     ...
    
    
     2016-06-06T23:24:59.343+0800 I STORAGE  [replslave] copying indexes for: { name: "fs.files", options: {} }
    
    
     2016-06-06T23:24:59.344+0800 I REPL     [replslave] resync: done with initial clone for db: test
    
    
     2016-06-06T23:25:00.346+0800 I REPL     [replslave] syncing from host:192.168.56.80:27017
    
    
     2016-06-06T23:25:01.348+0800 I REPL     [replslave] syncing from host:192.168.56.80:27017
    
    
     2016-06-06T23:25:02.349+0800 I REPL     [replslave] syncing from host:192.168.56.80:27017
    
    
     2016-06-06T23:25:03.683+0800 I REPL     [replslave] syncing from host:192.168.56.80:27017

初始化完毕后会自动进入实时同步.

5.主从管理

查看主从信息

使用 rs.printReplicationInfo()来查看.2.6以前的版本使用 db. printReplicationInfo()

master端:

   
    
     > rs.printReplicationInfo()
    
    
     configured oplog size:   990MB
    
    
     log length start to end: 887037secs (246.4hrs)
    
    
     oplog first event time:  Fri May 27 2016 17:08:25 GMT+0800 (CST)
    
    
     oplog last event time:   Mon Jun 06 2016 23:32:22 GMT+0800 (CST)
    
    
     now:                     Mon Jun 06 2016 23:32:26 GMT+0800 (CST)

slave端:

   
    
     > db.printReplicationInfo()
    
    
     this is a slave, printing slave replication info.
    
    
     source: 192.168.56.80:27017
    
    
     	syncedTo: Mon Jun 06 2016 23:34:12 GMT+0800 (CST)
    
    
     	5 secs (0 hrs) behind the freshest member (no primary available at the moment)

slave端除了可以使用上面的还可以是有那个 rs.printSlaveReplicationInfo()

上面的显示这些内容显示都很简单,就不说明了.

查看主机状态

使用db.serverStatus( { repl: 1 } )来查看

    
     
      > db.serverStatus( { repl: 1 } )
     
     
      {
     
     
      	"host" : "mongodb1",
     
     
      	"advisoryHostFQDNs" : [ ],
     
     
      	"version" : "3.2.6",
     
     
      	"process" : "mongod",
     
     
      	"pid" : NumberLong(3780),
     
     
      	"uptime" : 1029,
     
     
      	"uptimeMillis" : NumberLong(1029698),
     
     
      	"uptimeEstimate" : 962,
     
     
      	"localTime" : ISODate("2016-06-06T15:41:44.864Z"),
     
     
      	"asserts" : {
     
     
      		"regular" : 0,
     
     
      		"warning" : 0,
     
     
      		"msg" : 0,
     
     
      		"user" : 0,
     
     
      		"rollovers" : 0
     
     
      	},
     
     
      	"connections" : {
     
     
      		"current" : 3,
     
     
      		"available" : 816,
     
     
      		"totalCreated" : NumberLong(8)
     
     
      	},
     
     
      ...
     
     
      ...
     
     
      ...

具体的说明查看官方文档:

https://docs.mongodb.com/manual/reference/command/serverStatus/#server-status-repl

slave查询

默认slave端是不能查询的,使用rs.slaveOk()来将slave端设置为可读状态:

   
    
     > rs.slaveOk()
    
    
     >

resync

当slave端落后过多的时候需要进行resync.

WARNING

This command obtains a global write lock and will block other operations until it has completed.

也就是说resync会在master上加一个全局的写锁,会阻塞其它的写操作,直到resync结束.使用数据库命令进行resync:

   
    
     > use admin
switched to db admin
    
    
     > db.runCommand({"resync":1})
    
    
     { "ok" : 0, "errmsg" : "not dead, no need to resync" }

6.oplog说明

oplog保存在local数据库中, 具体的local数据库介绍查看官方文档:

https://docs.mongodb.com/manual/reference/local-database/

   
    
     > use local
    
    
     switched to db local
    
    
     > show collections
    
    
     me
    
    
     oplog.$main
    
    
     startup_log
    
    
     > db.oplog.$main.findOne()
    
    
     {
    
    
     	"ts" : Timestamp(1464340105, 1),
    
    
     	"h" : NumberLong(0),
    
    
     	"v" : 2,
    
    
     	"op" : "n",
    
    
     	"ns" : "",
    
    
     	"o" : {
    
    
     		
    
    
     	}
    
    
     }

ts：8字节的时间戳，由4字节unix timestamp + 4字节自增计数表示。

这个值很重要，在选举(如master宕机时)新primary时，会选择ts最大的那个secondary作为新primary。

op：1字节的操作类型，例如i表示insert，d表示delete。

ns：操作所在的namespace。

o：操作所对应的document,即当前操作的内容（比如更新操作时要更新的的字段和值）

o2: 在执行更新操作时的条件，仅限于update时才有该属性。

其中op，可以是如下几种情形之一：

"i"： insert

"u"： update

"d"： delete

"c"： db cmd

"db"：声明当前数据库 (其中ns 被设置成为=>数据库名称+ '.')

"n": no op,即空操作，其会定期执行以确保时效性。

天工造物局

北京人形旗下天工造物具身智能开源社区，聚焦具身天工与慧思开物两大平台

更多推荐

deck.gl TripsLayer 出租车轨迹动画示例实战：从示例运行到着色器原理

TripsLayer 是 deck.gl 中用于渲染**随时间流动的轨迹动画**（如出租车行程、物流路径、迁徙路线）的核心图层。本文以仓库中的最小独立示例 [examples/website/trips](https://link.gitcode.com/i/1442af8f442f4cff39ff546e050fceb5) 为骨架，带你完成从安装依赖、启动应用、理解曼哈顿出租车数据格式，到深入

天工造物局

Foundry Anvil 中 eth_simulateV1 的 Blob 交易与 Blob Gas 字段规范化：原理、实现与测试验证

本篇技术指南以 [anvil-simulate-blob-transactions.md](https://link.gitcode.com/i/3d2ebe227262de169335eb290af80da8) 这条 changelog 条目为起点，深入剖析 Foundry Anvil 对 `eth_simulateV1` RPC 返回结果中 blob（EIP-4844）交易与 blob gas

天工造物局

LMCache CLI 实战：用 `lmcache kvcache clear` 管理运行中服务的 KV Cache 状态

本文是一份针对 LMCache 官方 CLI 命令 `lmcache kvcache` 的完整技术指南。该命令用于在**运行中的 LMCache 服务（MP HTTP server）**上管理 KV cache 状态，当前提供 `clear` 子命令，用于清空 L1（CPU 内存）层中缓存的全部 KV 数据。读完本文，你将掌握该命令的完整参数体系、退出码语义、终端/JSON/静默三种输出模式，并能