Caused by: com.mongodb.MongoException: can't find a master at com.mongodb.DBTCPConnector.checkMaster(DBTCPConnector.java:509) at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:266) at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:289) at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:274) at com.mongodb.DBCursor._check(DBCursor.java:368) at com.mongodb.DBCursor._hasNext(DBCursor.java:459) at com.mongodb.DBCursor.hasNext(DBCursor.java:484)
有趣的是,我可以使用本地应用程序中的副本集服务器地址连接到dev mongodb,但是当我尝试将应用程序(深入到dev中)连接到dev mongodb时,我看到上面的错误.
我想知道是否有人遇到同样的问题并解决了.
mongodb的这个令人困惑的方面在其 voting policy中与政治科学的原则发生冲突.这是它发生的方式.
>存在副本集;它必须有奇数个投票节点.
>主节点因服务器/网络出现故障或关闭而失败.其他节点也可能失败,但最重要的是……>偶数个节点仍然没有主节点.>剩余的偶数节点无法在主要节点上定居,并陷入政治僵局(又名没有多数的hung parliament).>重新选举发生但主要人物仍在下降;它的另一个僵局.循环在这里.
一种解决方案是通过赋予选票权重以使候选人不再平等来影响选举.在mongo世界中,这是通过为成员分配优先级来完成的.
Priority Comparisons The priority setting affects elections. Members
will prefer to vote for members with the highest priority value.
一个是通过进入mongo shell(在admin上)并更新rs.conf来实现的
cfg = rs.conf() cfg.members[0].priority = 100 cfg.members[1].priority = 99 cfg.members[3].priority = 98 rs.reconfig(cfg)
在此配置下,当主成员0失败时,成员1将被投票为主要成员.
这里有一些很好的链接:
http://docs.mongodb.org/manual/core/replica-set-elections/
http://docs.mongodb.org/manual/core/replica-set-architecture-four-members/
最后,这种情况在云架构中很常见,其中包括可用性集等技术,即按时间,cpu,负载或其他指标进行扩展和缩小 – 并且应该通过随机或某种不公平的区分策略来处理对于所有默认副本集.即使没有技术,默认副本集上的主服务器也会在某个时刻出现死锁,使其无法使用.我认为是一个重大失败.
精彩评论