配置副本集成员是通过哪个节点

‘壹’ 搭建MongoDB副本集&分片

顾名思义，副本集是一个集合，即MongoDB实例的集合，集合中的每个成员拥有相同的数据集合；一个副本集包含多个数据节点和一个可选的仲裁节点，在数据节点中，只有一个可以作为主节点（Primary Node），其他节点只能是第二节点（Secondary Nodes）。
主节点接收所有的写操作，一个副本集只能有一个能够确认写入的主节点（Primary Node），如下图：

第二节点复制主节点的操作日志并且将所有的操作应用到自己的数据集合中，复制过程是异步的，如果主节点不可用，一个可以被选举的第二节点将会被选举为主节点，所以在副本集中，即使一个或者多个成员没有正常运行，但整个副本集仍然可以正常工作；主副节点关系如下图：

在某些情况下（比如受硬件条件所限，只有一个主节点和一个副节点，无法添加更多的副节点），你可以选择将mongod实例添加进副本集，并作为仲裁者（仲裁者只负责选举新的主节点，不持有数据），在副本集中，如果主节点与其他节点无法通信的时间超过配置的时间值( electionTimeoutMillis )，那么副本集将视主节点出现故障，此时将会重新选举一个正常副节点来作为新的主节点，从而让整个副本集系统正常工作，如下图：

副本集的搭建的步骤为：同时启动多个mongod实例（可以在一台服务器上，也可以在不同的服务器上），然后在每个实例的配置文件中配置相应的配置项，最后启动实例后，登录并且在做一次配置即可。

注意: 文中都是通过配置文件的方式来启动mongod实例的，你也可以通过启动参数来启动实例，同时本文中的mongod实例是通过 supervisor 来管理的，关于如何通过supervisor管理进程，可以自行查阅相关资料或者参考 这里

对于每一个配置项，如果不明白每个配置项的释义，请参考: mongo配置文件 。另外，如果实例在同一台机器上，则针对每个实例，需要区分 path , pidFilePath , port , dbPath 这几个的配置值，并且每个配置文件中的 replSetName 必须相同。

在supervisorctl中执行update，此时三个实例便启动成功。

分片是将MongoDB中的数据集分割成多个数据片，每片数据存放在不同的MongoDB实例中，可以理解为将一个MongoDB数据集拆分成多个小型数据集，而小数据集分布在相同或者不同的物理机器上，分割只是从物理层面进行分割，逻辑上仍然属于同一个数据集合。

分片包含三部分, 如下图所示:

注意: 不同的分片集群必须使用不同的配置服务器(Config Servers)，不能使用同一个配置服务器(Config Servers)

分片实例的搭建与副本集类似，都是配置不同的配置文件，然后启动相应的实例:

这里只给出了关键配置项，其他配置项根据自己的实际情况配置，图中的 replSetName 表示当前实例属于哪个副本集，该副本集中的每个节点的该配置项必须一致， clusterRole 表示当前节点在分片中的的角色，可选值有: shardsvr 和 configsvr ， shardsvr 表示该节点是作为Shards节点提供服务，而 configsvr 表示该节点作为Config Server节点提供服务。

至此，分片搭建完成。

‘贰’ MongoDB分片集群搭建

分片（sharding）是一种跨多台机器分布数据的方法，MongoDB使用分片来支持具有非常大的数据集和高吞吐量操作的部署。换句话说：分片就是将数据拆分，将其分散存在不同的机器上的过程，将数据分散到不同的机器上，不需要功能强大的大型计算机就可以存储更多的数据，处理更多的负载。

MongoDB分片集群包含以下组件：

下图描述了分片集群中组件的交互：

本文搭建的副本集集群是两个分片节点副本集（3+3）+一个配置节点副本集（3）+两个路由节点（2），共11个服务节点，具体如下图所示：

本次搭建一主一副本一仲裁，相关的配置文件、数据、日志都放在sharded_cluster相应的子目录下面，具体步骤如下：

myshardrs01

设置sharding.clusterRole需要mongod实例运行复制。 要将实例部署为副本集成员，请使用
replSetName设置并指定副本集的名称。

使用客户端命令连接主节点，这里最好连接主节点

执行初始化副本集命令：

查看副本集情况：

同样搭建一主一副本一仲裁，相关的配置文件、数据、日志都放在sharded_cluster相应的子目录下面，
具体步骤如下：

myshardrs02

myshardrs01_27318

设置sharding.clusterRole需要mongod实例运行复制。 要将实例部署为副本集成员，请使用
replSetName设置并指定副本集的名称

myshardrs01_27418

myshardrs01_27518

启动第二套副本集：一主一副本一仲裁

依次启动三个mongod服务：

查看服务是否启动：

新建或修改配置文件：
myconfigrs_27019：

新建或修改配置文件：
myconfigrs_27119

新建或修改配置文件：
myconfigrs_27219

依次启动配置的mongod副本集：一主两副本

查看服务是否启动：

‘叁’ mongodb--选举失败

mongodb搭建了一个集群 测试的只有两个节点
为了测试副本集群的自动切换

关闭了主节点 但是发现子节点权限为只读 没有成为主节点

https://www.modb.pro/db/53381 参考了这篇文章 得知

