MongoDB的备份与回复

发布时间:2018-11-17  栏目:NoSQL  评论:0 Comments

系统环境

服务器系统:Windows Server2012 R2

MongoDB:v3.4.4

足由此命令:mongo -version 查看版本信息

manbet手机客户端3.0 1

情景:备份数据库smp_maint_2,还原到新建的数据库smp_maint_2_restore中。

1.6.2 全量备份方法

 manbet手机客户端3.0 2

MongoDB数据库备份

    1、语法:
        mongodump -h dbhost -d dbname -o dbdirectory
        参数说明:
            -h:
MongDB所于服务器地址,例如:127.0.0.1,当然也得以指定端口号:127.0.0.1:27017
            -d: 需要备份的数据库实例,例如:test
            -o:
备份的多寡存放位置,例如:/home/mongodump/,当然该目录需要提前立,这个目录里存该数据库实例的备份数据。
    2、实例:

优先经服务器上面安装的Mongodb服务器找到服务的到处路径:C:\Program
Files\MongoDB\Server\3.4\bin\mongod.exe

manbet手机客户端3.0 3

先在服务器上面创建文件目录:E:\data\home\momgodump

下一场为管理员身份打开CMD,然后跳反至Mongodb所当路线,执行如下命令:

mongodump -h 192.168.1.18:27017 -d smp_maint_2 -o E:\data\home\momgodump

 运行结果如下:

manbet手机客户端3.0 4

备份完成后,我们再度看下备份目录下面自动创建了一个与数据库名称一致的目,目录下面有如图所示备份文件

manbet手机客户端3.0 5

1.5.2 存储引擎方面

  WiredTiger是3.0随后的默认存储引擎,细粒度的出现控制和数据压缩提供了再度强之性及贮效率。3.0缘前默认的MMAPv1也增长了性。

  以MongoDB复制集中可以组成多钟存储引擎,各个实例实现不同的应用需求。

MongoDB数据库恢复

    1、语法:
        mongorestore -h dbhost -d dbname –dir dbdirectory
 
        参数或曰:
            -h: MongoDB所于服务器地址
            -d:
需要恢复的数据库实例,例如:test,当然是称呼为可以与备份时候的匪一致,比如test2
            –dir: 备客数据所在位置,例如:/home/mongodump/itcast/
            –drop:
恢复的时光,先去时数量,然后还原备份的数码。就是说,恢复后,备份后上加修改的数额还见面于删去,慎用!
    2、实例:

新建mongodb数据库smp_maint_2_restore,然后实施如下命令:

mongorestore -h 192.168.1.18:27017 -d smp_maint_2_restore --dir E:\data\home\momgodump\smp_maint_2

 运行结果如下所示:

manbet手机客户端3.0 6
  
manbet手机客户端3.0 7

复原成!

1.5 MongoDB集群性能优化方案

1.3.3 【模拟】mongodump使用

第一我们学一个不息发生插入操作的集合foo,

use clsn
for(var i = 0; i < 10000; i++) {
    db.clsn.insert({a: i});
}

  然后当插入过程中法一次于mongodump并点名–oplog。

mongodump -h 10.0.0.152 --port 28021  --oplog  -o /home/mongod/backup/oplog

  注意:–oplog选项就针对全库导出有效,所以未可知指定-d选项。

       因为整个实例的更改操作都见面集中在local库中的oplog.rs集合中。

冲上面所说,从dump开始之时日体系将记录有的oplog到oplog.bson中,所以我们得到这些文件:

[mongod@MongoDB ~]$ ll /home/mongod/backup/oplog 
total 8
drwxrwxr-x 2 mongod mongod   4096 Jan  8 16:49 admin
drwxrwxr-x 2 mongod mongod   4096 Jan  8 16:49 clsn
-rw-rw-r-- 1 mongod mongod  77256 Jan  8 16:49 oplog.bson

查oplog.bson中第一漫漫与最终一修内容

