先说明一下mongod和mongos的含义：mongod是MongoDB系统的主要后台进程，它处理数据请求、管理数据访问和执行后台管理操作；该命令的命令行选项主要用于测试，在场景操作中，使用配置文件选项来控制数据库的行为。mongos就是"MongoDB Shard"的简写，它是一个针对MongoDB分片配置的路由服务，该服务处理来自应用层的查询请求，确定数据在分片集群中的位置，以完成这些操作；从应用的角度来看，一个mongos实例表现得跟任何其他MongoDB实例完全相同。
（一）复制集（Replica Set）
MongoDB3.4版本在复制集中新增了以下特性：
1、Ddfault Journaling Behavior of majority Write Concern
在MongoDB3.4版本配置复制集时，增加writeConcernMajorityJournalDefault选项，默认为true，即当指定WriteConcern为majority时，数据写到大多数节点并且journal成功刷盘后，才向客户端确认成功；如果为false，则数据写到大多数节点的内存时就向客户端确认。
writeConcernMajorityJournalDefault的默认值跟protocolVersion相关，当protocolVersion为1时，它的默认值为true；当protocolVersion为0时，它的默认值为false。而protocolVersion从3.2版本开始就默认为1了，注意了protocolVersion为0的复制集成员不能加入protocolVersion为1的副本集。
2、Adjustable Catchup Period for Newly Elected Primary
- 在MongoDB3.4版本中配置复制集时增加了catchUpTimeoutMillis参数，默认值为2s（在3.6版本中为-1，不限制时间），它用来指出新选定的Primary从其他拥有更新数据的节点追数据的时间；
- 增加catchUpTimeoutMillis的时间能最大限度地减少需要rollback的数据，但有可能增加整个failover的时间；
- catchUpTimeoutMillis只能在protocolVersion为1时使用；
- 从3.6版本的副本集降级到3.4版本，此时需要将catchUpTimeoutMillis的值从-1更改为正数，如果没有及时将此值更为正数，那么会导致运行3.4版本的节点既不能重新启动，也不能加入副本集。
3、Linearizable Read Concern
- readConcern的级别level为linearizable时，一定能读到WriteConcern为majority，并且确认时间在读请求开始之前的数据；
- linearizable级别仅在查询结果只有单个文档的情况下有效；
- readConcern的级别值中linearizable级别要比majority级别、local级别慢，使用时要与maxTimeMS结合使用；
- 结合"majority" WriteConcern、"linearizable" ReadConcern使多个线程能够在单个文档上执行读取和写入。
4、Improved Initial Sync
在3.4版本中初始同步过程有所改进，体现以下几个方面：
- 在复制数据的同时建立所有的索引；
- inital sync在数据复制期间拉取新添加的oplog记录；
- 改进了初始同步重试逻辑；
- 为避免潜在的数据损坏，在初始同步过程中如果发现在同步源上重命名了一个集合，则初始同步将失败并重新启动初始同步；
- rs.status命令新增了一些可参考监控项，例如：
- replSetGetStatus.optimes.lastCommittedOpTime:已写入大多数副本集成员的最新操作时间；
- replSetGetStatus.optimes.appliedOpTime:已应用于副本集的该成员的最新操作时间；
- replSetGetStatus.optimes.durableOpTime:已写入该副本集的该成员的journal日志的时间。
5、Decimal Type
新增了对decimal128 format的支持，最多支持34位小数位。decimal数据存储的是实际的数据，无精度问题。
6、Collation and Case-Insensitive Indexes
从3.4版本开始支持collation，有了它后就可以支持对字符串的内容进行解读，可以按使用的local进行对比，也支持对比时忽略大小写。
7、Security Enhancement
MongoDB3.4版本支持不停服务开启认证，利用Transition to Auth可以实现，它可以允许mongod或mongos接受使用用户名+密码的登录，也接受未使用用户名+密码的登录，实现了0 down time认证切换。
8、Tools
3.4版本引入了mongoreplay工具，可以用于监控和记录mongod上执行的命令并“replay“到另一个mongod实例上，代替老版本中的mongosniff。
（二）分片集群（Sharded Cluster）
1、Membership Awareness
（1）从3.4版本开始，分片集群的所有组件如shares、config servers、mongos instances都能在分片集群中互相感知到对方的存在，包括分片集群的名称和config servers的位置。
（2）3.4版本的分片集群，mongod在实例启动时，必须制定shardsvr，可以在配置文件中配置sharding，clusterRole为shardsrv，也可以在启动时添加--shardsvr参数。
（3）从3.4版本起，若不指定端口，则shardsvr成员的端口默认为27018。
（4）3.4版本的mongos不能连接低版本的mongod。
2、Balancer on Config Server Primary
（1）从3.4版本起，Balancer进程从mongos移动到了config server的Primary节点上。
（2）3.2及之前的版本中，分片集群的负载均衡由mongos负责。
3、Faster Balancing
从3.4版本起，chunk migration可以进行并行操作，如果有n个shard，则可以有最多n/2个chunk同时迁移。
4、不再支持SCCC Config server模式
（1）在3.4版本中必须将config server部署为副本集架构。
（2）取消sh.getBalanceHost()命令，因为现在的Balancer进程在config server的Primary节点上。
5、Sharding Zones
分片集群里引入了Zone的概念，Zone能够将某些数据分配到指定的一个或多个Shard上。