Questa non sarà di gran lunga una risposta completa, ci sono troppi dettagli e potrei scrivere un intero saggio su questa domanda come molti altri tuttavia, dato che non ho quel tipo di tempo libero, aggiungerò alcuni commenti su quello che vedo.
I set di repliche non sono progettati per funzionare in questo modo. Se desideri bilanciare il carico, potresti effettivamente cercare lo sharding che ti consentirà di farlo.
La replica è per il failover automatico.
Dal momento che, per rimanere aggiornati, i tuoi membri riceveranno tante operazioni quante sono le primarie, sembra che questo potrebbe non aiutare troppo.
In realtà invece di avere un server con molte connessioni in coda, hai molte connessioni su molti server in coda per dati obsoleti poiché la coerenza dei membri è eventuale, non immediata a differenza delle tecnologie ACID, tuttavia, detto questo sono coerenti solo alla fine per 32 ms dispari che significa che non sono abbastanza in ritardo per fornire un throughput decente se il primario viene caricato.
Poiché le letture SONO simultanee, otterrai la stessa velocità sia che tu stia leggendo dal primario o dal secondario. Suppongo che potresti ritardare uno slave per creare una pausa di OP, ma ciò riporterebbe in cambio dati massicciamente obsoleti.
Per non parlare del fatto che MongoDB non è multi-master in quanto tale, puoi scrivere solo su un nodo alla volta, rende slaveOK non l'impostazione più utile al mondo e ho visto numerose volte in cui 10gen stessi consigliano di utilizzare lo sharding su questa impostazione.
Ciò richiederebbe la tua codifica. A quel punto potresti prendere in considerazione l'utilizzo effettivo di un database che supporti http://en.wikipedia .org/wiki/Replica_multi-master
Questo perché la velocità che stai cercando è molto probabilmente in realtà in scrittura non in lettura come ho discusso sopra.
Questo è il modo consigliato ma hai trovato l'avvertenza con esso. Sfortunatamente questo è qualcosa che rimane irrisolto che la replica multi-master dovrebbe risolvere, tuttavia, la replica multi-master aggiunge la propria nave di topi della peste alla stessa Europa e ti consiglio vivamente di fare qualche ricerca seria prima di pensare se MongoDB al momento non può soddisfare le tue esigenze.
Potresti non preoccuparti di nulla in realtà poiché la coda fsync è progettata per gestire il collo di bottiglia dell'IO che rallenta le tue scritture come farebbe in SQL e le letture sono simultanee, quindi se pianifichi lo schema e il set di lavoro correttamente dovresti essere in grado di ottenere un enorme quantità di OP.
C'è infatti una domanda collegata qui intorno da un dipendente 10gen che è molto bello leggere:https:/ /stackoverflow.com/a/17459488/383478 e mostra quanto throughput MongoDB può ottenere sotto carico.
Crescerà presto con il nuovo blocco a livello di documento che è già nel ramo dev.