例如：有N个副本集成员节点，必须有N/2+1个成员投票支持某个节点，此节点才能成为主节点。注意：副本集中若有成员节点处于不可用状态，并不会影响副本集中的“大多数”，“大多数”是以副本集的配置来计算的。

2/2+1=2 也就是必须有两个节点投票支持 才能成为主节点！

‘肆’ linux安装MongoDB双机热备份（主从复制）

主从复制作用：数据备份、读写分离
双机热备份：部署两个节点的MongoDB服务，配置一主一从，主节点添加数据，将自动备份到从节点上面，保证主机宕机后数据不丢失，同时可以继续提供数据读取服务(主服务挂掉，从服务将无法在进行写入数据，只能提供数据读取服务)
一主多从：部署多个节点的MongoDB服务，配置一主多从，数据也会自动备份到所有从节点上面，保证主机宕机后数据不丢失，同时可以根据从节点的优先级进行选取新的主节点，继续提供读写服务（主从关系跟服务设置的优先级有直接关系 优先级参数：priority 数字越大优先级越高）

使用上面的方式，在不同服务器上安装并启动MongoDB服务

将启动时使用的配置文件mongodb.conf中添加下面的副文本集名称配置，将权限控制参数改为false（auth=false），然后将服务进行重新启动即可（testrs是自定义的副本集名称）
#使用此设置来配置复制副本集。指定一个副本集名称作为参数，所有主机都必须有相同的名称作为同一个副本集
replSet=testrs

然后启动每个服务的客户端查看当前节点为主节点还是从节点；
1). 如果服务部署在不同服务器上，直接启动/bin目录下的mongo即可 命令：./ mongo
2). 如果服务部署在同一台服务器上，使用不同端口及配置文件进行启动的，启动客户端使用该命令 命令：./mongo 127.0.0.1:27018/

经过上面的一系列操作后，主从配置就完成了，接下来可以进行数据同步测试

第一步：在主库上面切换到admin，然后进行添加数据（命令：db.testdb1.insert([{"name":"zs"}])）

在从库上查询该数据（命令：db.testdb1.find({name:"zs"})），会出现下面如图的错误，因为从库没有查询数据权限，所以需要设置查询权限

设置从库查询权限，使用命令：rs.secondaryOk()
然后在使用查询命令进行查询（命令：db.testdb1.find({name:"zs"})）就会看到如下图的查询结果：

如上图所示，数据已经同步到从库上面了，这样双机热备份就已经实现了，上面的情况不包含权限控制

上面的情况已经完成了MongoDB的主从复制功能，但是我们把权限没有开放，启动时使用的配置中auth配置的值为false，说明没有添加权限，接下来就开放一下权限配置；
首先需要主从之间通信的一个keyFile文件，根据官网提供的说明，这个keyfile是可以任意内容的，只要保证所有集群中的机器都拥有同样的文件即可。

我这里将keyFile文件放到了MongoDB的bin目录下了，使用openssl rand -base64 1024 > /usr/local/mongodb-master/bin/mongodb.key 命令生成；

然后将mongodb.key文件复制到每台从服务上面，在每台服务的启动文件上添加 keyFile=/usr/local/mongodb-master/keyfile/mongodb.key 配置项 ，然后将auth属性值改为true，这样就完成了权限配置

重启主从两个节点，这样主机添加的数据，就会同步到从机上面了！！！

添加或删除从节点参考文章：
https://blog.csdn.net/weixin_44839444/article/details/105666163

‘伍’ MongoDB副本集同步原理解析

在MongoDB的副本集中，节点之间是通过oplog来同步数据。Primary节点每执行一次数据写入，都会记录一条oplog，Secondary节点会持续不断的自Primary拉取oplog并在本地回放，从而确保各节点达到数据最终一致性。

Primary节点并发写入数据，时间点分别为t1、t2和t3，按时间先后排序为 t1 -> t2 -> t3；如果t1和t3先落库，t2后落库，那么在oplog集合中如何能保证有序呢？

MongoDB底层通用的存储引擎为WiredTiger、In-Memory，以WiredTiger为例，MongoDB管理层调用WiredTiger引擎接口向oplog集合中插入文档（即记录）；

WiredTiger会以 oplog 的 ts 字段作为 key、文档内容作为 value，写入一条 KV 记录，wiredtiger 会保证存储（btree 或 lsm 的方式都能保证）的文档按 key 来排序，这样就解决 “Primary节点oplog如何保证有序” 的问题；

并发写入多条oplog ts1、ts2、ts3和ts4，其中 ts1<ts2<ts3<ts4，如果ts1、ts2和ts4先写入primary成功，ts3存在延迟，还未写入，此时secondary节点自pirmary拉取oplog在本地回放，如何保证有序呢？

MongoDB（wiredtiger 引擎）的解决方案是在读取oplog时进行限制，保证Secondary 节点看到一定是顺序的，具体实现机制如下：

如此既可以确保 “secondary节点在本地回放oplog时有序”

Secondary节点回放oplog在保证有序的前提下，如何保证高效呢？如下：

如果OpQueue队列中的oplog有对同一个collection的操作，后续并发进行数据回放时，如何保证同一个collections中两条oplog的执行顺序呢？

