原因是这样的,我们项目有很多台式机(主机)是放到现场作为采集服务器用的,使用的数据库是Mongodb.且,我们在阿里云购买了个云主机(从机),现场的台式机是保证对现场数据采集的完整性,阿里云主机(从机)保证现场数据的备份和万一现场断网,客户都可以通过阿里云读到以前的旧数据.
小伙看你根骨奇佳，潜力无限，来学PHP伐。
这个想法很合理呀。
如 @依云 所说，replica set里的primary和secondary不是固定的，是选举(election)而来的，所以机器之前的failover才得以实现。不过像题主这样，希望某个机器更可能成为primary，那就把它的priority设得比你在阿里云里的机器高，Priority的文档，如何操作。注意至少要有3个机器（包括arbitor），replica set才有意义。
这样，你在现场的机器有了高的优先级，只要它活着，数据不太老就会成为primary. 一开始的时候，大家都没有数据，现场的机器因为高优先级自然就成了primary. 如果现场机器挂了，另外两在阿里云的机器作为大多数(majority)会自动选出新的primary，继续快乐地工作，读数据当然没问题了。这时候，如果现场的机器活过来了，或者网好了，阿里云的机器发现现场的机器更适合当primary就主动step down，现场的机器自动就成了primary了，一切好像没发生过一样……参见Priority的文档。
这个想法很合理呀。
如 @依云 所说，replica set里的primary和secondary不是固定的，是选举(election)而来的，所以机器之前的failover才得以实现。不过像题主这样，希望某个机器更可能成为primary，那就把它的priority设得比你在阿里云里的机器高，Priority的文档，如何操作。注意至少要有3个机器（包括arbitor），replica set才有意义。
这样，你在现场的机器有了高的优先级，只要它活着，数据不太老就会成为primary. 一开始的时候，大家都没有数据，现场的机器因为高优先级自然就成了primary. 如果现场机器挂了，另外两在阿里云的机器作为大多数(majority)会自动选出新的primary，继续快乐地工作，读数据当然没问题了。这时候，如果现场的机器活过来了，或者网好了，阿里云的机器发现现场的机器更适合当primary就主动step down，现场的机器自动就成了primary了，一切好像没发生过一样……参见Priority的文档。