MongoDB复制集副本集(Replica Set)搭建

MongoDB 是一个典型的NoSQL（not only sql）数据库是开源的面向文档的数据库管理系统，主要实现NoSQL数据库管理系统，用于存储海量数据（humongous，Mongo名称的由来）。。

ElasticSearch是基于Apache Lucene 的RESTful 实时搜索和分析引擎。ES基于数据抽取一些值，提供实时存储、索引、搜索和分析数据功能，这些数据收集自其他数据源(包括MongoDB)，可以直接存储在Elasticsearch集群中。

一、共同点：

面向文档存储，无Schema，分布式数据存储，高可用性，分片和复制等。虽然使用ElasticSearch作为主数据存储是可行的，但一般做为主数据库的辅助数据库。

二、不同点：

1、Elasticsearch是java编写，通过RESTFul接口 *** 作数据。MongoDB是C++编写，通过driver *** 作数据。

2、MongoDB的分片有hash和range两种方式，Elasticsearch只有hash一种。

3、Elasticsearch是天生分布式，主副分片自动分配和复制，开箱即用。MongoDB的分布式是由“前置查询路由+配置服务+shard集合”，需要手动配置集群服务。

4、内部存储ES是倒排索引+docvalues+fielddata。

5、Elasticsearch全文检索有强大的分析器且可以灵活组合，查询时智能匹配。MongoDB的全文检索字段个数有限制。

6、Elasticsearch所有字段自动索引，MongoDB的字段需要手动索引。Elasticsearch 使用 Apache Lucene 实现索引，而 MongoDB 索引是基于传统的B+ 树结构。Elasticsearch利用Lucene实现实时索引和搜索功能，默认支持在文档的每个字段上创建索引。而 MongoDB,我们必须定义索引用于提升查询性能，但会影响写 *** 作。

7、Elasticsearch非实时有数据丢失窗口。mongodb实时理论上无数据丢失风险。

8、文档 - Elasticsearch 存储 JSON 文档, MongoDB 采用BSON格式存储 (Binary JSON)。

9、REST 接口 - Elasticsearch 提供 RESTful接口，MongoDB 不提供 RESTful接口。

10、MapReduce - MongoDB 支持 MapReduce 数据 *** 作。 Elasticsearch 不支持 MapReduce。

三、使用场景：

MongoDB是通用功能的非RESTful风格的 NoSQL 数据库 文档以 BSON 格式存储，主要用于存储数据。

Elasticsearch 是分布式全文检索引擎，可以提供实时Restful风格API处理海量面向文档的数据。文档使用JSON格式，主要用于基于文本的数据搜索。

在实际应用中两者通常同时使用，Elasticsearch一般不作为主存储数据库，而是和SQL & NoSQL数据库一起使用，作为辅助数据库。

与MongoDb不同, Elasticsearch 默认没有提供安全特性，如认证和授权。Elasticsearch和 Logstash & Kibana 一起称为ELK stack，用于快速查询数据并可视化展现分析数据。

Elasticsearch 非常适合需要基于文本进行快速索引然后进行检索，其查询速度非常快，大多数情况速度最多几十毫秒。

因此，Elasticsearch 通常作为主数据库存储的辅助存储库。一般数据库系统更聚焦于约束、准确性和健壮性。当主记录在事务中更新时，其会同时被推送至Elasticsearch中。

一般典型使用PostgreSQL 和 ZooKeeper 负责数据的存储, 同时提供给Elasticsearch实现实时检索。

没有万能的产品，没有一个数据库可以满足所有需求。所以我们需要了解不同数据库的优势和劣势，并选择合适的产品用于特定的需求。

游戏服务器开发中，玩家的账号，背包，装备，物品，排名等数据都需要落地存储在数据库中。行业中主流的数据库当属mysql，优点是免费开源，从端游时代过渡过来的程序员，求稳保守的话大多数会选用mysql数据库做存储。但是游戏中要存储的数据表会经常改动，导致数据库的表会频繁更新改动表结构，如果游戏数据量达到千万级别，对所有的表刷新改动会是一项很恐怖的事情，期间如果再出错，运维跟开发人员估计全都GG。

