mongodb 概述

############对mongo db中某个集合做分片################# 本例中test1为数据库，test1也为集合名===

1、先enable sharding，开启数据库的分片功能

mongos> use admin

mongos> db.runCommand({"enablesharding":"test1"})

2、对具体collection做分片, 选择片键为"_id"

mongos> db.runCommand({"shardcollection":"test1.test1","key":{"_id":1}})

{ "collectionsharded" : "test1.test1", "ok" : 1 }

3、观察2个分片 shard_01  shard_02 tunks 数量

===========MongoDB=====复制集读写设置====

write concern 

默认情况下，Primary完成写操作即返回，Driver可通过设置[Write Concern]来设置写成功的规则。

如下的write concern规则设置写必须在大多数节点上成功，超时时间为5s。

cfg = rs.conf()

cfg.settings = {}

cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 }

rs.reconfig(cfg)

数据同步

Primary与Secondary之间通过oplog来同步数据，Primary上的写操作完成后，会向特殊的local.oplog.rs特殊集合写入一条oplog，Secondary不断的从Primary取新的oplog并应用。

因oplog的数据会不断增加，local.oplog.rs被设置成为一个capped集合，当容量达到配置上限时，会将最旧的数据删除掉。另外考虑到oplog在Secondary上可能重复应用，oplog必须具有幂等性，即重复应用也会得到相同的结果。

如下oplog的格式，包含ts、h、op、ns、o等字段

{

  "ts" : Timestamp(1446011584, 2),

  "h" : NumberLong("1687359108795812092"), 

  "v" : 2, 

  "op" : "i", 

  "ns" : "test.nosql", 

  "o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" } 

}

}

ts： 操作时间，当前timestamp + 计数器，计数器每秒都被重置

h：操作的全局唯一标识

v：oplog版本信息

op：操作类型

i：插入操作

u：更新操作

d：删除操作

c：执行命令（如createDatabase，dropDatabase）

n：空操作，特殊用途

ns：操作针对的集合

o：操作内容，如果是更新操作

o2：操作查询where条件，仅update操作包含该字段

========oplog 与journal日志问题==========张友东博客===========

MongoDB 复制集里写入一个文档时，需要修改如下数据

将文档数据写入对应的集合

更新集合的所有索引信息

写入一条oplog用于同步

上面3个修改操作，需要确保要么都成功，要么都失败，不能出现部分成功的情况。

MongoDB 在写入数据时，会将上述3个操作放到一个 wiredtiger 的事务里，确保「原子性」

wiredtiger 提交事务时，会将所有修改操作应用，并将上述3个操作写入到一条 journal 操作日志里；后台会周期性的checkpoint，将修改持久化，并移除无用的journal。

谁先写入？

oplog 与 journal 是 MongoDB 里不同层次的概念，放在一起比先后本身是不合理的。

oplog 在 MongoDB 里是一个普通的集合，所以 oplog 的写入与普通集合的写入并无区别。

一次写入，会对应数据、索引，oplog的修改，而这3个修改，会对应一条journal操作日志

####====具体部分参考了张友东博客======#####

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28211342/viewspace-2213184/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28211342/viewspace-2213184/