[mongod@MongoDB oplog]$ bsondump oplog.bson  >/tmp/oplog.bson.tmp
[mongod@MongoDB oplog]$ head -1 /tmp/oplog.bson.tmp 
{"ts":{"$timestamp":{"t":1515401553,"i":666}},"t":{"$numberLong":"5"},"h":{"$numberLong":"5737315465472464503"},"v":2,"op":"i","ns":"clsn.clsn1","o":{"_id":{"$oid":"5a533151cc075bd0aa461327"},"a":3153.0}}
[mongod@MongoDB oplog]$ tail -1 /tmp/oplog.bson.tmp 
{"ts":{"$timestamp":{"t":1515401556,"i":34}},"t":{"$numberLong":"5"},"h":{"$numberLong":"-7438621314956315593"},"v":2,"op":"i","ns":"clsn.clsn1","o":{"_id":{"$oid":"5a533154cc075bd0aa4615de"},"a":3848.0}}

  最终dump出的多寡既是无是无与伦比开头之状态,也不是终极的状态,而是中间有随机状态。这多亏为集合不断变动导致的。

  使用mongorestore来恢复

[mongod@MongoDB oplog]$ mongorestore -h 10.0.0.152 --port 28021  --oplogReplay  --drop   /home/mongod/backup/oplog
2018-01-08T16:59:18.053+0800    building a list of dbs and collections to restore from /home/mongod/backup/oplog dir
2018-01-08T16:59:18.066+0800    reading metadata for clsn.clsn from /home/mongod/backup/oplog/clsn/clsn.metadata.json
2018-01-08T16:59:18.157+0800    restoring clsn.clsn from /home/mongod/backup/oplog/clsn/clsn.bson
2018-01-08T16:59:18.178+0800    reading metadata for clsn.clsn1 from /home/mongod/backup/oplog/clsn/clsn1.metadata.json
2018-01-08T16:59:18.216+0800    restoring clsn.clsn1 from /home/mongod/backup/oplog/clsn/clsn1.bson
2018-01-08T16:59:18.669+0800    restoring indexes for collection clsn.clsn1 from metadata
2018-01-08T16:59:18.679+0800    finished restoring clsn.clsn1 (3165 documents)
2018-01-08T16:59:19.850+0800    restoring indexes for collection clsn.clsn from metadata
2018-01-08T16:59:19.851+0800    finished restoring clsn.clsn (10000 documents)
2018-01-08T16:59:19.851+0800    replaying oplog
2018-01-08T16:59:19.919+0800    done

  注意黄字体,第一词表示clsn.clsn1集合中回复了3165个文档;第二句表示重放了oplog中的装有操作。所以理论及clsn1应该发16857独文档(3165独来clsn.bson,剩下的来源于oplog.bson)。验证一下:

sh1:PRIMARY> db.clsn1.count()
3849

  这即是带oplog的mongodump的真作用。

1.2.2 mongorestore恢复实践

  mongorestore与mongoimport参数近似 

参数

参数说明

-h

指明数据库宿主机的IP

-u

指明数据库的用户名

-p

指明数据库的密码

-d

指明数据库的名字

-c

指明collection的名字

-o

指明到要导出的文件名

-q

指明导出数据的过滤条件

–authenticationDatabase

验证数据的名称

–gzip

备份时压缩

–oplog

use oplog for taking a point-in-time snapshot

–drop

恢复的时候把之前的集合drop掉

全库备份中恢复单库(基于前的全库备份)

mongorestore -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d test --drop  /home/mongod/backup/full/test/

恢复test库

mongorestore -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d test /home/mongod/backup/test/

恢复test库下的vast集合

mongorestore -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d test -c vast /home/mongod/backup/test/vast.bson

–drop参数实践恢复

# 恢复单库
mongorestore -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d test --drop /home/mongod/backup/test/
# 恢复单表
mongorestore -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d test -c vast --drop /home/mongod/backup/test/vast.bson

1.4.3 db级别命令

db.currentOp()

  查看数据库当前施行什么操作。

  用于查看长时运作过程。

  通过(执行时长、操作、锁、等待锁时长)等规范过滤。

  如果发现一个操作太长,把数据库卡死的话,可以用这个命令杀死他:>
db.killOp(608605)

db.setProfilingLevel()

  设置server级manbet手机客户端3.0别慢日志

  打开profiling:

0:不保存

1:保存慢查询日志

 

2:保存有查询日志

  注意:级别是指向应当前的数据库,而阈值是大局的。

查看profiling状态

查看慢查询:system.profile

 

