其中的仲裁节点不存储数据，只是负责故障转移的群体投票，这样就少了数据复制的压力。是不是想得很周到啊，一看mongodb的开发兄弟熟知大数据架构体系，其实不只是主节点、副本节点、仲裁节点，还有Secondary-Only、Hidden、Delayed、Non-Voting。
Secondary-Only:不能成为primary节点，只能作为secondary副本节点，防止一些性能不高的节点成为主节点。
Hidden:这类节点是不能够被客户端制定IP引用，也不能被设置为主节点，但是可以投票，一般用于备份数据。
Delayed：可以指定一个时间延迟从primary节点同步数据。主要用于备份数据，如果实时同步，误删除数据马上同步到从节点，恢复又恢复不了。
Non-Voting：没有选举权的secondary节点，纯粹的备份数据节点。
到此整个mongodb副本集搞定了两个问题：
主节点挂了能否自动切换连接？目前需要手工切换。主节点的读写压力过大如何解决？
还有这两个问题后续解决：
从节点每个上面的数据都是对数据库全量拷贝，从节点压力会不会过大？数据压力大到机器支撑不了的时候能否做到自动扩展？
做了副本集发现又一些问题：
副本集故障转移，主节点是如何选举的？能否手动干涉下架某一台主节点。官方说副本集数量最好是奇数，为什么？mongodb副本集是如何同步的？如果同步不及时会出现什么情况？会不会出现不一致性？mongodb的故障转移会不会无故自动发生？什么条件会触发？频繁触发可能会带来
系统负载加重