driver java mongodb - com.mongodb.MongoException: impossibile trovare un master

Question

Sto provando a connettermi a un mongodb remoto. Ho sviluppato la mia applicazione con il mongodb locale. Ora ho distribuito l'applicazione allo sviluppatore e configurato il dev mongodb. Sto ottenendo la seguente eccezione.

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) 

La cosa divertente è che posso collegare al MongoDB dev con gli indirizzi dei server set di repliche da mia domanda locale, ma quando provo ad avere l'applicazione (dispiega nel dev) collegarsi al MongoDB dev, Vedo l'errore sopra.

Mi chiedo se c'è qualcuno che ha affrontato lo stesso problema e lo ha risolto.

Answer 1

Questo aspetto confondente di mongodb si scontra con i principi della scienza politica nel suo voting policy.

Ecco come succede.

• Esiste un set di repliche; deve avere un numero dispari di nodi di voto.
• Il nodo primario non riesce perché il server/la rete si arresta o viene disattivato. Altri nodi potrebbero anche non riuscire, ma soprattutto ...
• Un numero pari di nodi rimane senza primario.
• Il numero di nodi pari rimanenti non può stabilirsi su un primario e viene catturato in un deadlock politico (noto anche come hung parliament senza maggioranza).
  • Una rielezione si verifica ma il primario è ancora inattivo; è un altro punto morto. Loop qui.

Una soluzione è quella di influenzare le elezioni assegnando peso di voti in modo tale che i candidati non sono più uguali. Nel mondo dei mongo, questo viene fatto assegnando priority ai membri.

Confronti di priorità L'impostazione della priorità influisce sulle elezioni. I membri preferiranno votare per i membri con il valore di priorità più alto.

Uno fa questo inserendo il mongo shell (su admin) e aggiornando la rs.conf

cfg = rs.conf() 
cfg.members[0].priority = 100 
cfg.members[1].priority = 99 
cfg.members[3].priority = 98 
rs.reconfig(cfg) 

Con questa configurazione, quando l'elemento primario 0 fallisce membro 1 sarà votata come primario.

Qui ci sono alcuni buoni collegamenti:

http://docs.mongodb.org/manual/core/replica-set-elections/

http://docs.mongodb.org/manual/core/replica-set-architecture-four-members/

Infine, questa situazione è molto comune su un'architettura cloud con tecniche come disponibilità set, che è scalare su e giù - per tempo, CPU, carico o con altre metriche - e dovrebbe essere veramente gestito da un criterio di discriminazione casuale o ingiusta per tutti i set di repliche predefinite. Anche senza tecniche, un primario su un set di repliche predefinito sta per deadlock a un certo punto, rendendolo non disponibile. Un fallimento significativo a mio parere.