参考文档：
MongoDB 如何保证 oplog 顺序？
MongoDB复制集同步原理解析

‘陆’ MongoDB是什么，怎么用看完你就知道了

MongoDB是一款为web应用程序和互联网基础设施设计的数据库管理系统。没错MongoDB就是数据库，是Nosql类型的数据库。

（1）MongoDB提出的是文档、集合的概念，使用BSON（类JSON）作为其数据模型结构，其结构是面向对象的而不是二维表，存储一个用户在MongoDB中是这样子的。

使用这样的数据模型，使得MongoDB能在生产环境中提供高读写的能力，吞吐量较于mysql等SQL数据库大大增强。

（2）易伸缩，自动故障转移。易伸缩指的是提供了分片能力，能对数据集进行分片，数据的存储压力分摊给多台服务器。自动故障转移是副本集的概念，MongoDB能检测主节点是否存活，当失活时能自动提升从节点为主节点，达到故障转移。

（3）数据模型因为是面向对象的，所以可以表示丰富的、有层级的数据结构，比如博客系统中能把“评论”直接怼到“文章“的文档中，而不必像myqsl一样创建三张表来描述这样的关系。

（1）文档数据类型

SQL类型的数据库是正规化的，可以通过主键或者外键的约束保证数据的完整性与唯一性，所以SQL类型的数据库常用于对数据完整性较高的系统。MongoDB在这一方面是不如SQL类型的数据库，且MongoDB没有固定的Schema，正因为MongoDB少了一些这样的约束条件，可以让数据的存储数据结构更灵活，存储速度更加快。

（2）即时查询能力

MongoDB保留了关系型数据库即时查询的能力，保留了索引（底层是基于B tree）的能力。这一点汲取了关系型数据库的优点，相比于同类型的NoSQL redis 并没有上述的能力。

（3）复制能力

MongoDB自身提供了副本集能将数据分布在多台机器上实现冗余，目的是可以提供自动故障转移、扩展读能力。

（4）速度与持久性

MongoDB的驱动实现一个写入语义 fire and forget ，即通过驱动调用写入时，可以立即得到返回得到成功的结果（即使是报错），这样让写入的速度更加快，当然会有一定的不安全性，完全依赖网络。

MongoDB提供了Journaling日志的概念，实际上像mysql的bin-log日志，当需要插入的时候会先往日志里面写入记录，再完成实际的数据操作，这样如果出现停电，进程突然中断的情况，可以保障数据不会错误，可以通过修复功能读取Journaling日志进行修复。

（5）数据扩展

MongoDB使用分片技术对数据进行扩展，MongoDB能自动分片、自动转移分片里面的数据块，让每一个服务器里面存储的数据都是一样大小。

MongoDB核心服务器主要是通过mongod程序启动的，而且在启动时不需对MongoDB使用的内存进行配置，因为其设计哲学是内存管理最好是交给操作系统，缺少内存配置是MongoDB的设计亮点，另外，还可通过mongos路由服务器使用分片功能。

MongoDB的主要客户端是可以交互的js shell 通过mongo启动，使用js shell能使用js直接与MongoDB进行交流，像使用sql语句查询mysql数据一样使用js语法查询MongoDB的数据，另外还提供了各种语言的驱动包，方便各种语言的接入。

mongomp和mongorestore,备份和恢复数据库的标准工具。输出BSON格式，迁移数据库。

mongoexport和mongoimport，用来导入导出JSON、CSV和TSV数据，数据需要支持多格式时有用。mongoimport还能用与大数据集的初始导入，但是在导入前顺便还要注意一下，为了能充分利用好mongoDB通常需要对数据模型做一些调整。

mongosniff,网络嗅探工具，用来观察发送到数据库的操作。基本就是把网络上传输的BSON转换为易于人们阅读的shell语句。

因此，可以总结得到，MongoDB结合键值存储和关系数据库的最好特性。因为简单，所以数据极快，而且相对容易伸缩还提供复杂查询机制的数据库。MongoDB需要跑在64位的服务器上面，且最好单独部署，因为是数据库，所以也需要对其进行热备、冷备处理。

因为本篇文章不是API手册，所有这里对shell的使用也是基础的介绍什么功能可以用什么语句，主要是为了展示使用MongoDB shell的方便性，如果需要知道具体的MongoDB shell语法可以查阅官方文档。

创建数据库并不是必须的操作，数据库与集合只有在第一次插入文档时才会被创建，与对数据的动态处理方式是一致的。简化并加速开发过程，而且有利于动态分配命名空间。如果担心数据库或集合被意外创建，可以开启严格模式。

以上的命令只是简单实例，假设如果你之前没有学习过任何数据库语法，同时开始学sql查询语法和MongoDB 查询语法，你会发现哪一个更简单呢？如果你使用的是java驱动去操作MongoDB，你会发现任何的查询都像Hibernate提供出来的查询方式一样，只要构建好一个查询条件对象，便能轻松查询（接下来会给出示例），博主之前熟悉ES6，所以入手MongoDB js shell完成没问题，也正因为这样简洁，完善的查询机制，深深的爱上了MongoDB。

