作者回复: 后续的事务性方面还会涉及到复制集。已定目录更新完后也会考虑根据用户的反馈追加一些内容。
作者回复: 第一个问题你可以先看下这篇博客:
https://www.cnblogs.com/Joans/p/7723554.html
如果进一步了解的话,源码也可以尝试阅读下
第二个问题也在上面的文章里有提及
第三个问题:可以的,但是要通过对local库下面的一些表做个手脚。如果你用MongoDB的Ops Manager的话,它就提供这种方法来快速恢复一个从节点。
https://docs.opsmanager.mongodb.com/v1.4/tutorial/use-restore-to-seed-secondary/
其中关键的集合是system.replset 以及oplog.rs。 system.replset必须包含对应的配置(和其他节点一致)和时间戳。oplog.rs必须包含至少一条和主节点oplog一样的记录用来匹配同步点。
作者回复: 可以的 - 如果能用hostname最好
作者回复: 不能用local 库。那个是系统保留的。用任意其他库都可以。如 use test
作者回复: 1: 这个是你假设的问题还是真实的问题? 节点之间用的是一个heartbeat,主节点如果还能响应heartbeat说明可能没有假死。触发选举的话可以考虑直接关掉主节点。
2) reconfig 原则上不会触发全量同步,除非是加入新的节点
作者回复: 这个通常和你的hostname是否可以被解析相关。
试试下面这个:
rs.initiate({
_id: "rs0",
members: [{
_id: 0,
host: "localhost:28017"
}]
})
作者回复: 这里面最关键的是内存大小。
考虑为summary建一个covered index,然后保证你的索引能够装在内存里 (所有索引大小加起来要小于物理内存的一半那样)。
如果你用分片的话,比如说4个分片,那每个分片只需要处理2.5亿(在2.5亿里寻找,4个分片同时进行),理论上肯定更快了。但是最终还是要看你总的内存的数量。
作者回复: 抱歉这个问题不清楚不知道如何回答。
作者回复: 可以提供下完整的配置文件吗
作者回复: oplog 和 binlog类似。并且在压力超大的时候,也有可能在从节点造成一些延迟。当然mongodb可以用多线程同时来会放