为了应对方便扩展，提升读写速度，NoSQL数据库（非关系型数据库）诞生。在NoSQL中应用比较广泛的当属mongodb和redis，由于对开发者友好，方便快速开发迭代高可用复制集满足数据高可靠、服务高可用的需求，运维简单，故障自动切换可扩展分片集群海量数据存储被游戏服务器广泛应用。现在的项目《鹿鼎记》用redis做高速缓存角色列表信息数据。

怎么连接mongo数据库

1在这里使用的是MongoVUE进行连接，安装完成mongo客户端后，点击mongo的图标，启动运行程序

2打开面板后在界面的左上角有一个可点击的菜单connect连接按钮，这里相信不用我说读者就知道。

3点击后，显示出配置的连接数据库会话名。

4读者需要选择一个数据库的连接，然后点击下方的Connect连接

5如果读者没有配置连接需要点击下图红色方框选中的“”号，点击进行创建一个连接。

6下面就是配置数据库的连接信息，IP、端口、口令等

7连接进入后可以看到对应的数据库中所有的表，将鼠标移至需要的表格，然后鼠标右键，选择view（视图）

8打开后选择第二个视图--TableView，表格视图，就可以看到数据库表中的数据和字段名称。

高可用是MongoDB最核心的功能之一，相信很多同学也是因为这一特性才想深入了解它的。

那么本节就来说下MongoDB通过哪些方式来实现它的高可用，然后给予这些特性我们可以实现什么程度的高可用。

相信一旦提到高可用，浮现在大家脑海里会有如下几个问题：

那么，带着这些问题，我们继续看下去，看完大家应该会对这些问题有所了解了。

MongoDB高可用的基础是复制集群，复制集群本质来说就是一份数据存多份，保证一台机器挂掉了数据不会丢失。

一个副本集至少有3个节点组成：

从上面的节点类型可以看出，一个三节点的复制集群可能是PSS或者PSA结构。

PSA结构优点是节约成本，但是缺点是Primary挂掉之后，一些依赖 majority（多数）特性的写功能出问题，因此一般不建议使用。

复制集群确保数据一致性的核心设计是：

从上面4点我们可以得出 MongoDB 高可用的如下结论：

MongoDB宕机重启之后可以通过checkpoint快速恢复上一个60s之前的数据。

MongoDB最后一个checkpoint到宕机期间的数据可以通过Journal日志回放恢复。

Journal日志因为是100ms刷盘一次，因此至多会丢失100ms的数据

（这个可以通过WriteConcern的参数控制不丢失，只是性能会受影响，适合可靠性要求非常严格的场景）

如果在写数据开启了多数写，那么就算Primary宕机了也是至多丢失100ms数据（可避免，同上）。

分布式系统必须要面对的一个问题就是数据的一致性和高可用，针对这个问题有一个非常著名的理论就是CAP理论。

CAP理论的核心结论是：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

关于CAP理论在网上有非常多的论述，这里也不赘述。

CAP理论提出了分布式系统必须面临的问题，但是我们也不可能因为这个问题就不用分布式系统。

因此，BASE（Basically Available基本可用、Soft state软状态、Eventually consistent最终一致性）理论被提出来了。

BASE理论是在一致性和可用性上的平衡，现在大部分分布式系统都是基于 BASE理论设计的，当然MongoDB也是遵循此理论的。

MongoDB为了保证可用性和分区容错性，采用的是副本集的方式，这种模式就必须要解决的一个问题就是怎样快速在系统启动和Primary发生异常时选取一个合适的主节点。

这里潜在着多个问题：

MongoDB的选举算法是基于Raft协议的改进，Raft协议将分布式集群里面的节点有3种状态：

leader：就是Primary节点，负责整个集群的写 *** 作。

candidate：候选者，在Primary节点挂掉之后，参与竞选的节点。只有选举期间才会存在，是个临时状态。