使用java驱动链接MongoDB是一件非常简单的事情，简单的引用，简单的做增删改查。在使用完java驱动后我才发现spring 对MongoDB 的封装还不如官方自身提供出来的东西好用，下面简单的展示一下使用。

这里只举例了简单的链接与简单的MongoDB操作，可见其操作的容易性。使用驱动时是基于TCP套接字与MongoDB进行通信的，如果查询结果较多，恰好无法全部放进第一服务器中，将会向服务器发送一个getmore指令获取下一批查询结果。

插入数据到服务器时间，不会等待服务器的响应，驱动会假设写入是成功的，实际是使用客户端生成对象id，但是该行为可以通过配置配置，可以通过安全模式开启，安全模式可以校验服务器端插入的错误。

要清楚了解MongoDB的基本数据单元。在关系型数据库中有带列和行的数据表。而MongoDB数据的基本单元是BSON文档，在键值中有指向不定类型值的键，MongoDB拥有即时查询，但不支持联结操作，简单的键值存储只能根据单个键来获取值，不支持事务，但支持多种原子更新操作。

如读写比是怎样的，需要何种查询，数据是如何更新的，会不会存在什么并发问题，数据结构化的程度是要求高还是低。系统本身的需求决定mysql还是MongoDB。

在关于schema 的设计中要注意一些原则，比如：

数据库是集合的逻辑与物理分组，MongoDB没有提供创建数据库的语法，只有在插入集合时，数据库才开始建立。创建数据库后会在磁盘分配一组数据文件，所有集合、索引和数据库的其他元数据都保存在这些文件中，查阅数据库使用磁盘状态可通过。

集合是结构上或概念上相似得文档的容器，集合的名称可以包含数字、字母或 . 符号，但必须以字母或数字开头，完全。

限定集合名不能超过128个字符，实际上 . 符号在集合中很有用，能提供某种虚拟命名空间，这是一种组织上的原则，和其他集合是一视同仁的。在集合中可以使用。

其次是键值，在MongoDB里面所有的字符串都是UTF-8类型。数字类型包括double、int、long。日期类型都是UTC格式，所以在MongoDB里面看到的时间会比北京时间慢8小时。整个文档大小会限制在16m以内，因为这样可以防止创建难看的数据类型，且小文档可以提升性能，批量插入文档理想数字范围是10~200，大小不能超过16MB。

（1）索引能显着减少获取文档的所需工作量，具体的对比可以通过 .explain()方法进行对比

（2）解析查询时MongoDB通过最优计划选择一个索引进行查询，当没有最适合索引时，会先不同的使用各个索引进行查询，最终选出一个最优索引做查询

（3）如果有一个a-b的复合索引，那么仅针对a的索引是冗余的

（4）复合索引里的键的顺序是很重要的

（1）单键索引

（2）复合索引

（3）唯一性索引

（4）稀疏索引

如索引的字段会出现null的值，或是大量文档都不包含被索引的键。

如果数据集很大时，构建索引将会花费很长的时间，且会影响程序性能，可通过

当使用 mongorestore 时会重新构建索引。当曾经执行过大规模的删除时，可使用

对索引进行压缩，重建。

（1）查阅慢查询日志

（2）分析慢查询

注意新版本的MongoDB 的explain方法是需要参数的，不然只显示普通的信息。

本节同样主要简单呈现MongoDB副本集搭建的简易性，与副本集的强壮性，监控容易性

提供主从复制能力，热备能力，故障转移能力

实际上MongoDB对副本集的操作跟mysql主从操作是差不多的，先看一下mysql的主从数据流动过程

而MongoDB主要依赖的日志文件是oplog

写操作先被记录下来，添加到主节点的oplog里。与此同时，所有从结点复制oplog。首先，查看自己oplog里最后一条的时间戳；其次，查询主节点oplog里所有大于此时间戳的条目;最后，把那些条目添加到自己的oplog里并应用到自己的库里。从节点使用长轮询立即应用来自主结点oplog的新条目。

当遇到以下情况，从节点会停止复制

local数据库保存了所有副本集元素据和oplog日志

可以使用以下命令查看复制情况

每个副本集成员每秒钟ping一次其他所有成员，可以通过rs.status()看到节点上次的心跳检测时间戳和 健康 状况。

这个点没必要过多描述，但是有一个特殊场景，如果从节点和仲裁节点都被杀了，只剩下主节点，他会把自己降级成为从节点。

如果主节点的数据还没有写到从库，那么数据不能算提交，当该主节点变成从节点时，便会触发回滚，那些没写到从库的数据将会被删除，可以通过rollback子目录中的BSON文件恢复回滚的内容。

（1）使用单节点链接

只能链接到主节点，如果链接到从节点的话，会被拒绝写入操作，但是如果没有使用安全模式，因为mongo的fire and forget 特性，会把拒绝写入的异常给吃掉。

（2）使用副本集方式链接

能根据写入的情况自动进行故障转移，但是当副本集进行新的选举时，还是会出现故障，如果不使用安全模式，依旧会出现写不进去，但现实成功的情况。

分片是数据库切分的一个概念实现，这里也是简单总结为什么要使用分片以及分片的原理，操作。

当数据量过大，索引和工作数据集占用的内存就会越来越多，所以需要通过分片负载来解决这个问题

