ttlsa教程系列之mongodb——(五)mongodb架构-复制原理&复制集
mongodb集群：复制，复制集和分片。 强烈建议在生产环境中使用mongodb的复制功能。复制具有故障切换，读扩展，热备份和离线批处理操作。 默认情况下，主节点负责客户端所有的读写请求，从节点不可读不可写。 一. 工作原理 1. mongodb的复制至少需要两个实例。其中一个是主节点，负责处理客户端请求，其余的都是从节点，负责复制主节点上的数据。主节点记录在其上的所有操作oplog，从节点定期轮询主节点获取这些操作，然后对自己的数据副本执行这些操作，从而保证从节点的数据与主节点一致。 2. 主节点的操作记录称为oplog(operation log)，存储在local数据库中(local数据库不会被复制，用来存放复制状态信息的)。oplog中的每个文档代表着主节点上执行的操作。oplog只作为从节点与主节点保持数据同步的机制。 3. oplog.rs是一个固定长度的capped collection。默认情况下，64位的实例将使用oplog 5%的可用空间，这个空间将在local数据库中分配，并在服务器启动时预先分配。 4. 如果从节点落后主节点很远了，oplog日志从节点还没执行完，oplog可能已经轮滚一圈了，那么从节点将会追赶不上主节点了，复制将会停止。从节点需要重新做完整的同步，可以用{resync:1}命令来手动执行重新同步或在启动从节点时指定--autoresync选项让其自动重新同步。重新同步的代价昂贵，应尽量避免，避免的方法就是配置足够大的oplog。 查看oplog信息：
> db.oplog.rs.stats()
{
"ns" : "local.oplog.rs",
"count" : 7276573,
"size" : 1980730564,
"avgObjSize" : 272.20651314842854,
"storageSize" : 2097156096,
"numExtents" : 1,
"nindexes" : 0,
"lastExtentSize" : 2097156096,
"paddingFactor" : 1,
"systemFlags" : 0,
"userFlags" : 0,
"totalIndexSize" : 0,
"indexSizes" : {
},
"capped" : true,
"max" : 2147483647,
"ok" : 1
} 查看oplog.rs内容：
> db.oplog.rs.find().limit(1).toArray()
[
{
"ts" : Timestamp(1357529944000, 1),
"h" : NumberLong("-3237467944396345731"),
"v" : 2,
"op" : "i",
"ns" : "ttlsa_event.ttlsa_events",
"o" : {
"_id" : ObjectId("50ea43599ca66a2d7e000000"),
"aid" : 110000,
"kid" : 10007,
"tag" : "Mobile",
"uid" : 368514901,
"stmp" : 1357529945,
"born" : 1357529945,
"total" : 1,
"val" : [
{
"nickname" : "m44332148",
"productid" : 109350,
"product" : "三国时代OL",
"stmp" : 1357529945
}
]
}
}
] 字段说明： ts：操作的时间戳，用于跟踪操作执行的时间。 op：操作类型，i代表插入，u代表更新，d代表delete ns：执行操作的集合名 o: 文档内容 二. 复制 mongodb支持传统的master-slave架构。没有自动故障转移功能，需要指定master和slave端。强烈推荐使用复制集架构，复制集架构比复制架构更好维护，功能更强。 master-slave架构一般使用于下面两种情况： 1. slave超过11个 2. 需要复制单一的数据库 master-salve架构配置： // master server启动master，只需指定master参数
# mongod --master// slave server启动slave，需要指定slave参数和master的IP和端口
# mongod --slave --source master_server:27017主从复制的选项有： 1. --only 在slave节点上指定只复制的数据库 2. --slavedelay 指定slave节点延时多少秒同步master 3. --fastsync 以master节点的数据快照为基础启动slave节点 4. --autoresync 如果slave节点不同步了，则主动重新同步 5. --oplogSize master节点oplog大小 三. 复制集 复制集最少需要三台服务器或两台服务器+仲裁一台。 复制集的配置参见：http://www.ttlsa.com/html/1093.html 查看master 的oplog元数据信息：
> db.printReplicationInfo() configured oplog size: 2000MB log length start to end: 16685504secs (4634.86hrs) oplog first event time: Mon Jan 07 2013 11:42:50 GMT+0800 (CST) oplog last event time: Fri Jul 19 2013 14:34:34 GMT+0800 (CST) now: Fri Jul 19 2013 14:34:38 GMT+0800 (CST)字段说明： configured oplog size： oplog文件大小 log length start to end: oplog日志的启用时间段 oplog first event time: 第一个事务日志的产生时间 oplog last event time: 最后一个事务日志的产生时间 now: 现在的时间 查看slave的同步状态：
> db.printSlaveReplicationInfo()
source: 10.1.11.157:27017
no replication info, yet. State: ARBITER
source: 10.1.11.156:27017
syncedTo: Fri Jul 19 2013 14:34:42 GMT+0800 (CST)
= 2 secs ago (0hrs) 字段说明： source：从库的IP以及端口 syncedTo：当前的同步情况 增加节点：
ttlsa:PRIMARY> rs.add("10.1.11.111:27017") 减少节点：
ttlsa:PRIMARY> rs.remove("10.1.11.111:27017") 允许从库读操作：
ttlsa:SECONDARY> db.getMongo().setSlaveOK()手动转移primary：
ttlsa:SECONDARY> rs.freeze([secs]) //make a node ineligible to become primary for the time specified ttlsa:PRIMARY> rs.stepDown([secs]) //step down as primary (momentarily) (disconnects)复制集状态： 1. STARTUP：刚加入到复制集中，配置还未加载 2. STARTUP2：配置已加载完，初始化状态 3. RECOVERING：正在恢复，不适用读 4. ARBITER: 仲裁者 5. DOWN：节点不可到达 6. UNKNOWN：未获取其他节点状态而不知是什么状态，一般发生在只有两个成员的架构，脑裂 7. REMOVED：移除复制集 8. ROLLBACK：数据回滚，在回滚结束时，转移到RECOVERING或SECONDARY状态 9. FATAL：出错。查看日志grep "replSet FATAL"找出错原因，重新做同步 10. PRIMARY：主节点 11. SECONDARY：备份节点 四. 复制认证 如果启用了认证，需要在主节点和从节点上的local数据库下，建个相同的用户名和密码的用户，可读写。 从节点连接主节点时，会用存储在local.system.users中的用户进行认证，最先尝试用repl用户，若没有，则用local.system.users中的第一个可用用户。
> use local
> db.addUser("repl","password") 五. 分片 分片下一节说。 转载请注明出处： http://www.ttlsa.com/html/1679.html