关闭profiling

店家工具ops manager官方文档:
https://docs.opsmanager.mongodb.com/v3.6/

1.5.3 其他优化建议

收缩数据

预分片

增新的机械、新的抱本集

集群分片键选择

 

chunk大小设置

1.1.3 【实验】mysql数据迁移到mongodb数据库

    mysql相关的参阅文档:http://www.cnblogs.com/clsn/category/1131345.html

以mysql数据库中之mysql下之user表导出。

select user,host,password from mysql.user
into outfile '/tmp/user.csv'
fields terminated by ','
optionally enclosed by '"'
escaped by '"' 
lines terminated by '\r\n';

命说明:

into outfile '/tmp/user.csv'  ------导出文件位置  
fields terminated by ','     ------字段间以,号分隔
optionally enclosed by '"'   ------字段用"号括起
escaped by '"'            ------字段中使用的转义符为"
lines terminated by '\r\n';  ------行以\r\n结束

查阅导出内容

[mongod@MongoDB tmp]$ cat user.csv 
"root","localhost",""
"root","db02",""
"root","127.0.0.1",""
"root","::1",""
"","localhost",""
"","db02",""
"repl","10.0.0.%","*23AE809DDACAF96AF0FD78ED04B6A265E05AA257"
"mha","10.0.0.%","*F4C9AC49A736981AE2739FC2F4A1FD92B4F07929"

以mongodb中导入数据

mongoimport -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d app -c user -f user,host,password  --type=csv --file /tmp/user.csv

   查看导入的内容

[root@MongoDB tmp]# mongo --port 27017 
MongoDB shell version: 3.2.8
connecting to: 127.0.0.1:27017/test
> use app 
switched to db app
> db.user.find()
{ "_id" : ObjectId("5a53206b3b42ae4683180009"), "user" : "root\tlocalhost" }
{ "_id" : ObjectId("5a53206b3b42ae468318000a"), "user" : "root\tdb02" }
{ "_id" : ObjectId("5a53206b3b42ae468318000b"), "user" : "root\t127.0.0.1" }
{ "_id" : ObjectId("5a53206b3b42ae468318000c"), "user" : "root\t::1" }
{ "_id" : ObjectId("5a53206b3b42ae468318000d"), "user" : "localhost" }
{ "_id" : ObjectId("5a53206b3b42ae468318000e"), "user" : "db02" }
{ "_id" : ObjectId("5a53206b3b42ae468318000f"), "user" : "repl\t10.0.0.%\t*23AE809DDACAF96AF0FD78ED04B6A265E05AA257" }
{ "_id" : ObjectId("5a53206b3b42ae4683180010"), "user" : "mha\t10.0.0.%\t*F4C9AC49A736981AE2739FC2F4A1FD92B4F07929" }

     到是数迁移完成。

1.6.1 MongoDB云数据库备份/恢复

manbet手机客户端3.0 8 

备份策略:

  1. 自从hidden节点备份
  2. 每日一糟糕全量备份
  3. 不止拉取oplog增量备份
  4. 期限巡检备份有效性
  5. 恢复时克隆到新实例

1.2 mongodump/mongorestore实践

1.3.4 从别处要来之oplog

oplog有有限种植来源:

1、mongodump时长–oplog选项,自动生成的oplog,这种办法的oplog直接
–oplogReplay 就得还原

 

2、从别处要来,除了–oplog之外,人为获取之oplog

例如:

mongodump  --port 28021 -d local -c oplog.rs

  既然dump出的数码配合oplog就好拿数据库恢复到某个状态,那是未是富有同样卖起某个时间点起备份的dump数据,再添加从dump开始后的oplog,如果oplog足够长,是不是就是可将数据库恢复到下之妄动状态了?是的!

  事实上replica
set正是依赖oplog的重放机制当干活。当secondary第一坏参加replica
set时举行的initial
sync就一定于是当举行mongodump,此后独待持续地合跟重放oplog.rs中的数目,就达到了secondary与primary同步的目的。

  既然oplog一直还当oplog.rs中留存,我们怎么还亟需以mongodump时指定–oplog呢?需要的当儿打oplog.rs中以不纵终止了吧?答案是肯定的,你确实可只dump数据,不待oplog。

