2013-06-17 7 views
19

Per impostare il set di repliche, ho eseguito in 3 schede terminali separati:MongoDB replica insieme impedendo query secondaria

$ sudo mongod --replSet rs0 --dbpath /data/mining --port 27017 
$ sudo mongod --replSet rs0 --dbpath /data/mining2 --port 27018 
$ sudo mongod --replSet rs0 --dbpath /data/mining3 --port 27019 

Poi, ho configurato replica nel guscio Mongo e verificato che ha funzionato:

> var rsconf = { 
    _id: "rs0", 
    members: [ 
     { 
     _id: 0, 
     host: 'localhost:27017' 
     }, 
     { 
     _id: 1, 
     host: 'localhost:27018' 
     }, 
     { 
     _id: 2, 
     host: 'localhost:27019' 
     } 
    ] 
    }; 
> rs.initiate(rsconf); 
{ 
    "info": "Config now saved locally. Should come online in about a minute.", 
    "ok": 1 
} 
// Some time later... 
> rs.status() 
{ 
    "set": "rs0", 
    "date": ISODate("2013-06-17T13:23:45-0400"), 
    "myState": 2, 
    "syncingTo": "localhost:27017", 
    "members": [ 
    { 
     "_id": 0, 
     "name": "localhost:27017", 
     "health": 1, 
     "state": 1, 
     "stateStr": "PRIMARY", 
     "uptime": 4582, 
     "optime": { 
     "t": 1371489546, 
     "i": 1 
     }, 
     "optimeDate": ISODate("2013-06-17T13:19:06-0400"), 
     "lastHeartbeat": ISODate("2013-06-17T13:23:44-0400"), 
     "lastHeartbeatRecv": ISODate("2013-06-17T13:23:44-0400"), 
     "pingMs": 0 
    }, 
    { 
     "_id": 1, 
     "name": "localhost:27018", 
     "health": 1, 
     "state": 2, 
     "stateStr": "SECONDARY", 
     "uptime": 5034, 
     "optime": { 
     "t": 1371489546, 
     "i": 1 
     }, 
     "optimeDate": ISODate("2013-06-17T13:19:06-0400"), 
     "self": true 
    }, 
    { 
     "_id": 2, 
     "name": "localhost:27019", 
     "health": 1, 
     "state": 2, 
     "stateStr": "SECONDARY", 
     "uptime": 4582, 
     "optime": { 
     "t": 1371489546, 
     "i": 1 
     }, 
     "optimeDate": ISODate("2013-06-17T13:19:06-0400"), 
     "lastHeartbeat": ISODate("2013-06-17T13:23:44-0400"), 
     "lastHeartbeatRecv": ISODate("2013-06-17T13:23:45-0400"), 
     "pingMs": 0, 
     "syncingTo": "localhost:27017" 
    } 
    ], 
    "ok": 1 
} 

il mio script funziona bene contro il primario:

$ ./runScripts.sh -h localhost -p 27017 
MongoDB shell version: 2.4.3 
connecting to: localhost:27017/test 
Successful completion 

Tuttavia, contro eith er secondaria:

$ ./runScripts.sh -h localhost -p 27018 
MongoDB shell version: 2.4.3 
connecting to: localhost:27017/test 
Mon Jun 17 13:30:22.989 JavaScript execution failed: count failed: 
{ "note" : "from execCommand", "ok" : 0, "errmsg" : "not master" } 
at src/mongo/shell/query.js:L180 
failed to load: /.../.../myAggregateScript.js 

Ho letto in più posti di utilizzare rs.slaveOk() o db.getMongo().setSlaveOk(), ma nessuno di questi ha avuto alcun effetto, se è entrato dalla shell o chiamato nel mio script. Queste istruzioni non hanno generato errori quando sono state chiamate, ma non hanno risolto il problema.

Qualcuno sa perché non riesco a configurare il mio replset per consentire l'interrogazione del secondario?

+1

rs.slaveOk() dovrebbe consentire di leggere. Ho appena testato usando la shell mongo e 2.4.3 e un count() ha funzionato per me. Puoi condividere il tuo script? –

+0

@JamesWahlin ha ragione - l'unico modo in cui ciò accade è se non hai impostato rs.slaveOk() prima di eseguire il comando che ha dato questo output. Maggiori informazioni sul contenuto del tuo js script possono aiutare. –

+2

possibile duplicato di [mongodb, repliche ed errore: {"$ err": "non master e slaveOk = falso", "codice": 13435}] (http://stackoverflow.com/questions/8990158/mongodb-replicates- e-error-err-not-master-and-slave-false-code) – Pykler

risposta

47

rs.slaveOk() eseguito nella shell mongo consente di leggere da secondari. Ecco una dimostrazione utilizzando la shell mongo in MongoDB 2.4.3:

$ mongo --port 27017 
MongoDB shell version: 2.4.3 
connecting to: 127.0.0.1:27017/test 
replset:PRIMARY> db.foo.save({}) 
replset:PRIMARY> db.foo.find() 
{ "_id" : ObjectId("51bf5dbd473d5e80fc095b17") } 
replset:PRIMARY> exit 

$ mongo --port 27018 
MongoDB shell version: 2.4.3 
connecting to: 127.0.0.1:27018/test 
replset:SECONDARY> db.foo.find() 
error: { "$err" : "not master and slaveOk=false", "code" : 13435 } 
replset:SECONDARY> rs.slaveOk() 
replset:SECONDARY> db.foo.find() 
{ "_id" : ObjectId("51bf5dbd473d5e80fc095b17") } 
replset:SECONDARY> db.foo.count() 
1 
+0

grazie mille per questo. –

+1

Ci sono dei motivi per cui 'slaveOK' esiste, varrebbe la pena sottolinearne le ragioni. Ad esempio: 'IMPORTANTE Prestare attenzione quando si specificano le preferenze di lettura: Modalità diverse da primario potrebbero restituire dati non aggiornati perché con la replica asincrona, i dati nel secondario potrebbero non riflettere le operazioni di scrittura più recenti. – Madbreaks

+0

Duhhh I era connesso su 27017 quale era il mio primaria .... dopo un riavvio ho dovuto ricostruire la cosa stupida, e il mio nuovo master era 27018. Il post di cui sopra ha aiutato. – Andy

13

Devi eseguire il comando rs.slaveOk() in guscio del server secondario.