（1）分片组件

（2）分片的核心操作

分片一个集合：分片是根据一个属性的范围进行划分的，MongoDB使用所谓的分片键让每个文档在这些范围里找到自己的位置

块：是位于一个分片中的一段连续的分片键范围，可以理解为若干个块组成分片，分片组成MongoDB的全部数据

（3）拆分与迁移

块的拆分：初始化时只有一个块，达到最大块尺寸64MB或100000个文档就会触发块的拆分。把原来的范围一分为二，这样就有了两个块，每个块都有相同数量的文档。

迁移：当分片中的数据大小不一时会产生迁移的动作，比如分片A的数据比较多，会将分片A里面的一些块转移到分片B里面去。分片集群通过在分片中移动块来实现均衡，是由名为均衡器的软件进程管理的，任务是确保数据在各个分片中保持均匀分布，当集群中拥有块最多的分片与拥有块最少分片的块差大于8时，均衡器就会发起一次均衡处理。

启动两个副本集、三个配置服务器、一个mongos进程

配置分片

（1）分片查询类型

（2）索引

分片集合只允许在_id字段和分片键上添加唯一性索引，其他地方不行，因为这需要在分片间进行通信，实施起来很复杂。

当创建分片时，会根据分片键创建一个索引。

（1）分片键是不可修改的、分片键的选择非常重要

（2）低效的分片键

（3）理想的分片键

（1）部署拓扑

根据不同的数据中心划分

这里写图片描述

（2）最低要求

（3）配置的注意事项

需要估计集群大小，可使用以下命令对现有集合进行分片处理

（4）备份分片集群

备份分片时需要停止均衡器

（1）部署架构

使用64位机器、32位机器会制约mongodb的内存，使其最大值为1.5GB

（2）cpu

mongodb 只有当索引和工作集都可放入内存时，才会遇到CPU瓶颈，CPU在mongodb使用中的作用是用来检索数据，如果看到CPU使用饱和的情况，可以通过查询慢查询日志，排查是不是查询的问题导致的，如果是可以通过添加索引来解决问题

mongodb写入数据时会使用到CPU，但是mongodb写入时间一次只用到一个核，如果有频繁的写入行为，可以通过分片来解决这个问题

（3）内存

大内存是mongodb的保障，如果工作集大小超过内存，将会导致性能下降，因为这将会增加数据加载入内存的动作

（4）硬盘

mongodb默认每60s会与磁盘强制同步一次，称为后台刷新，会产生I/O操作。在重启时mongodb会将磁盘里面的数据加载至内存，高速磁盘将会减少同步的时间

（5）文件系统

使用ext4 和 xfs 文件系统

禁用最后访问时间

（6）文件描述符

linux 默认文件描述符是1024，需要大额度的提升这个额度

（7）时钟

mongodb各个节点服务器之间使用ntp服务器

（1）绑定IP

启动时使用 - -bind_ip 命令

（2）身份验证

启动时使用 - -auth 命令

（3）副本集身份认证

使用keyFile，注意keyFile文件的权限必须是600，不然会启动不起来

（1）拓扑结构

搭建副本集至少需要两个节点，其中仲裁结点不需要有自己的服务器

（2）Journaling日志

写数据时会先写入日志，而此时的数据也不是直接写入硬盘，而是写入内存

但是Journaling日志会消耗内存，所以可以在主库上面关闭，在从库上面启动

可以单独为Journaling日志使用一块固态硬盘

在插入时，可以通过驱动确保Journaling插入后再反馈，但是会非常影响性能。

logpath 选项指定日志存储地址

-vvvvv 选项（v越多，输出越详细）

db.runCommand({logrotare:1}) 开启滚动日志

（1）serverStatus

这里写图片描述

（2）top

（3）db.currentOp()

动态展示mongodb活动数据

占用当前mongodb监听端口往上1000号的端口

（1）mongomp

把数据库内容导出成BSON文件，而mongorestore能读取并还原这些文件

（2）mongorestore

把导出的BSON文件还原到数据库

（3）备份原始数据文件

可以这么做，但是，操作之前需要进行锁库处理 db.runCommand({fsync:1,lock:true})

db.$cmd.sys.unlock.findOne() 请求解锁操作，但是数据库不会立刻解锁，需要使用db.currentOp()验证。

（1）修复

mongd --repair 修复所有数据库

db.runCommand({repairDatabase:1}) 修复单个数据库

修复就是根据Jourling文件读取和重写所有数据文件并重建各个索引

（2）压紧

压紧，会重写数据文件，并重建集合的全部索引，需要停机或者在从库上面运行,如果需要在主库上面运行，需要添加force参数 保证加写锁。

（1）监控磁盘状态

（2）为提升性能检查索引和查询

总的来说，扫描尽可能少的文档。

保证没有冗余的索引，冗余的索引会占用磁盘空间、消耗更多的内存，在每次写入时还需做更多工作

（3）添加内存

dataSize 数据大小 和 indexSize 索引大小，如果两者的和大于内存，那么将会影响性能。

storageSize超过dataSize 数据大小 两倍以上，就会因磁盘碎片而影响性能，需要压缩。

