mongodb中mongodump 使用 --oplog 参数备份非常的慢

mongodb中mongodump 使用 –oplog 参数备份非常的慢

问题表现：最近生产环境突然收到 IO 使用率100%跟的报警
登上服务器产看io状态
iostat -x -m 1
%util 的值一直是 100%，await，达到 60 以上，
top 查看，负载居然达到47以上，通过进程 id 找到相应的进程，发现居然是 3个 mongodb 备份进程把磁盘io占用完了，
备份进程如下：

  /usr/local/mongodb3.0.15/bin/mongodump -h 192.168.201.129:28010  --oplog -o /data/backup/mongo_dbbackup/pktest/20180226174241/pktest >/data/backup/mongo_dbbackup/pktest/20180226174241/pktest.log 2>/data/backup/mongo_dbbackup/pktest/20180226174241/pktest.er

为什么是3个进程同时进行的呢，我的定时任务是每隔3个小时进行一次，mongodb 版本是3.0.15 wiredTiger引擎，备份压缩后的数据不到1G的数据，为什么3个小时都备份不完1G的数据呢，
产看备份日志文件

2018-02-26T17:42:41.812+0800    writing captured oplog to

在17:42:41 分的时候就已经读oplog，现在已经是22:03:46 已经超过4个小时了，为啥读取oplog中的数据居然要这么久，而且这个mongodb 业务量非常的小，为啥还这么慢
登录mongodb
执行如下命令

rs11:SECONDARY> rs.slaveOk()
rs11:SECONDARY> db.serverStatus().storageEngine
{ "name" : "wiredTiger" }
rs11:SECONDARY> show dbs
local           46.102GB
testdata2       0.036GB
texasmoney_108  0.312GB
texasmoney_13   2.072GB
texasmoney_67   1.508GB

oplog 居然达到46GB 数据

rs11:SECONDARY> rs.printReplicationInfo()
configured oplog size:   92160MB
log length start to end: 24826899secs (6896.36hrs)
oplog first event time:  Mon May 29 2017 13:39:32 GMT+0800 (CST)
oplog last event time:   Mon Mar 12 2018 22:01:11 GMT+0800 (CST)
now:                     Mon Mar 12 2018 22:01:11 GMT+0800 (CST)
rs11:SECONDARY>

通过上面数据我们就分析出io以及高负载的原因：
原因：日志保留居然到达了287 天， oplog 明显太大，到时读取oplog的使用大量的io

解决办法：缩小oplog 的大小，我们生产环境一般保留48小时左右的数据，这个我们设置2GB 的大小

修改完以后，再次备份，每次备份时间不用10分钟，备份数据的性能大大提升

至于修改oplog 的大小的方法，后面有空就会写出来

mongodb中mongodump 使用 --oplog 参数备份非常的慢

mongodb中mongodump 使用 –oplog 参数备份非常的慢

猜你喜欢