以急需之时段可重从oplog.rs中取。但前提是oplog时间窗口要能覆盖dump的开端时。

即时点恢复状况模拟

学生产条件

for(i=0;i<300000;i++){ db.oplog.insert({"id":i,"name":"shenzheng","age":70,"date":new Date()}); }

   插入数据的还要备份

mongodump -h 10.0.0.152 --port 28021  --oplog  -o /home/mongod/backup/config

    备份完成后进行次错误的操作

    db.oplog.remove({});

备份oplog.rs文件

mongodump -h 10.0.0.152 --port 28021 -d local -c oplog.rs -o  /home/mongod/backup/config/oplog

   恢复之前备份的多寡

mongorestore -h 10.0.0.152 --port 28021--oplogReplay /home/mongod/backup/config

   截取oplog,找到有误删除的年月接触

bsondump oplog.rs.bson |egrep "\"op\":\"d\"\,\"ns\":\"test\.oplog\"" |head -1 
"t":1515379110,"i":1

   复制oplog到备份目录

cp  /home/mongod/backup/config/oplog/oplog.rs.bson   /home/mongod/backup/config/oplog.bson

   进行复原,添加之前找到的误删除的触发(limt)

mongorestore -h 10.0.0.152 --port 28021 --oplogReplay --oplogLimit "1515379110:1"  /home/mongod/backup/config

   
 至这如出一辙不行恢复就得了

1.2.1 mongodump备份工具

  mongodump的参数与mongoexport的参数基本一致 

参数

参数说明

-h

指明数据库宿主机的IP

-u

指明数据库的用户名

-p

指明数据库的密码

-d

指明数据库的名字

-c

指明collection的名字

-o

指明到要导出的文件名

-q

指明导出数据的过滤条件

–authenticationDatabase

验证数据的名称

–gzip

备份时压缩

–oplog

use oplog for taking a point-in-time snapshot

mongodump参数实践

全库备份

mongodump -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -o /home/mongod/backup/full

备份test库

mongodump -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -d test -o /home/mongod/backup/

备份test库下的vast集合

mongodump -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -d test -c vast -o /home/mongod/backup/

压缩备份库

mongodump -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -d test -o /home/mongod/backup/ --gzip

削减备份单表

mongodump -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -d test -c vast -o /home/mongod/backup/ --gzip

1.1.1 导出工具mongoexport

Mongodb中的mongoexport工具得以把一个collection导出成JSON格式或CSV格式的文书。可以由此参数指定导出的多寡项,也得以依据指定的条件导出数据。

   该令的参数如下:

参数

参数说明

-h

指明数据库宿主机的IP

-u

指明数据库的用户名

-p

指明数据库的密码

-d

指明数据库的名字

-c

指明collection的名字

-f

指明要导出那些列

-o

指明到要导出的文件名

-q

指明导出数据的过滤条件

–type

指定文件类型

–authenticationDatabase

验证数据的名称

mongoexport备份实践

备份app库下的vast集合

mongoexport -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d app -c vast -o /home/mongod/backup/vasts.dat

横流:备份文件的讳可以从定义,默认导出了JSON格式的多少。

导出CSV格式的多少

mongoexport -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -d app -c vast --type=csv -f id,name -o /home/mongod/backup/vast_csv.dat

1.4.1 MongoDB集群监控措施

db.serverStatus()

  查看实例运行状态(内存以、锁、用户连接等消息)

  通过比较对上下快照进行性能分析

"connections"     # 当前连接到本机处于活动状态的连接数
"activeClients"   # 连接到当前实例处于活动状态的客户端数量
"locks"           # 锁相关参数
"opcounters"      # 启动之后的参数
"opcountersRepl"  # 复制想关
"storageEngine"   # 查看数据库的存储引擎
"mem"             # 内存相关

状态:

db.stats()