‘柒’ 搭建MongoDB单节点副本集服务

mongo普通单节点不支持事务，需要使用副本集或者mongos才行，原因如下

参考官方文档

使用docker只需要三步即可启动一个副本集节点用于开发测试

‘捌’ 新手求教MongoDB副本集配置问题

网络MongoDB副本集群配置，有完整教程。
1：首先创建3台虚拟机作为配置环境 IP1：192.168.91.128 IP2：192.168.91.129 IP3：192.168.91。

‘玖’ 如何正确配置基于 oracle 数据库的 wps v6.12 集群应用系统

本文描述了远程消息传递和远程支持集群环境的搭建配置过程。这个集群环境由三个集群组成，具体的拓扑结构是：
应用程序集群，不但为应用程序提供工作负载管理以及URL和EJB 请求故障转移功能，而且还部署了BPC和HTM 容器，提供了对长业务流程和人工业务流程的应用程序的支持。
远程消息集群，运行WPS默认提供的四个总线（SCA应用，SCA系统，BPC和CEI）提供独立的高效的消息引擎。
远程支持集群，部署通用事件体系结构和业务规则管理等其他应用程序，提供异步的事件查询。
这三个集群配置在两台机器的不同的节点上，即三个集群的成员水平部署在两台机器上。在一个集群中的两个成员是该集群中完全相同的副本。消息传递引擎、业务支持和业务流程应用程序分别位于不同的集群上，所以可以根据实际业务负载和硬件环境，灵活调配所需的资源。这种模式，也称为黄金拓扑，是 WPS 中最复杂的拓扑结构，是大多数企业集成应用用户的首选，具有如下优点：

可靠性。将所有的应用、消息引擎和通用事件部署在三个集群上面，方便管理和使用。
可扩展性。因为系统中的消息引擎处于的关键地位，可能存在之后的访问需求增长等扩展需要，单独创建消息引擎集群可以很方便实行这一点。
对于系统运行时可能遇到的处理量非常大和可伸缩性等问题，通过将通用事件基础架构（CEI）和应用程序分离，可以确保这两个组件不会争用相同的资源（内存和CPU）。此拓扑还能帮助创建集中的事件服务器以处理来自多个源的事件。
所有的应用服务器由 Deployment Manager 统一管理，降低了系统管理的复杂度。
安装前的注意事项
在集群环境的安装过程中，需要同步两台主机的信息，确保它们之间能够良好的通信。主要同步的信息包括两台主机的系统时间、时区设置，并确保两台机器的时间差在5分钟之内，如果时间差超过5分钟，联合操作将失败。
更新两台主机的hosts 文件（默认目录为/etc/hosts ），确保每台机器均包含对方的host name 和对应的IP 地址，以便主机间的相互访问。
在使用向导安装和配置概要时，请按照从上到下的顺序输入配置参数，对于WPS V6.12 ，输入顺序的改变有可能导致未知错误。
集群环境的搭建步骤
Informix 数据库规划
WPS的集群环境需要后台数据库的支持。为了提高集群在实际运行中的效率，建议根据功能的不同，创建不同的数据库。数据库的详细信息如下表所示：

数据库名称 说明
WPRCSDB 公共数据库
EVENT 通用事件体系结构数据库
CEIDB 通用事件体系结构消息传递引擎数据库
SCASYSDB 服务组件系统消息传递引擎数据库
SCAAPPDB 服务组件应用程序消息传递引擎数据库
BPCDB 业务流程编排器数据库
BPCME 业务流程编排器消息传递引擎数据库
OBSVRDB 业务流程编排器事件收集器数据库

注意：本文选择英文语言的数据库安装。如果要安装中文语言的数据库，请参考本文的：在数据源定制属性中添加数据库语言。

安装WPS的步骤
首先使用图形化安装向导在两台主机上分别安装WPS v6.1.2 产品，。在安装产品和搭建集群过程中，步骤如下：
1.选择“Typical installation”安装类型。典型安装也称为完全安装，提供了环境的初始化定义，包括通过概要管理工具创建特定了类型的概要文件。
图2 选择安装类型

2.在选择概要类型界面提供了四种可选择的概要类型（图3）。我们选择“None”，即不创建任何类型的概要，以便在以后的步骤中手动创建概要。
使用Profile Management Tool（PMT） 创建Deployment Manager 概要

Deployment Manager（DM）是管理控制节点，它对集群环境下的所有节点提供了图形化的管理功能。一个集群环境中一般只需要一个管理概要。下面我们将向您讲述创建DM 概要的主要步骤：
1. 在<WPS_HOME>/bin/ProfileManagement/ 下执行命令pmt.sh ，弹出安装界面。在各种类型的环境选项中选择 WPS，进入下一步。
2. 在概要类型中提供了三种典型的概要类型，选择 Deployment manager profile，搭建DM 概要。
3. 在创建方式界面中，默认选项为创建典型的概要文件，在此需要选择 Advanced profile creation，以便我们在后续步骤中通过管理控制台手动进行集群配置，以满足特定环境的需求。
4. 填写要创建的Deployment manager profile的名称和安装目录。
5. 填写概要的Node Name和Cell name ，指定 Host Name。
6. 在管理安全选项中，如果选中 Enable administrative security 选项，请记住 WPS v 6.1.2
用户名称和密码。这里建议取消 Enable administrative security 选项，不设置安全管理。在后续步骤中可以根据需要手动启动安全管理选项，设定用户名密码。
7. 配置服务器的端口。
8. 进行数据库的配置。首先从 Choose a database proct 选择 Informix Dynamic Server 作为公共数据库类型，并选择 Use an existing database。另外，需要指定 Database name，本例中使用先前创建的数据库 WPRCSDB。不选择“Deplay execution of database scripts for new or existing database”选项，因为概要文件的安装过程中会自动创建数据库 WPRCSDB 中的表。注意：如果创建的数据库为中文字符集，则需要选择 “Deplay execution of database scripts for new or existing database“选项，在概要创建完成后，手动执行创建数据库表（请参考本节内容中的步骤 11）。

