作者回复: “MongoDB官方好像是建议1主1从1arbiter” 请提供相应的文章。
主节点挂了以后,两个从节点的投票算法会防止你说的现象发生。具体来说,如果两个从节点条件完全一样,那么第一个主张的节点就获胜。如果两个从节点同时主张自己,那么两个人同时放弃,并用一个随机值等待一小段时间(数秒),然后重试。所以总有一个节点会在另一个之前选为主节点。
作者回复: - 升级存储是最直接的方案,如PCIE + SSD
- 注意索引的数量:索引越多写入越慢
- 分片: 增加写的节点来提供并发
作者回复: 总数是看最初的配置,如你部署并配置了3个,虽然坏了一个,但是你的拓扑还是3节点, 按3节点的规则,剩下2个存活就可以正常工作。
作者回复: 太多从节点会增加主节点的压力,大概是每增加一个节点会有10%左右的性能影响。
主从读写分离还是比较常见的。所有读操作对数据时效(如报表型,或者历史数据)不高的都可以用从节点。
作者回复: 通过水平扩展可以提高整体的吞吐量,但是单个(比如说,查询 id=1234 这条记录)查询是不会得到改善的。因为这个查询就是会在一个节点上发生。
提高单个查询性能就是把数据放在内存里,加上合适的索引可以来提升性能(降低读取延迟)
作者回复: 主节点故障如果是进程crash或者server crash,那么它当然无法进行选举。
如果故障是因为节点之间网络不通,那失联的主节点会自动降级为从节点。
如果是短暂故障马上回复后,主节点(这个时候已经是从节点了)会重新加入选举,但是有个30秒的等待期。
作者回复: 1)是的会重新同步。节点之间判断是否需要同步是根据local库里的元数据决定的。里面记录了节点同步的状态信息,并不是看你实际存储的数据。
2)建议用SSL/TLS 加密链路就可以有效防止数据被窃取。
https://docs.mongodb.com/manual/tutorial/configure-ssl/index.html
作者回复: 主从复制会有延迟。常见因素:
1) 网络抖动 (没办法)
2)网络拥挤 (评估数据增量需求,给予足够的带宽)
3)节点之间延迟太长
4)主节点压力过大 (注意监控,压力过大要扩容)
5)从节点配置不均衡,低于主节点配置(尽量均衡)
作者回复: 你可以描述的详细点吗?如何不均匀?
作者回复: 通过增加节点,并且每个节点同时提供服务来提高并发访问能力。
单个查询的性能不受影响(不会变快)。
作者回复: 主从复制是由从节点的线程发起的。通过监听主节点的oplog表的变化,并把oplog的entries pull到从节点进行回放。
oplog变化通知的方式类似于你在linux 下执行一个tail -f 命令,一旦你tail的文件(oplog)有变化,马上就会打印出来。或者在java里是类似于observable pattern。
作者回复: 1)投票节点的最早设计初衷:需要奇数节点满足一致性协议,但同时又想节省资源。为何不建议用?降低的可用性(丢一个数据节点后风险很高),无法使用更高的writeConcern(后续章节会讲)来保证在主从切换的时候保证不丢失数据
2) 这种现象出现的可能性不大,你可以尝试下画下网络拓扑,具体到物理层链路。如果真的出现了,应该是可以继续工作的。
作者回复: 可以 - 剩下两个满足大多数(2)就可以正常完成选举并工作。
作者回复: 如果是因为同步滞后,超过oplog window大小,或者是数据库损坏,或者是刚加入主库,都需要执行initial syn的操作,这个就会清空本地库再同步。
作者回复: 选举节点必须是奇数,过半数(4)才可以工作和选举