MongoDB集群配置笔记一

MongoDB 的部署方案有单机部署、复本集（主备）部署、分片部署、复本集与分片混合部署。
混合的部署方式如图：

分片集群的构造

（1）mongos ：数据路由，和客户端打交道的模块。mongos本身没有任何数据，他也不知道该怎么处理这数据，去找config server

（2）config server：所有存、取数据的方式，所有shard节点的信息，分片功能的一些配置信息。可以理解为真实数据的元数据。

（3）shard：真正的数据存储位置，以chunk为单位存数据。

Mongos本身并不持久化数据，Sharded cluster所有的元数据都会存储到Config Server，而用户的数据会议分散存储到各个shard。Mongos启动后，会从配置服务器加载元数据，开始提供服务，将用户的请求正确路由到对应的碎片。

MongoDB 的适用场景如下:

1）网站实时数据:MongoDB 非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
2）数据缓存:由于性能很高，MongoDB 也适合作为信息基础设施的缓存层。在系统重启之后，由MongoDB搭建的持久化缓存层可以避免下层的数据源过载。
3）大尺寸、低价值数据存储:使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储。
4）高伸缩性场景:MongoDB 非常适合由数十或数百台服务器组成的数据库。MongoDB 的路线图中已经包含对MapReduce 引擎的内置支持。
5）对象或JSON 数据存储:MongoDB 的BSON 数据格式非常适合文档化格式的存储及查询。

不适用场景
1）高度事务性系统:例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
2）传统的商业智能应用:针对特定问题的BI 数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
3）需要复杂SQL 查询的问题。

Mongodb的优点与不足
（1）Mongodb的不足之处
1、在集群分片中的数据分布不均匀
2、单机可靠性比较差
3、大数据量持续插入，写入性能有较大波动
4、磁盘空间占用比较大
（2）Mongodb的过人之处
1、无模式
2、查询与索引方式灵活，是最像SQL的Nosql
3、支持复制集、主备、互为主备、自动分片等特性

mongodb 文件存储是BSON格式类似JSON，或自定义的二进制格式。

MongoDB集群设置

副本集比传统的Master-Slave主从复制有改进的地方就是它可以进行故障的自动转移,如果我们停掉复制集中的一个成员,那么剩余成员会再自动选举一个成员,作为主库.

Replica Set 使用的是 n 个 mongod 节点,构建具备自动的容错功能(auto-failover),自动恢复的(auto-recovery)的高可用方案。使用 Replica Set 来实现读写分离。通过在连接时指定或者在主库指定 slaveOk,由Secondary 来分担读的压力,Primary 只承担写操作。对于 Replica Set 中的 secondary 节点默认是不可读的。

副本集包括三种节点:主节点、从节点、仲裁节点。

1）主节点负责处理客户端请求,读、写数据, 记录在其上所有操作的 oplog;

2）从节点定期轮询主节点获取这些操作,然后对自己的数据副本执行这些操作,从而保证从节点的数据与主节点一致。默认情况下,从节点不支持外部读取,但可以设置;

副本集的机制在于主节点出现故障的时候,余下的节点会选举出一个新的主节点,从而保证系统可以正常运行。

3）仲裁节点不复制数据,仅参与投票。由于它没有访问的压力,比较空闲,因此不容易出故障。由于副本集出现故障的时候,存活的节点必须大于副本集节点总数的一半,

否则无法选举主节点,或者主节点会自动降级为从节点,整个副本集变为只读。因此,增加一个不容易出故障的仲裁节点,可以增加有效选票,降低整个副本集不可用的

风险。仲裁节点可多于一个。也就是说只参与投票，不接收复制的数据，也不能成为活跃节点。

`数据同步`

在副本集中,有两种数据同步方式:

1）initial sync

(初始化):这个过程发生在当副本集中创建一个新的数据库或其中某个节点刚从宕机中恢复,或者向副本集中添加新的成员的时候,默认的,副本集中的节点会从离 它最近

的节点复制 oplog 来同步数据,这个最近的节点可以是 primary 也可以是拥有最新 oplog 副本的 secondary 节点。该操作一般会重新初始化备份节点,开销较大。

2）replication(复制):在初始化后这个操作会一直持续的进行着,以保持各个 secondary 节点之间的数据同步。