前文我们搭建MongoDB三成员副本集，了解集群基本特性，今天我们围绕下图聊一聊背后的细节。
默认搭建的replica set均在主节点读写，辅助节点冗余部署，形成高可用和备份， 具备自动故障转移的能力。
集群心跳保活
集群每个节点以周期性向其他成员发出心跳命令 replSetHeartbeat来获取状态，
根据应答消息来更新节点的状态，根据最终状态确定是否重选主节点。
异步复制
辅助节点复制主节点的oplog，并将改变应用到数据集，从而保持与主节点数据同步。
这里有三个知识点：
oplog是一个特殊的封顶集合capped collection， 主节点上的operation log会记录在主节点的oplog中，辅助节点异步拷贝这些操作，这样所有的节点的都包含operatin log的一个副本：local.oplog.rs集合
每次异步复制触发的时机是在心跳保活阶段，所有的辅助节点都会在ping阶段从其他成员插入oplog文档。
oplog中的每个操作都是冥等的：无论是一次还是多次应用到目标数据集，oplog操作会产生相同的结果
当有新节点加入集群，该节点会启动另一种同步：initial sync, 将所有数据从副本集一个成员拷贝到另外一个成员， 复制完成，将过渡为辅助节点。
选举主节点
集群会因为各种事件触发选举主节点
在集群中添加新节点
初始化replica set集群
执行人工运维命令（rs.stepDown() rs.reconfig()）维护集群
辅助节点与主节点失联时间超过默认10s
自动故障转移说的是最后一种情况：
默认情况下，辅助节点A与主节点心跳失联超过10s，A节点标记主节点不可用；之后与其他辅助节点心跳保活，沟通各自信息（节点的票数、节点优先级、PingMs等因素）确立出新主节点。
在发生故障转移时，集群不能再执行写入操作； 如果你在客户端配置了在辅助节点的读取首选项 read preference，则集群可继续提供读取能力。
你的应用程序可用重试逻辑应对自动故障转移和后续的重选，从MongoDB3.6版本开始，MongoDB Driver可侦测主节点的失联，并执行一次重试操作。
连接副本集的客户端配置字符串，其中rs0是配置文件中设置的副本集名称 replSetName
mongodb://account:[email protected]:27017,mongodb1.example.com:27017,mongodb2.example.com:27017?replicaSet=rs0
OK， 以上便是MongoDB副本集心跳保活、异步复制、自动故障转移的背景知识。
留一个作业？
客户端连接MongoDB副本集的连接字符串，只是一个很普通的IP数组，
- 并未体现主副节点， 客户端是怎么区分主副节点，并向主节点发出写入指令？
- 另外MongoDB服务器发生故障转移后，客户端又是如何再次识别出主副节点？
这就涉及到客户端Moninoring, 所有遵守MongoDB官方规范的Driver都会实现 Service discovery和Monitoring :
我们在连接字符串指定的IP节点其实是种子节点，Driver会准实时监视集群，获取集群最新的状态信息。（heartbeatFrequencyMS 约定了客户端Driver检查集群状态的时间间隔）
这也与我在MongoDB 辅助节点看到的日志相互照应， 这也说明了 MongoBB故障转移并不只是服务端的事，客户端Driver 也为我们做了不少的事情。
+ https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#heartbeatfrequencyms
+ https://docs.mongodb.com/manual/reference/connection-string/#urioption.heartbeatFrequencyMS