9. 在数据库配置的第2步，需要对 Common DB 参数进行配置。如果是远程数据库，则在填写 Database server host name时，要确保远程数据库的host name 已经添加到本地主机（参考本文的第三部分内容“安装前的注意事项”）；也可以直接在该项填写远程数据库的IP 地址。换句话说，在点击下一步之前，请确认数据库的参数信息，否则将在点击下一步后，会收到不能连接数据库的错误提示。
10. 完成以上步骤后，系统会显示概要的创建信息。如果发现参数需要调整可以后退向导重新进行输入。DM 创建成功后，可取消选择 Launch the First steps console和Create another profile，点击完成。至此，Deployment Manager 创建完成。如果创建DM 失败，请查看 <WPS_HOME>/logs/manageprofile 目录下的日志文件进行分析。

11. 另外，如果需要手工创建Common DB(WPRCSDB) 相关的表，可执行DM 概要创建生成的数据库脚本，默认目录为：
<WPS_HOME>/profiles/Dmgr01/dbscripts/CommonDB/Informix/WPRCSDB 。
请将这些脚本复制到 Informix 数据库所在机器，并设置如下环境变量：
INFORMIXSERVER=<IFX_INSTANCENAME>
INFORMIXDIR=<IFX_INSTALL_HOME>
之后执行如下命令：
dbaccess – createDatabase_CommonDB.sql
如果WPRCSDB已经创建，可以忽略。
dbaccess WPRCSDB createTable_AppScheler.sql
dbaccess WPRCSDB createTable_CommonDB.sql
dbaccess WPRCSDB createTable_customization.sql
dbaccess WPRCSDB createTable_lockmanager.sql
dbaccess WPRCSDB createTable_mediation.sql
dbaccess WPRCSDB createTable_Recovery.sql
dbaccess WPRCSDB createTable_RelationshipMetadataTable.sql
dbaccess WPRCSDB createTable_EsbLoggerMediation.sql
dbaccess WPRCSDB insertTable_CommonDB.sql
使用PMT 创建自定义概要
接下来，我们手动进行自定义概要的创建。这样，能够在创建概要过程中，根据客户特定的使用需求和环境特点，选择适合于自己的数据库，并进行端口、用户名、密码等信息的设置。
在创建自定义概要（Custom profile）之前启动 DeploymentManager（DM）概要，在目录<WPS_HOME>/profiles/Dmgr01/bin 下，运行startManager.sh 命令。节点概要的创建与 DM 概要的创建类似，在目录<WPS_HOME>/bin/ProfileManagment 下执行命令pmt.sh，随即获得安装界面，主要步骤如下。
1．选择 Create 即创建一个新的概要文件。
2．在环境选项中，选择 WPS，进入下一步。
3．在创建概要的类型中，选择 Custom Profile，创建一个自定义节点概要。
4．在安装类型选项中，选择 Advanced profile creation，以便在后续步骤中通过手动配置相关参数，定制特定的节点概要。

5．输入节点所对应的DM 概要的主机名称和端口，默认端口为8879。如果在创建DM时启动了管理安全性，则需要输入用户名和密码。Federate this node later 选项的选择取决于是否要在创建节点的同时将其联合到指定的DM 概要中。这里，我们不选择该选项，节点会自动与 DM 概要联合，需要注意的是，要确保 DM 概要此时为启动状态。
若选择创建节点之后手动联合到 DM 概要中，则需要在创建节点完成后使用<WPS_HOME>/Custom01/bin 目录下的addNode.sh 命令进行节点与 DM的手动联合，具体命令如下：
addNode.sh dmgr_hostname<–username username –password password>
6．输入DM的信息后，进入端口设置页面，可以自行修改端口号。

7．在数据库选项中选择 Informix Dynamic Server 作为数据库类型，并为Informix JDBC driver 指定正确的路径。该路径指向节点所在的本地机器上 ifxjdbc.jar和ifxjdbcx.jar的存储位置。
8．浏览汇总信息无误后，点击 Create 开始创建自定义概要。