显示信息说明:

  "db" : "test" ,表示当前是针对"test"这个数据库的描述。想要查看其他数据库,可以先运行$ use databasename(e.g  $use admiin).
 "collections" : 3,表示当前数据库有多少个collections.可以通过运行show collections查看当前数据库具体有哪些collection.
 "objects" : 13,表示当前数据库所有collection总共有多少行数据。显示的数据是一个估计值,并不是非常精确。
 "avgObjSize" : 36,表示每行数据是大小,也是估计值,单位是bytes
 "dataSize" : 468,表示当前数据库所有数据的总大小,不是指占有磁盘大小。单位是bytes
 "storageSize" : 13312,表示当前数据库占有磁盘大小,单位是bytes,因为mongodb有预分配空间机制,为了防止当有大量数据插入时对磁盘的压力,因此会事先多分配磁盘空间。
 "numExtents" : 3,似乎没有什么真实意义。我弄明白之后再详细补充说明。
 "indexes" : 1 ,表示system.indexes表数据行数。
 "indexSize" : 8192,表示索引占有磁盘大小。单位是bytes
   "fileSize" : 201326592,表示当前数据库预分配的文件大小,例如test.0,test.1,不包括test.ns。

1.5.1 优化趋势

硬件(内存、SSD)

抽数据

追加新的机械、新的符本集

集群分片键选择

chunk大小设置

 

预分片(预先分配存储空间)

1.3 MongoDB中的oplog

1.1.2 导入工具mongoimport

  Mongodb中之mongoimport工具得以将一个一定格式文件中的情导入到指定的collection中。该工具得以导入JSON格式数据,也足以导入CSV格式数据。

欠令的参数如下:   

参数

参数说明

-h

指明数据库宿主机的IP

-u

指明数据库的用户名

-p

指明数据库的密码

-d

指明数据库的名字

-c

指明collection的名字

-f

指明要导出那些列

-o

指明到要导出的文件名

-q

指明导出数据的过滤条件

–drop

插入之前先删除原有的

–headerline

指明第一行是列名,不需要导入。

-j

同时运行的插入操作数(默认为1),并行

–authenticationDatabase

验证数据的名称

mongoimport恢复执行

将事先恢复的数码导入

mongoimport -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -d app -c vast  --drop /home/mongod/backup/vasts.dat

以事先恢复的CSV格式数据导入

mongoimport -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d app -c vast --type=csv --headerline --file vast_csv.dat

1.4 MongoDB监控

怎要监督?

style=”color: #000000;”>监控就获得行使之运行状态信息,在题材出现不时及时发现。

监控什么?

style=”color: #000000;”>CPU、内存、磁盘I/O、应用程序(MongoDB)、进程监控(ps
-aux)、错误日志监控

1.6.3 逻辑备份流程 – mongodump

 manbet手机客户端3.0 9

特点:

  1. 全量遍历所有数据、
  2. 备份、恢复慢
  3. 针对工作影响比较生
  4. 不必备份索引、恢复时重建
  5. 通用性强

1.1 MongoDB的常用命令

mongoexport / mongoimport
mongodump  / mongorestore

     有以上两组命令于备份与还原被进行以。

1.6 附录:Aliyun 备份策略

1.2.3 mongoexport/mongoimport与mongodump/mongorestore的对比

 

  1. mongoexport/mongoimport导入/导出的是JSON格式,而mongodump/mongorestore导入/导出的凡BSON格式。
  2. JSON可读性强但体积比充分,BSON则是二进制文件,体积小而针对人类几无可读性。
  3. 每当有mongodb版本之间,BSON格式可能会见随版本不同而有所不同,所以不同版本中因此mongodump/mongorestore可能无见面马到成功,具体要看本之间的兼容性。当无法采取BSON进行超越版本的数量迁移的时节,使用JSON格式即mongoexport/mongoimport是一个不过选项。跨版本的mongodump/mongorestore并无推荐,实在要举行要预反省文档看片只版本是否匹配(大部分时光是的)。
  4. JSON虽然拥有比较好的跨版本通用性,但那单保留了数量有,不保留索引,账户等其它基础信息。使用时该专注。

1.4.2 mongostat

  实时数据库状态,读写、加锁、索引命中、缺页中断、读写等待队列等情形。

  每秒刷新一不行状态值,并会提供精美的可读性,通过这些参数可以观测到MongoDB系统整体性能情况。

[mongod@MongoDB oplog]$ mongostat -h 10.0.0.152 --port 28017 
insert query update delete getmore command flushes mapped  vsize   res faults qr|qw ar|aw netIn netOut conn set repl                      time
    *0    *0     *0     *0       0     1|0       0        303.0M 13.0M      0   0|0   0|0  143b     8k    1      RTR 2018-01-08T17:28:42+08:00

