MongoDB Oplog

最新推荐文章于 2024-09-21 11:30:16 发布

weixin_30670965

最新推荐文章于 2024-09-21 11:30:16 发布

阅读量76

点赞数

文章标签：数据库操作系统

原文链接：http://www.cnblogs.com/duanxz/p/4375252.html

版权

Capped Collections

MongoDB有一种特殊的Collection叫Capped collections，它的插入速度非常快，基本和磁盘的写入速度差不多，并且支持按照插入顺序高效的查询操作。Capped collections的大小是固定的，它的工作方式很像环形缓冲器(circular buffers)，当剩余空间不足时，会覆盖最先插入的数据。

Capped collections的特点是高效插入和检索，所以最好不要在Capped collections上添加额外的索引，否则会影响插入速度。Capped collections可以用于以下场景：

存储日志： Capped collections的first-in-first-out特性刚好满足日志事件的存储顺序；
缓存小量数据：因为缓存的特点是读多写少，所以可以适当使用索引提高读取速度。

Capped collections的使用限制：

如果更新数据，你需要为之创建索引以防止collection scan；
更新数据时，文档的大小不能改变。比如说name属性为'abc'，则只能修改成3个字符的字符串，否则操作将会失败；
数据不允许删除，如果非删除不可，只能drop collection
不支持sharding
默认只支持按自然顺序(即插入顺序)返回结果

Capped collections可以使用$natural操作符按插入顺序的正序或反序返回结果：

db['oplog.rs'].find({}).sort({$natural: -1})

二、oplog简介

Oplog是一种特殊的Capped collections，特殊之处在于它是系统级Collection，记录了数据库的所有操作，集群之间依靠Oplog进行数据同步。Oplog的全名是local.oplog.rs，位于local数据下。由于local数据不允许创建用户，如果要访问Oplog需要借助其它数据库的用户，并且赋予该用户访问local数据库的权限，例如：

db.createUser({
   user: "play-community",
   pwd: "******",
   "roles" : [
    {
      "role" : "readWrite", 
      "db" : "play-community"
    }, 
    {
      "role" : "read", 
      "db" : "local"
    }
  ]
})

Oplog记录的操作记录是幂等的(idempotent)，这意味着你可以多次执行这些操作而不会导致数据丢失或不一致。例如对于$inc操作，Oplog会自动将其转换为$set操作，例如原始数据如下：

{ 
  "_id" : "0", 
  "count" : 1.0
}

执行如下$inc操作：

db.test.update({_id: "0"}, {$inc: {count: 1}})

Oplog记录的日志为：

{ 
  "ts" : Timestamp(1503110518, 1), 
  "t" : NumberLong(8),    "h" : NumberLong(-3967772133090765679),    "v" : NumberInt(2),    "op" : "u",    "ns" : "play-community.test",    "o2" : {     "_id" : "0"   },    "o" : {     "$set" : {       "count" : 2.0     }   } }

这种转换可以保证Oplog的幂等性。另外Oplog为了保证插入性能，不允许额外创建索引。

oplog是local库下的一个固定集合，Secondary就是通过查看Primary 的oplog这个集合来进行复制的。每个节点都有oplog，记录这从主节点复制过来的信息，这样每个成员都可以作为同步源给其他节点。

Timestamps格式

MongoDB有一种特殊的时间格式Timestamps，仅用于内部使用，例如上面Oplog记录：

Timestamp(1503110518, 1)

Timestamps长度为64位：

前32位是time_t值，表示从epoch时间至今的秒数
后32位是ordinal值，该值是一个顺序增长的序数，表示某一秒内的第几次操作

三、副本集数据同步的过程

副本集中数据同步的详细过程：Primary节点写入数据，Secondary通过读取Primary的oplog得到复制信息，开始复制数据并且将复制信息写入到自己的oplog。如果某个操作失败（只有当同步源的数据损坏或者数据与主节点不一致时才可能发生），则备份节点停止从当前数据源复制数据。如果某个备份节点由于某些原因挂掉了，当重新启动后，就会自动从oplog的最后一个操作开始同步，同步完成后，将信息写入自己的oplog，由于复制操作是先复制数据，复制完成后再写入oplog，有可能相同的操作会同步两份，不过MongoDB在设计之初就考虑到这个问题，将oplog的同一个操作执行多次，与执行一次的效果是一样的。可以简单的将其视作Mysql中的binlog。

3.1、同步类型

initial sync（初始化）：这个过程发生在当副本集中创建一个新的数据库或其中某个节点刚从宕机中恢复，或者向副本集中添加新的成员的时候，默认的，副本集中的节点会从离它最近的节点复制oplog来同步数据，这个最近的节点可以是primary也可以是拥有最新oplog副本的secondary节点。

replication（复制）：在初始化后这个操作会一直持续的进行着,以保持各个secondary节点之间的数据同步。

3.2、Oplog大小：

capped collection是MongoDB中一种提供高性能插入、读取和删除操作的固定大小集合，当集合被填满的时候，新的插入的文档会覆盖老的文档。

在64位的Linux,Solaris,FreeBSD以及Windows系统上，MongoDB会分配磁盘剩余空间的5%作为oplog的大小，如果这部分小于1GB则分配1GB的空间
在64的OS X系统上会分配183MB
在32位的系统上则只分配48MB

3.3、oplog的增长速度

oplog是固定大小，他只能保存特定数量的操作日志，通常oplog使用空间的增长速度跟系统处理写请求的速度相当，如果主节点上每分钟处理1KB的写入数据，那么oplog每分钟大约也写入1KB数据。如果单次操作影响到了多个文档（比如删除了多个文档或者更新了多个文档）则oplog可能就会有多条操作日志。db.testcoll.remove() 删除了1000000个文档，那么oplog中就会有1000000条操作日志。如果存在大批量的操作，oplog有可能很快就会被写满了。

6：oplog的监控

## 查看 oplog 的状态
shard1:PRIMARY> rs.printReplicationInfo()
configured oplog size: 1674.7353515625MB
log length start to end: 102397secs (28.44hrs)
oplog first event time: Tue Oct 09 2018 18:17:42 GMT+0800 (CST)
oplog last event time: Wed Oct 10 2018 22:44:19 GMT+0800 (CST)
now: Wed Oct 10 2018 22:44:23 GMT+0800 (CST

## 查看集群 Oplog 使用情况
shard1:PRIMARY> db.getReplicationInfo()
{
"logSizeMB" : 1674.7353515625,
"usedMB" : 0.33,
"timeDiff" : 102307,
"timeDiffHours" : 28.42,
"tFirst" : "Tue Oct 09 2018 18:17:42 GMT+0800 (CST)",
"tLast" : "Wed Oct 10 2018 22:42:49 GMT+0800 (CST)",
"now" : "Wed Oct 10 2018 22:42:52 GMT+0800 (CST)"
}

## 查看集群延迟情况
shard1:PRIMARY> db.printSlaveReplicationInfo()
source: 10.100.25.42:27001
syncedTo: Wed Oct 10 2018 22:40:39 GMT+0800 (CST)
0 secs (0 hrs) behind the primary