follower：就是Secondary节点，被动的从Primary节点拉取更新数据。

节点的状态变化是：正常情况下只有一个leader和多个flower，当leader挂掉了，那么flower里面就会有部分节点成为candidate参与竞选。

当某个candidate竞选成功之后就成为新的leader，而其他candidate回到flower状态。

具体状态机如下：

Raft协议中有两个核心RPC协议分别应用在选举阶段和正常阶段：

请求投票：选举阶段，candidate向其他节点发起请求，请求对方给自己投票。

追加条目：正常阶段，leader节点向follower节点发起请求，告诉对方有数据更新，同时作为心跳机制来向所有follower宣示自己的地位。

如果follower在一定时间内没有收到该请求就会启动新一轮的选举投票。

Raft协议规定了在选举阶段的投票规则：

一个节点，在一个选举周期（Term）内只能给一个candidate节点投赞成票，且先到先得。

只有在candidate节点的oplog领先或和自己相同时才投赞成票。

一轮完整的选举过程包含如下内容：

以上就是目前掌握的MongoDB的选举机制，其中有个问题暂时还未得到解答，就是最后一个，怎样确保选出的Primary是最合适的那一个

因为，从前面的协议来看，存在一个逻辑bug：由于follower转换成candidate是随机并行的，再加上先到先得的投票机制会导致选出一个次优的节点成为Primary。

针对Raft协议的这个问题，下来查询了一些资料，结论是：

Raft协议确实不保证选举出来的Primary节点是最优的。

MongoDB通过在选举成功，到新Primary即位之前，新增了一个 catchup（追赶） *** 作来解决。

即在节点获取投票胜利之后，会先检查其它节点是否有比自己更新的oplog，如果没有就直接即位，如果有就先把数据同步过来再即位。

MongoDB的主从同步机制是确保数据一致性和可靠性的重要机制。其同步的基础是oplog，类似MySQL的binlog，但是也有一些差异，oplog虽然叫log但并不是一个文件，而是一个集合（Collection）。

同时由于 oplog 的并行写入，存在尾部乱序和空洞现象，具体来说就是oplog里面的数据顺序可能是和实际数据顺序不一致，并且存在时间的不连续问题。

为了解决这个问题，MongoDB采用的是混合逻辑时钟（HLC）来解决的，HLC不止解决乱序和空洞问题，同时也是用来解决分布式系统上事务一致性的方案。

主从同步的本质实际上就是，Primary节点接收客户端请求，将更新 *** 作写到oplog，然后Secondary从同步源拉取oplog并本地回放，实现数据的同步。

同步源是指节点拉取oplog的源节点，这个节点不一定是Primary，链式复制模式下就可能是任何节点。

节点的同步源选取是一个非常复杂的过程，大致上来说是：

在同步源选取时有些特殊情况：

用户可以为节点指定同步源。

如果关闭链式复制，所有Secondary节点的同步源都是Primary节点。

如果从同步源拉取出错了，会被短期加入黑名单。

整个拉取和回放的逻辑非常复杂，这里根据自己的理解简化说明，如果想了解更多知识可以参考《MongoDB复制技术内幕》

节点有一个专门拉取oplog的线程，通过Exhausted cursor从同步源拉取 oplog。拉取下来之后，并不会执行回放执行，而是会将其丢到一个本地

的阻塞队列中。

然后有多个具体的执行线程，从阻塞队列中取出oplog并执行。

在取出过程中，同一个Collection的oplog一定会被同一个线程取出执行，线程会尽可能的合并连续的插入命令。

整个回放的执行过程，大致为先加锁，然后写本店oplog，然后将oplog刷盘（WAL机制），最后更新自己的最新opTime。

MongoDB全方位知识图谱

>

以上就是关于MongoDB复制集/副本集(Replica Set)搭建全部的内容，包括:MongoDB复制集/副本集(Replica Set)搭建、window7拒绝连接MongoDB怎么办、怎么在中国地理空间数据云找梅州市行政边界等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！