参数说明: 

参数

参数说明

insert

每秒插入量

query

每秒查询量

update

每秒更新量

delete

每秒删除量

conn

当前连接数

qr|qw

客户端查询排队长度(读|写)最好为0,如果有堆积,数据库处理慢。

ar|aw

活跃客户端数量(读|写)

time

当前时间

mongotop命令说明:

[mongod@MongoDB oplog]$ mongotop  -h 127.0.0.1:27017
2018-01-08T17:32:56.623+0800    connected to: 127.0.0.1:27017

                                               ns    total    read    write    2018-01-08T17:32:57+08:00
                               admin.system.roles      0ms     0ms      0ms                             
                               admin.system.users      0ms     0ms      0ms                             
                             admin.system.version      0ms     0ms      0ms                             
                                         app.user      0ms     0ms      0ms                             
             automationcore.automation.job.status      0ms     0ms      0ms                             
                 automationcore.config.automation      0ms     0ms      0ms                             
        automationcore.config.automationTemplates      0ms     0ms      0ms                             
automationcore.config.automationTemplates_archive      0ms     0ms      0ms                             
         automationcore.config.automation_archive      0ms     0ms      0ms                             
                 automationstatus.lastAgentStatus      0ms     0ms      0ms      

mongotop重要指标

ns:数据库命名空间,后者结合了数据库名称和集合。
total:mongod在这个命令空间上花费的总时间。
read:在这个命令空间上mongod执行读操作花费的时间。
write:在这个命名空间上mongod进行写操作花费的时间。

1.3.5 mongodb的备份准则

独针对replica或master/slave,满足这些规则MongoDB就得拓展point-in-time恢复操作:

 

  1. 肆意两次数据备份的时空距离(第一软备份开始到第二浅备份结束)不克跨越oplog时间窗口覆盖范围。
  2. 每当上次数据备份的基本功及,在oplog时间窗口没有滑发生上次备份结束的时光点前进行整体的oplog备份。请充分考虑oplog备份需要的流年,权衡服务器空间情况确定oplog备份间隔。

其实运用中之注意事项:

 

  1. 设想到oplog时间窗口是个变化值,请关注oplog时间窗口的切实日子。
  2. 于贴近oplog时间窗口滑动出可行时间之前必须要来足够的日子dump出用之oplog.rs,请留下足够的光阴,不要顶满时间窗口又备份。
  3. 当灾难发生时,第一件业务就是要停数据库的写入操作,以往oplog滑发生时窗口。特别是像上述如此的remove({})操作,瞬间虽会插入大量d记录从而导致oplog迅速滑发生时窗口。

分片集群的备份注意事项

1、备份什么?

  (1)configserver

  (2)每一个shard节点

2、备份需要专注什么?

  (1)元数据与实在数据如果来针对性等性(blancer迁移的题目,会招config和shard备份不等同)

 

  (2)不同部分备份结束时间接触未均等,恢复出来的数量就是是生题目的。

1.6.4 物理备份流程

manbet手机客户端3.0 10 

备份特点

  1. 拷贝数据目录所有文件,效率高
  2. 备份、恢复快
  3. 对工作影响比小
  4. 以及数据库版本、配置高涉嫌

1.7 参考文献

[1]  http://www.cnblogs.com/yaoxing/p/mongodb-backup-rules.html

[2]  http://blog.itpub.net/15498/viewspace-2073272/

[3]  http://www.mongoing.com/archives/3962

[4]  http://chenzhou123520.iteye.com/blog/1641319

[5]  http://www.mongoing.com/oplog

[6]  https://www.cnblogs.com/datazhang/p/5917861.html

 

1.3.2 oplog.bson作用

和oplog相关的参数

参数

参数说明

–oplogReplay

重放oplog.bson中的操作内容

–oplogLimit

