MongoDB分片集群与复制集

分片集群 
1.1、概念 
分片集群是将数据存储在多台机器上的操作，主要由查询路由mongos、分片、配置服务器组成。 
●查询路由根据配置服务器上的元数据将请求分发到相应的分片上，本身不存储集群的元数据，只是缓存在内存中。 
●分片用来存储数据块。数据集根据分片键将集合分割为数据块，存储在不同的分片上。在生产环境下，通常一个分片由一个复制集组成。 
●配置服务器存储集群的元数据，包括数据与分片的映射关系，配置服务器一旦挂掉，集群将无法工作。 
注意： 
●当mongos重启时，会从配置服务器读取元数据更新自己缓存的元数据 
●当分割数据时或者在分片间移动数据时会写配置服务器。 
●在分片集群中，配置服务器可以采用复制集的架构，但复制集中不允许有仲裁节点和延时节点，且buildindexes必须设为true。 
●集合的数据分布在多个分片上，如果某个分片失效，查询会返回错误，可以通过为查询指定partial选项，允许接受不完整的数据 
作用 
单台机器无法满足存储需求，内存、磁盘空间不够，读写吞吐量不够。 
1.2、如何维护数据均衡分布 
集群使用分割器和平衡器两个后台进程维护数据均匀分布。 
分割器 
●分割器的作用是防止数据块变大，数据块大小默认是64MB，当超过64MB时，分割器会将其一分为二。 
●分割的对象不是实际的数据，而是元数据，只是在逻辑上进行逻辑块的划分，不会影响到实际数据的分布 
●数据块太小会产生大量块，容易使集群不平衡，导致数据块频繁移动，降低集群性能，元数据增加，降低查询效率 
●数据块太大，会减小移动频率，元数据少，有利于数据查询，但一旦移动，会花费很长时间 
●并不是所有的集合都会分片，没有被分片的集合都存储在同一个主分片上 
●只有对数据库和集合开启分片后，数据才会在不同分片上分布，否则只存储在主分片上 
●插入和更新操作都有可能引发分割 
平衡器 
●平衡器的作用是管理数据块的移动。 
●当集群中数据块的分布达到移动阈值时，平衡器会移动数据块。 
●增加或减少分片或增删数据也会使平衡器移动数据块 
1.3数据块如何存储在相应分片上 
每个需要被分片的集合都需要指定索引字段作为分片键，MongoDB使用区间分区或哈希分区算法根据分片键将数据分割为数据块。 
●区间分区 
数据块覆盖一段子区间，任何分片键都会被某一段覆盖 
优缺点 
区间分区支持更好的range查询，通过分片键查询，查询路由可以很容易的判断出哪些数据块含有查询需要数据，并将请求分配到的分片上。 
区间分区使数据分布不均匀 
●哈希分区 
根据分片键的哈希值进行数据的分配。 
优缺点 
数据随机分配到不同的数据块 
在进行range查询时，由于相邻数据分布在不同分片上，导致访问很多分片 
注意 
●分片键不能是多键索引，即索引字段的值不能是数组 
●分片键一旦被指定，不能被修改为其他字段，同时分片键的字段值也不能被修改 
●如果集群的写操作比较多，可以使用哈希分区，将数据均匀分配到节点上，将写操作均匀应用与集群， 
如果集群读操作比较多，可以使用区间分区，将相邻数据分到同一节点上，便于查询 
●如果查询时没有指定索引字段，查询路由会将请求分发到所有节点上，等待返回结果，查询效率低 
如果查询时指定了索引字段，查询路由会将请求分发到少数节点上，查询效率高 
1.4、数据迁移过程 
●平衡器向源节点发送movechunk指令 
●源节点移动指定数据块，在迁移期间，数据块的读写操作仍路由到源节点 
●目的节点如果没有需要的索引，此时会构建索引 
●目的节点开始请求数据块中的数据，保存在本地 
●在迁移期间，源节点上的数据如果发生变化，在迁移完之后，目的节点会同步源节点上变更的数据 
●同步结束后，目的节点会与配置服务器建立连接，配置服务器更新元数据，此期间源节点阻塞写操作 
●源节点上的旧数据被删除 
1.5、备份数据 
mongodump -h dbhost -d dbname -o directory 命令格式 
mongodump -h 127.0.0.1：28002 -d test -o /home/backup 
将本机数据库test中数据备份到/home/backup下 
恢复数据 
mongorestore -h dbhost -d dbname –directoryperdb dbdirectory dbdirectory为备份数据所在位置

复制集 
2.1、概念与特性 
概念 
复制集是一组具有相同数据的mongod实例，包含主节点以及从节点。集群中任何时候只有一个主节点，主节点将数据变更操作写到oplog（封顶表）中，从节点读取oplog，并将oplog中的操作应用的本地数据，从而实现数据同步。

