Oplog(operations log)是MongoDB Replica Set复制机制的基础。
在生产环境中部署replica set集群，设置合理的oplogSizeMB是很重要的，
这里[大小]是指local.oplog.rs固定集合的存储容量；
而oplog窗口时间 是从[时间]维度恒量oplog的大小，又名Oplog recovery window。
本文分几个小节，细说oplog recovey window:
Oplog窗口时间的定义
Oplog窗口时间过小的影响和监控
设置合理的Oplog size
如何修改Oplog Size
1 Oplog窗口时间的定义
oplog窗口时间:表示oplog.rs固定集合被写满时，存储的最新一条oplog记录与最旧一条的时间差；即表示oplog.rs能存储[多长时间跨度]的oplog记录，比如oplog.rs只能存储2天的oplog记录，那么这个节点的oplog recovery window就是2天。有的书籍又叫oplog-length或oplog maitenance window。
oplog的内容存储在local.oplog.rs的Capped collections中，oplog.rs能存储的数据容量是固定，当达到oplogSizeMB设置的上限时，就会清理最旧的oplog记录。 下图是一个oplog记录。
图1: oplog实例
2 Oplog窗口时间过小的影响
MongoDB的Primary与Secondary节点之间是通过oplog进行数据同步的，客户端在Primary写操作，就会在local.oplog.rs集合中写入一条或多条oplog记录(如图1）；Secondary节点通过获取Primary节点的oplog进行重放，以实现数据同步。
如果Primary节的oplog.rs固定集合容量设置不够大，如只能存储最近1小时oplog操作日志；那么MongoDB副本集集群的可用度风险很大。
延时备份节点(Delayed Secondary)失败；当延时节点设置的 延迟时长 > 主节点的oplog窗口时间;
易导致从节点复制同步中断；
数据恢复时可能导致全量备份和oplog衔接不上.
3 Oplog窗口时间监控
oplog的窗口时间属性，我们以小时为单位进行计算；
MongoDB自身提供获取oplog时间窗口函数： db.printReplicationInfo();
它只计算最旧和最新oplog.rs文档的ts差值，当oplog.rs固定集合没有“写满”时，这个计算是不合理的，比实际oplog窗口时间要小。
rsMongoBench:SECONDARY> db.printReplicationInfo(); configured oplog size: 40960MB log length start to end: 2183614secs (606.56hrs) oplog first event time: Wed Feb 15 2017 15:22:12 GMT+0800 (CST) oplog last event time: Sun Mar 12 2017 21:55:46 GMT+0800 (CST) now: Sun Mar 12 2017 21:55:46 GMT+0800 (CST)
在写的mongo监控插件时，建议使用以下方法计算，会相对精确。
计算方法： 通过计算oplog.rs固定集合中，最新一条文档与最旧文档的ts字段时间差，同时除以当前oplog.rs集合存储容量百分比。
Python代码的实现：
oplog_collection = connection["local"]["oplog.rs"] oplog_tFirst = oplog_collection.find({},{"ts"1}).sort('$natural',pymongo.ASCENDING).limit(1).next() oplog_tLast = oplog_collection.find({},{"ts":1}).sort('$natural',pymongo.DESCENDING).limit(1).next() oplogrs_collstats = connection["local"].command("collstats", "oplog.rs") window_multiple = 1.0 ##oplog.rs collections is not full if oplogrs_collstats.has_key("maxSize"): window_multiple = oplogrs_collstats["maxSize"]*1.0/(oplogrs_collstats["count"] * oplogrs_collstats["avgObjSize"])*1.0else: window_multiple = oplogrs_collstats["storageSize"]/(oplogrs_collstats["count"] * oplogrs_collstats["avgObjSize"])#oplog_window .xx hoursoplog_window = round((oplog_tLast["ts"].time - oplog_tFirst["ts"].time)/3600.0,2) * window_multiple*1.0 # full
oplog窗口时间的告警项
oplog窗口时间作为复制集重要的监控指标，需设置合理的告警项。
从上节采集oplog窗口时间单位是小时，建议设置1小时、24小时和48小时 分别是p0/p1/p2级别的告警
下面示例是oplog窗口时间小于24小时的p1级别短信告警：
ROBLEM P1 Endpoint:xx-dba-test-mgdb01.bj Metric:repl_oplog_window Tags:port=27017,role=master,service=test,type=mongodb all(#3): 23.09<=24Note:repl_oplog_window小于24小时 Max:3, Current:3Timestamp:2017-10-08 17:23:00
4 设置合理的Oplog size
目前最新版本的MongoDB3.4还不支持动态调整oplog.rs大小，其调整成本较大(详情见下节调整oplog.rs大小）； 为避免副本集群进行oplog大小调整，我们尽量设置一个合理大小的oplog.rs。
计算公式：
oplog.rs大小 = oplog窗口时间(单位小时) * oplog容量增速 oplog容量增速 = oplog每小时写入文档数(速率) * oplog.rs平均文档大小
我们在设置oplog.rs大小前，就需确定oplog窗口时间，以及当前副本集写入数据的速率、oplog.rs平均文档大小。
例如，我们设置副本集oplog窗口时间最小为2天(48小时), 每小写入的oplog容量为1GB,那么当前副本集的oplog大小至少设置为48GB.
那么为避免oplog窗口时间过小问题，是否设置一个超大的oplog ？例如200GB。
这样存储成本，如果我们使用备份文件(dbpath)的方式进行MongoDB数据备份，那local.oplog.rs数据每次都会拷贝；这样备份的存储成本，及数据还原RTO都会受到影响。
所以oplog并不是越大越好，保证足够的窗口时间就行；
常规集群设置40GB(这已经是很大的设置，请根据实际业务进行评估设置),时间窗口都会在7天以上。
5 如何修改Oplog Size
因oplog窗口时间变小，可能导致从节点因过旧导致复制中断，变成Recovering状态；我们需oplog.rs进行调大处理。
操作流程：
1. 关闭一个从节点，并以`standalone instance`方式启动 2. 备份此节点oplog.rs集合中最新文档记录 3. 删除oplog.rs集合 4. local库中创建oplog.rs的新集合 5. 把2步中备份的文档insert到新的oplog.rs中 6. 以`副本集`方式重新启动此节点，会自动加入集群中； 当前节点oplog调整完成; 7. 再按以上步骤调整其他从节点；最后主节点通过一次切换，变成从节点后再修改oplog大小。
详细的操作步骤，请见手册：Change the size of oplog(https://docs.mongodb.com/manual/tutorial/change-oplog-size/)
在MongoDB3.6版本(目前RC阶段)，使用wiredTiger存储引擎的实例可通过replSetResizeOplog动态修改oplog的大小replSetResizeOplog(https://docs.mongodb.com/master/reference/command/replSetResizeOplog/#dbcmd.replSetResizeOplog)。
-END-
▼
