修改mongodb oplog size

p 转载地址： a target= _blank href= http://blog.csdn.net/huwei2003/article/details/43307647 http://blog.csdn.net/huwei2003/article/details/43307647 /a /p p br /p p /p h1 >转载地址：http://blog.csdn.net/huwei2003/article/details/43307647

修改mongodb oplog size oplog简介： oplog：operations log的简写，存储在一个特殊的数据库中（local），oplog就存储在其中的oplog.$main集合里面，这个集合是一个固定集合，新操作会自动替换旧的操作，以保证oplog不会超过预设的大小，其中的每个文档都代表主节点上执行的一个操作，oplog会包含所有对数据有修改的的操作（查询操作不会记录），默认下，oplog大小会占用64位的实例5%的可用磁盘空间。
mongo复制的过程：主节点应用业务操作修改到数据库中，然后记录这些操作到oplog中，从节点复制这些oplog，然后应用这些修改。ps：这些操作是异步的。如果从节点的操作已经被主节点落下很远，oplog日志在从节点还没执行完，oplog可能已经轮滚一圈了，从节点跟不上同步，复制就会停下，从节点需要重新做完整的同步，为了避免此种情况，尽量保证主节点的oplog足够大，能够存放相当长时间的操作记录。
查询oplog的大小及保存的操作记录持续的时长 repltest:PRIMARY db.printReplicationInfo()
configured oplog size:   1024MB
log length start to end: 3705secs (1.03hrs)
oplog first event time:  Thu Oct 10 2013 11:13:29 GMT+0800 (CST)
oplog last event time:   Thu Oct 10 2013 12:15:14 GMT+0800 (CST)
now:                     Fri Oct 11 2013 16:33:42 GMT+0800 (CST)
查询从节点的数据源列表，其中有数据滞后的时间 repltest:PRIMARY db.printSlaveReplicationInfo()
source:   192.168.1.101:37017
syncedTo: Fri Oct 11 2013 16:38:16 GMT+0800 (CST)
= 1 secs ago (0hrs)
source:   192.168.1.100:37017
no replication info, yet.  State: ARBITER
so,修改oplog的大小：（下面介绍两种方式）
方式一: The oplog exists internally as a capped collection, so you cannot modify its size in the course of normal operations.另：改变oplog大小，需要在每个节点上执行维护模式。（官方推荐）
步骤：
1:重启一个实例以单机模式，

通常再关闭server之前，使用rs.stepDown() 强制primary成为secondary

2:重新创建一个新大小， 其中包含旧的oplgo的入口条目的oplog

3:重启mongod作为replica set的成员 操作步骤：
1 : Restart a Secondary in Standalone Mode on a Different Port
关闭mongod实例：
repset:PRIMARY use admin
repset:PRIMARY db.shutdownServer()
重启mongod实例以单机模式，修改端口，并不要加--replSet参数
＃vim /etc/mongo.conf
  dbpath=/var/lib/mongodb
  logpath=/var/log/mongodb/mongo.log
  pidfilepath=/var/run/mongo.pid
  directoryperdb=true
  logappend=true
  #replSet=repset
  bind_ip=192.168.1.100,127.0.0.1
  port=37017
  oplogSize=2000
  fork=true＃ mongod -f /etc/mongo.conf
备份oplog＃ mongodump --db local --collection oplog.rs --port 37017
2 : Recreate the Oplog with a New Size and a Seed Entry
保存oplog的最新的时间点
use local
db.temp.save( db.oplog.rs.find( { }, { ts: 1, h: 1 } ).sort( {$natural : -1} ).limit(1).next() )
db.temp.find()
删除旧的oplog
db.oplog.rs.drop()
3 :Create a New Oplog
创建一个新的Oplog，大小为2G
db.runCommand( { create: "oplog.rs", capped: true, size: (2 * 1024 * 1024 * 1024) } )
插入前面保存的旧的oplog的时间点的记录
db.oplog.rs.save( db.temp.findOne() )
db.oplog.rs.find()
4 :Restart the Member：
关闭单机实例：
use admin
db.shutdownServer()
修改回配置＃ vim /etc/mongo.conf
  dbpath=/var/lib/mongodb
  logpath=/var/log/mongodb/mongo.log
  pidfilepath=/var/run/mongo.pid
  directoryperdb=true
  logappend=true
  replSet=repset
  bind_ip=192.168.1.100,127.0.0.1
  port=37017
  oplogSize=2000
  fork=true
启动mongod
＃ mongod -f /etc/mongo.conf
重复上述步骤到所有需要更改的节点。
方式二： 步骤：
1:停掉所有replca set节点.
2:主节点删除local库下的文件，从节点删除数据目录下所有文件.
3:修改所有节点配置文件.
4:重启所有节点.
5:重新配置replca set，从节点会重新同步所有数据（initial sync）.
ps：此法好处是简单，但需要停掉服务，且如果数据量很大，初始同步的成本较高
1 :关闭mongod实例(所有节点) use admin
db.shutdownServer()
2 :删除local数据库下的所有文件（PRIMARY节点） # rm -rf /var/lib/mongodb/local/*
  删除mongo数据目录（其他节点上操作，可不要删错哦，建议所有rm操作先mv，待无问题时候再删除）# rm -rf /var/lib/mongodb/*
3 修改所有节点配置文件（oplogsize） ＃ vim /etc/mongo.conf
  dbpath=/var/lib/mongodb
  logpath=/var/log/mongodb/mongo.log
  pidfilepath=/var/run/mongo.pid
  directoryperdb=true
  logappend=true
  replSet=repset
  bind_ip=192.168.1.100,127.0.0.1
  port=37017
  oplogSize=2000
  fork=true
4 重启所有节点mongod mongod -f /etc/mongo.conf

SpringBoot高级篇MongoDB之修改基本使用姿势 本篇依然是MongoDB curd中的一篇，主要介绍document的更新，主要内容如下 常见类型成员的修改 数组类型成员的增删改 document类型成员的增删改
mongodb 基于oplog的时间点恢复 本文简单介绍mongodb时间点恢复的过程： 1.首先创建hezi集合，并插入10000条数据； MongoDB Enterprise liuhe_rs:PRIMARY use liuwenhe MongoDB Enterprise liuhe_rs:PRIMARY for ( var i = 0; i 100000; i++) { db.hezi.insert({id: i}); MongoDB Enterprise liuhe_rs:PRIMARY db.hezi.count(); 100000 2.执行备份操作，使用参数 --oplog ，会在备份路径下产生oplog.b
MongoDB Oplog Stones 实现分析及启动加载优化 对 Oplog Stones 的实现和初始化流程进行了详细的分析，简单分析了 Oplog 回收的逻辑。并对 oplog stones 的启动加载流程进行了优化，对比有数量级提升。
MongoDB 定位 oplog 必须全表扫描吗？ MongoDB oplog （类似于 MySQL binlog） 记录数据库的所有修改操作，除了用于主备同步；oplog 还能玩出很多花样，比如 全量备份 + 增量备份所有的 oplog，就能实现 MongoDB 恢复到任意时间点的功能 通过 oplog，除了实现到备节点的同步，也可以额外再往单独的集群同步数据（甚至是异构的数据库），实现容灾、多活等场景，比如阿里云开源的 MongoShake 就能实现基于 oplog 的增量同步。
一、文档替换     文档替换其实在之前已经有讲过了，就是传入两个对象，第一个对象作为调节，第二个条件作为满足条件的文档修改的内容，例如：     db.test.
涂宗勋 认真生活，快乐工作，保持理想！https://blog.csdn.net/tuzongxun