与–oplogReplay一起使用时,可以限制重放到的时间点

  首先要明的一个题目是数据里面相有据,比如集合A中存放了订单,集合B中存放了订单的具备密切,那么就生一个订单有整体的缜密时才是天经地义的状态。

  假要于随意一个时间点,A和B集合的多少还是共同体对应并且产生含义之(对非关系型数据库要水到渠成这点连无容易,且对MongoDB来说这样的数据结构并非合理。但此处我们要是规格建立),那么要A处于时间点x,而B处于x之后的一个日子点y时,可以想象A和B中的多寡最生或怪应设去意义。

  mongodump的拓展过程遭到并无会见把数据库锁死因为保证全体库冻结在一个稳住的时间点,这在业务及时是休允的。所以便生了dump的末尾结果中A集合是10点整的状态,而B集合则是10触及零1分开的状态这种状态。

  这样的备份即使恢复回去,可以设想得到的结果或者意义有限。

  那么点这oplog.bson的意思就是当此地体现出了。如果在dump数据的功底及,再重复开相同通oplog中著录之享有操作,这时的多寡就是足以表示dump结束时颇时间点(point-in-time)的数据库状态。

1.3.1 什么是oplog

  MongoDB
的Replication是由此一个日志来囤积写操作的,这个日志就深受做oplog。

  于默认情况下,oplog分配的凡5%底空余磁盘空间。通常而言,这是同种客观的装置。可以经mongod
–oplogSize来转oplog的日志大小。

  oplog凡是capped
collection,因为oplog的特征(不能够尽多管磁盘填满了,固定大小)需要,MongoDB才说明了capped
collection(the oplog is actually the reason capped collections were
invented). 定值大小的汇,oplogSizeMB:
2048,oplog是有所幂等性,执行下之未见面反复实践。

  值得注意的是,oplog**也replica
set或者master/slave模式专用(standalone模式运行mongodb并无推荐)。**

oplog的位置:

oplog在local库: local。oplog

master/slave 架构下:local.oplog.$main;

 

replica sets 架构下:local.oplog.rs

参数说明

$ mongodump --help
 --oplog use oplog for taking a point-in-time snapshot

  该参数的根本作用是于导出的还要转一个oplog.bson文件,存放于公从头展开dump到dump结束之间有的oplog。

  oplog
官方说明https://docs.mongodb.com/manual/core/replica-set-oplog/

 manbet手机客户端3.0 11

  简单地游说,在replica set中oplog是一个定容集合(capped
collection),它的默认大小是磁盘空间的5%(可以经–oplogSizeMB参数修改),位于local库的db.oplog.rs,有趣味可以看看中究竟出来什么内容。

  其中记录之是全方位mongod实例一段时间内数据库的富有改变(插入/更新/删除)操作。当空间用完经常新记录自动覆盖最总的笔录。

  所以从日轴及看,oplog的覆盖范围大概是如此的:

 manbet手机客户端3.0 12 

  其覆盖范围被称作oplog时间窗口。需要留意的是,因为oplog是一个定容集合,所以时窗口能遮住的限会因为你单位时外之创新次数不同而转变。想只要翻时的oplog时间窗口预计值.

sh1:PRIMARY> rs.printReplicationInfo()
configured oplog size:   2048MB   <--集合大小
log length start to end: 305451secs (84.85hrs)  <--预计窗口覆盖时间
oplog first event time:  Thu Jan 04 2018 19:39:05 GMT+0800 (CST)
oplog last event time:   Mon Jan 08 2018 08:29:56 GMT+0800 (CST)
now:                     Mon Jan 08 2018 16:33:25 GMT+0800 (CST)

  oplog有一个异常主要之特性——幂等性(idempotent)。即对一个数额集合,使用oplog中记录的操作重放时,无论吃重放多少次,其结果会是相同的。

  举例来说,如果oplog中记录的是一个栽操作,并切莫见面以你重放了零星次等,数据库被即获取两漫长相同的笔录。这是一个可怜重点的特性.

1.6.5 逻辑备份 vs 物理备份

 

逻辑备份

物理备份

备份效率

数据库接口读取数据

拷贝物理文件

恢复效率

下载备份集 +  导入数据 +  建立索引

下载备份集 +  启动进程

备份影响

直接与业务争抢资源

备份集大小

比原库小

无需备份索引数据

与原库相同

兼容性

兼容绝大部分版本

可跨存储引擎

依赖存储布局

   更多内容参考http://www.mongoing.com/archives/3962

留下评论

网站地图xml地图