9．创建成功后，重复以上步骤为另一台机器创建自定义概要。
命令行方式创建Deployment Manager 实例和托管节点实例
创建DM profile 和Custom profile时，除了使用pmt.sh 命令外，还可以选择命令行方式，即执行<WPS_HOME> /bin/manageprofiles.sh 命令创建概要。创建Deployment manager 概要的命令和脚本如下：
./manageprofiles.sh –create -dbServerPort 8002
–templatePath <WPS_HOME>/profileTemplates/dmgr.wbiserver
–profileName Dmgr01
-dbDelayConfig true –dbCommonForME false
–dbType INFORMIX –dbHostName aix235.cn.ibm.com
–dbInstance IFXTest –hostName aix235.cn.ibm.com
–enableAdminSecurity false –dbName wprcsdb
–dbPassword informix –ndtopology false
-cellName aix235Cell01 –nodeName aix235CellManager01
–dbJDBCClasspath /opt/jdbc/lib –dbUserId Informix
–dbCreateNew false –profilePath <WPS_HOME>/profiles/Dmgr01
创建自定义节点的命令和脚本如下：
./manageprofiles.sh –create –dmgrHost 9.186.111.234
–profileName Custom01 –templatePath <WPS_HOME>/profileTemplates/managed.wbiserver
–dbType INFORMIX –ndtopology false
–cellName aix234Node01Cell –hostName aix234.cn.ibm.com
–nodeName aix234Node01 –dbJDBCClasspath /home/jdbc/lib
–dmgrPort 8879 –profilePath <WPS_HOME>/profiles/Custom01

‘拾’ MongoDB复制集/副本集(Replica Set)搭建

mongo副本集/复制集是mongo高可用性特征之一，是有自动故障恢复功能的主要集群。由一个Primary节点和一个或多个Secondary节点组成。

复制是在多台服务器之间同步数据的过程，由一组Mongod实例（进程）组成，包含一个Primary节点和多个Secondary节点

Mongodb Driver（客户端）的所有数据都写入Primary，Secondary从Primary同步写入的数据

通过上述方式来保持复制集内所有成员存储相同的数据集，提供数据的高可用

Failover （故障转移，故障切换，故障恢复）

Rendancy（数据冗余）

避免单点，用于灾难时恢复，报表处理，提升数据可用性

读写分离，分担读压力

对用户透明的系统维护升级

主节点记录所有的变更到oplog日志

辅助节点(Secondary)复制主节点的oplog日志并且将这些日志在辅助节点进行重放(做)

各个节点之间会定期发送心跳信息，一旦主节点宕机，则触发选举一个新的主节点，剩余的辅助节点指向新的主

10s内各辅助节点无法感知主节点的存在，则开始触发选举

通常1分钟内完成主辅助节点切换，10-30s内感知主节点故障，10-30s内完成选举及切换

用户恢复数据，防止数据丢失，实现灾难恢复

人为误操作导致数据删除，程序Bug导致数据损坏等

首要复制节点，由选举产生，提供读写服务的节点，产生oplog日志

备用(辅助)复制节点，Secondary可以提供读服务，增加Secondary节点可以提供复制集的读服务能力

在故障时，备用节点可以根据设定的优先级别提升为首要节点。提升了复制集的可用性

Arbiter节点只参与投票，不能被选为Primary，并且不从Primary同步数据

Arbiter本身不存储数据，是非常轻量级的服务。

当复制集成员为偶数时，最好加入一个Arbiter节点，以提升复制集可用性

Mongodb版本3.0以上, 三台服务器均为64位

三台服务器    --------  Primary（Centos7)、 Secondary（Centos7)、 Secondary(Debian8)；架设IP分别为 192.168.1.1、1.2、 1.3

三台服务器关闭防火墙    -------- systemctl  stop firewalld.service

三台服务器修改mongo配置文件    --------  vi  /etc/mongod.conf 

        侦听地址除了 localhost 外再加上服务器IP； 设置复制集名字（RepliSetName）。

开启mongod服务： mongod

三台服务器mongo各自初始化： rs.initiate()

Primary上副本集配置：

rsconf(配置名称，可随意取)={_id:"副本集名",member:[{_id:0,host:"IP:port",priority:2},{_id:1,host:"IP:port",priority:1},{_id:2,host:"IP:port",priority:1}]}

在初始化：rs.initiate(变量名，如下面的config)

Secondary上配置：

rs.slaveOk()    #承认自己是Secondary

三台服务器上互相添加副本集成员：

rs.add("IP:port")， 如在Primary上 rs.add("192.168.1.2:27017"), rs.add("192.168.1.3:27017")

查看状态

rs.status()

3、rs(replication set) 常用命令：

初始化副本集  ----  rs.initiate()

mongo查看状态 ---- rs.status()

初始化副本集配置

rsconf = {_id: "rs0",

members: [{

_id: 0,

host: ":27017"}]}

rs.initiate( rsconf )

验证副本集配置  ----  rs.config()

增加副本集成员  ----  rs.add("Ip:port")

移除副本集成员  ----  rs.remove("IP:port")    #此步骤在Primary上操作

改变成员变量的优先级

cfg = rs.conf()

cfg.members[0].priority = 3

cfg.members[1].priority = 1

cfg.members[2].priority = 2

rs.reconfig(cfg)

配置延迟副本集

cfg = rs.conf()

cfg.members[0].priority = 0

cfg.members[0].hidden = true

cfg.members[0].slaveDelay = 3600

rs.reconfig(cfg)

#  07/03/2017