特性 
●异步复制 
从节点并不是实时复制主节点中的数据 
●自动容灾 
主节点宕机，主动发起选举 
●读操作 
从从节点上读到的数据可能并不是最新的 
2.2、复制集成员 
复制集最多包含50个节点，最多只能有7个可以投票。包含以下节点类型 
●主节点primary 
可以执行读写操作，所有节点均可以执行读操作。默认情况下，读请求只会发送给主节点，可以通过read preference设置。主节点的优先级priority至少为1。 
●从节点secondary 
只可以执行读操作。从节点通过与主节点同步，实现备份数据的功能，复制集至少有一个从节点。通过配置复制集的配置文件可以设置从节点是否参与选举（vote=0）以及是否可以被选举为主节点（priority=0）优先级priority为0的节点不能发起选举，不能被选举为主节点，但可以投票。 
●隐藏节点 
通过设置从节点的hidden属性，可以对客户端隐藏节点，不接受读写请求，无法被选举为主节点（priority=0），只能投票，主要用于备份数据。 
●延时节点 
通过设置隐藏节点的slaveDelay属性可以使节点延时一定时间从主节点复制数据，可以起到保护数据的作用。延时节点是在隐藏节点的基础上，多了一个延时属性。 
●仲裁节点Arbiter 
本身不存储数据，不能被选举为主节点，只能投票，仲裁节点主要用于使复制集中节点个数为奇数，从而容易达到多数派。仲裁节点只消耗极少的资源，但不要与主节点、从节点部署在同一个物理节点上。 
●非投票节点 
不参与投票，但存储数据，可以接受读操作 
2.3、复制集管理 
●use admin切换到admin数据库 
●config={_id:”myset”,members:[{“_id”:0,”host”:”127.0.0.1:28001”,”priority”:2},{“_id”:1,”host”:”127.0.0.1:28002”,”priority”:1}]} 
●rs.initiate(config) 
修改复制集配置 
●cfg=rs.conf() 
●cfg.members[0].priority=1 
●rs.reconfig(cfg) 
复制集维护 
将配置文件中的replset注释掉，从而以单机模式启动复制集，维护完毕后再加入复制集。 
2.4、大多数原则 
概念 
如果复制集中的节点个数为N，则大多数为N/2+1（N/2向下取整），当复制集中存活节点数小于大多数时，不存在主节点，无法提供写服务。

作用 
大多数原则保证了，在任何时刻复制集中的主节点个数不会超过一个。比如复制集部署在两个机房，两个机房通信发生故障，不含有主节点的机房会选举出一个主节点，等到故障恢复，复制集就会存在两个主节点，无法保证数据的一致性。 
2.5、选举 
选举的前提条件 
复制集满足大多数原则。在选举的过程中，复制集无法进行写操作。

何时会引发选举 
●复制集初始化时或被重新配置后 
●主节点宕机或主节点网络不可达，即大多数节点无法连接主节点 
●人为将主节点降为从节点，执行rs.stepDown(n)命令 
●有更高优先级的节点加入复制集

选举特点 
●优先级高的节点优先被选为主节点 
●具有最高optime的节点被选为主节点 
●如果优先级高的节点不具有最新的optime，那么首先会同步主节点的oplog 
●优先级为0的节点无法发起选举，且无法成为主节点，只能投票。 
●所有成员都可以否决选举，包括不投票的节点Non-voting

何时否决选举 
●发起选举的节点不包含最新数据 
●发起选举的节点优先级比其他节点低 
●发起选举的节点没有持有最高的optime 
2.6、数据回滚 
概念：在主节点失效之前，从节点并未全部复制主节点上的数据，原先的主节点在选举出新的主节点后重新加入复制集，会导致旧主节点与新主节点数据不一致，旧主节点会将不一致的数据回滚，从而与主节点数据保持一致。

避免数据回滚 
默认情况下，在主节点上写入成功后，就会向客户端返回结果，可能造成回滚，客户端可以修改写策略writeconcern为向大多数节点写入成功后才返回结果。 
2.7、读写策略 
writeconcern：不等待主节点写入成功，客户端就返回结果；等待主节点写入成功，就返回结果；等到大多数节点写入成功，才返回结果 
readconcern：只读主节点、只读从节点、优先主节点、优先从节点、读网络延迟最小的节点 
2.8、复制集优缺点 
优点 
●自动容灾。主节点宕机，通过投票选举主节点，保证数据安全 
●自动备份数据，无需人工干预 
●易于扩展 
●数据可靠性高 
缺点 
●消耗资源高 
●不能解决负载均衡的问题 
●客户端读到的数据可能并未持久化 ，比如：客户端可以读到最新写入的数据，但数据有可能存在磁盘写入失败的可能；客户端读到的数据可能发生rolled back