原因是這樣的,我們項目有很多台式機(主機)是放到現場作為采集服務器用的,使用的數據庫是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的文檔。