MongoDB--副本集基本信息

副本集的概念

副本集是一组服务器，其中有一个是主服务器（primary），用于处理客户端请求；还有多个备份服务器（secondary），用于保存主服务器的数据副本。若是主服务器崩溃了，备份服务器会自动将其中一个成员升级为新的主服务器。

副本集特征：
　　· N 个节点的集群
　　· 任何节点可做为主节点
　　· 全部写入操做都在主节点上
　　· 自动故障转移
　　· 自动恢复
副本集还有如下几个须要注意的地方：
　　1. 最小构成是：primary，secondary，arbiter，通常部署是：primary，2 secondary。
　　2. 成员数应该为奇数，若是为偶数的状况下添加arbiter，arbiter不保存数据，只投票。
　　3. 最大50 members，可是只能有 7 voting members，其余是non-voting members。

 

一、数据同步
　　　　Mongo的复制功能是经过oplog实现的，oplog包含了主节点的每一次写操做，是主节点的local数据库中的一个固定集合，备份节点经过查询这个集合就能够知道须要进行复制的操做。每一个备份节点有本身的oplog，这样每一个成员就能够看成同步源提供给其余成员使用。备份节点从当前同步源中获取须要执行的操做，而后在本身的数据集上执行这些操做，最后将这些操做写入本身的oplog。

　　　　若是备份节点挂了，当它重启后，会自动从oplog中最后一个操做开始同步，因为复制操做的过程是先复制数据再写入oplog，因此备份节点有可能在已经同步过的数据上再次执行复制操做。Mongo是这么处理的：将oplog中的同一操做执行屡次与只执行一次的效果是同样。

　　　　因为oplog大小是固定的，一般它的使用空间的增加速度与系统处理写请求的速率近乎相同。可是有些例外状况：若是单次处理可以影响到多个文档，那么每一个受影响的文档都会对应oplog的一条日志。好比执行db.coll.remove()删除了1000000个文档，那么oplog中就会有1000000条操做日志，这样oplog很快就会被填满。

 

二、仲裁节点
　　仲裁者惟一的做用就是选举，不保存数据，也不会为客户端提供服务，它只是为了知足“大部分”的要求

　　添加仲裁者的两种方式

　　　　>rs.addArb(“server-5:27017”)

　　　　>rs.add({“_id”:4,”host”:” server-5:27017”,”arbiterOnly”:true})

　

　仲裁的缺点

　　　　好比有三个成员的副本集，其中一个是仲裁节点。当一个数据节点挂了，那么另外一个数据节点成为主节点，为了保证数据安全，就须要添加一个新的备份节点，但因为仲裁节点无数据，那么新节点的数据传输只能靠当前的主节点完成。那么它不只要处理应用程序请求，还要数据复制到备份节点，会形成服务器压力巨大

　　　　因此尽可能配置成奇数个数据成员，而不使用仲裁者

 

 

三、优先级
　　优先级表示一个成员渴望成为主节点的程度，取值范围0-100，默认1，0表明永远不能成为主节点（passive member）

　　优先级别高的会优先选举为主节点（只要他能获得大部分的支持，而且数据是最新的）

四、心跳
　　每一个成员每隔两秒都会向其余成员发送一个心跳请求，用于检查每一个成员的状态，知道本身是否符合大多数的条件。

 

五、回滚
　　若是主节点执行了一次写请求后挂了，可是备份节点还没来得及复制此次操做，那么新选举出来的主节点就会漏掉此次写操做。这时就会执行回滚过程。

 

六、内存管理mmap

　　 mongodb的全部数据其实是存放在硬盘的，全部要操做的数据经过 mmap的方式映射到 内存某个区域内。

　　而后， mongodb就在这块区域里面进行数据修改，避免了零碎的硬盘操做。

　　至于mmap上的内容flush到硬盘就是操做系统的事情了，因此，若是，mongodb在内存中修改了数据，而后，mmap数据flush到硬盘以前，系统当机了，就会丢失数据了。

 

　　mysql，不管数据仍是索引都存放在硬盘中。到要使用的时候才交换到内存中。可以处理远超过内存总量的数据。

 

　　数据量和性能

　　　　 当物理内存够用的时候，redis》mongodb》mysql

 

　　mysql垫底是确定的。至于，redis为何比mongodb快。仍是跟场景和使用业务有关系的。

　　大部分情景下，因为mongodb要兼顾它特有的弱表结构下复杂的查询，在不少存取过程上作了妥协。

　　其实，这里并不想说redis和mongodb的性能怎样，只想说明下随着数据量的增加，redis和mongodb，mysql是怎么变化的。

 

　　当物理内存不够用的时候

　　redis和mongodb都会使用虚拟内存。

　　实际上若是redis要开始虚拟内存，那很明显要么加内存条，要么你换个数据库了。

　　可是，mongodb不同，只要，业务上能保证，冷热数据的读写比，使得热数据在物理内存中，mmap的交换较少。mongodb仍是可以保证性能。有人使用mongodb存储了上T的数据。

　　mysql，mysql根本就不须要担忧数据量跟内存下的关系。不过，内存的量跟热数据的关系会极大地影响性能表现。

 

　　当物理内存和虚拟内存都不够用的时候

　　估计除了mysql你没什么好选择了。

 

 

　　其实，从数据存储原理来看，我更倾向于将mongodb归类为硬盘数据库，可是使用了mmap做为加速的手段而已。

       MongoDB应该分配的内存大小最好知足内存大小>索引+热数据+链接占用内存，经过db.stats()命令可查看到当前数据库的索引大小状况
　    db.stats()

      下面是公司的MongoDB存储了14亿数据，占1.4T存储空间

shard1:SECONDARY> db.stats()
{
    "db" : "database",　　　　　　　　　 　　// 当前使用的数据库　
    "collections" : 662,       　　　　　　// 多少张表 
    "objects" : 1405948982,　　　　　　　　 // 全部表的多少条数据    　　-- 14.05亿
    "avgObjSize" : 1134.649427176014,    // 平均每条数据大小  　　 　 
    "dataSize" : 1595259207065,　　　　　　// 总数据大小　　　　　　　　 -- 1.485TB
    "storageSize" : 768647647232,　　　　　// 全部数据占磁盘的大小　　  -- 715.85G
    "numExtents" : 0,
    "indexes" : 1098,　　　　　　　　　　　　// 索引数量
    "indexSize" : 173431967744,　　　　　　// 索引大小 　　　　　　　　 -- 160G
    "ok" : 1
}