MongoDB 主从复制(Master-Slave) 副本集(Replica Set) 分片(Sharding)

MongoDB 分片集群介绍
MongoDB 复制集原理深度分析

官方建议用副本集替代主从复制

MongoDB 中提供了复制(Replication)机制，通过该机制可以帮助我们很容易实现读写分离方案，并支持灾难恢复（服务器断电）等意外情况下的数据安全。
在老版本(1.6)中，Mongo提供了两种方式的复制：master-slave及replica pair模式（注:mongodb最新支持的replset复制集方式可看成是pair的升级版，它解决pair只能在两个结点间同步
的限制，支持多个结点同步且支持主从宕机时的自动切换, 在1.6版以后提供）。
一、Master-Slave(主从复制)模式，目前已经不推荐使用:
一个 Server 可以同时为 Master 和 Slave。一个Slave可以有多个Master（不推荐，可能会产生不可预期的结果）。

主从复制有Primary、Secondary、Arbiter三种角色。以三节点为例，一般一个Primary两个Secondary较为常见。一个复制集群最多有50个节点，但是最多有7个投票节点。
通过心跳检测确定节点是否存在，当发起Primary投票时，获得大多数成员投票支持的节点，会变为Primary。其他节点为Secondary。

配置选项：
--master：以主服务器方式启动；
--slave：以从服务器方式启动；
--autoresync：自动重新sync，因为该操作会copy 主服务器上的所有document，比较耗时，在10分钟内最多只会进行一次。（自动重新同步主服务器上的所有document）；
--oplogSize：指定master上用于存放更改的数据量，如果不指定，在32位机上最少为50M，在64位机上最少为 1G，最大为磁盘空间的5%。主节点的oplog日志大小，单位为M，建议设大点(更改oplog大小时，只需停主库，删除local.*，然后加–oplogSize=* 重新启动即可,*代表大小)；
--source：主服务器地址（与--slave组合使用）；
--only：仅限于同步指定数据库（下面示例为test库）；
--slavedelay：同步的延时时间，单位是秒；

下面是在本地为了测试方便所使用的配置参数
Master:  IP->10.0.1.103       
mongod --dbpath=d:\mongodb\db --master --oplogSize 64       
Slave:   IP->10.0.4.210
mongod --dbpath=d:\mongodb\db --slave --source 10.0.1.103:27017 --only test --slavedelay 100

 

二、Replica pairs模式
以这种方式启动后，数据库会自动协商谁是master谁是slave。一旦一个数据库服务器断电，另一个会自动接管，并从那一刻起起为master。万一另一个将来也出错了，那么master状态将会转回给第一个服务器。以这种复制方式启动mongod的命令如下：
配置选项：
mongod --pairwith <remoteserver> --arbiter <arbiterserver>
--pairwith: remoteserver是pair里的另一个server
--arbiter:  arbiterserver是一个起仲裁作用的Mongo数据库，用来协商pair中哪一个是master。arbiter运行在第三个机器上，利用“平分决胜制”决定在pair中的两台机器不能联系上对方时让哪一个做master，一般是能同arbiter通话的那台机器做master。如果不加--arbiter选项，出现网络问题时两台机器都作为master。
注：可使用db.$cmd.findOne({ismaster:1})可以检查当前哪一个database是master。

另外这种模式下的两台机器只能满足最终一致性。当replica pair中的一台机器完全挂掉时，需要用一台新的来代替。如(n1, n2)中的n2挂掉，这时用n3来代替n2。

步骤如下：
1. 告诉n1用n3来代替n2：db.$cmd.findOne({replacepeer:1});
2. 重启n1让它同n3对话：mongod --pairwith n3 --arbiter <arbiterserver>
3. 启动n3：mongod --pairwith n1 --arbiter <arbiterserver>。
在n3的数据没有同步到n1前n3还不能做master，这个过程长短由数据量的多少决定。

三、oplog
mongodb使用cap collection来存储操作日志，并进而使用日志来复制(同步)结点间的数据，其中由主结点保存的操作的记录叫做oplog(operation log的简称)。
Oplog存在一个叫local的特殊数据库中，在oplog.$main集合。Oplog中的每一个文档表示一个在主结点上执行的操作。文档主要包括4块内容，如下：
 Ts:操作的时间戳。时间戳类型是一个用来跟踪操作是何时执行的一种内部类型。它由4字节的时间戳和四字节的增量计数器组成。
 Op:执行的操作的类型，大小为1字节。（例如，“i”代表insert,"u":update, "d":delete, "n":none无操作等）
 Ns：执行操作的命名空间（集合名）
 O：执行操作的文档。对于插入，这是将要插入的文档。
另外这种日志只保存会“改变数据库状态”的操作。查询操作不会记录在oplog中。

四、副本集(Replica Set)
副本集(Replica Set) 模式取代了 主从复制(Master-Slave)  模式，是⼀种互为主从的关系MongoDB

副本集中的各节点会通过⼼跳信息来检测各⾃的健康状况，当主节点出现故障时，多个从节点会触发⼀次新的选举操作，并选举其中⼀个作为新的主节点。为了保证选举票数不同，副本集的节点数保持为奇数。

五、分片(Sharding)
MongoDB 分片集群介绍

分片是为了应对高吞吐量和高并发量。通过水平分片，将数据集分散到不同的服务器节点上，提高整体的吞吐量和并发量。

构建⼀个 MongoDB 的分⽚集群，需要三个重要的组件，分别是分⽚服务器（Shard Server）、配置服务器（Config Server）和路由服务器（Route Server）。
Shard Server：每个 Shard Server 都是⼀个 mongod 数据库实例，⽤于存储实际的数据块。整个数据库集合分成多个块存储在不同的 Shard Server 中。
在实际⽣产中，⼀个 Shard Server 可由⼏台机器组成⼀个副本集来承担，防⽌因主节点单点故障导致整个系统崩溃。
Config Server：这是独⽴的⼀个 mongod 进程，保存集群和分⽚的元数据，在集群启动最开始时建⽴，保存各个分⽚包含数据的信息。
Route Server：这是独⽴的⼀个 mongos 进程，Route Server 在集群中可作为路由使⽤，客户端由此接⼊，让整个集群看起来像是⼀个单⼀的数据库，提供
客户端应⽤程序和分⽚集群之间的接⼝。Route Server 本⾝不保存数据，启动时从 Config Server 加载集群信息到缓存中，并将客户端的请求路由给每个 Shard Server，在各 Shard
Server 返回结果后进⾏聚合并返回客户端。

以上介绍了 MongoDB 的三种集群模式，副本集已经替代了主从复制，通过备份保证集群的可靠性，分⽚机制为集群提供了可扩展性，以满⾜海量数据的存储和分析的需求。
*
*
*