原因是这样的,我们项目有很多台式机(主机)是放到现场作为采集服务器用的,使用的数据库是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的文檔。