ttlsa教程系列之mongodb——(五)mongodb架构-复制原理&复制集

为什么80%的码农都做不了架构师？>>>   

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

转载于:https://my.oschina.net/766/blog/211104