Nota: Assicuratevi di controllare the answer fornito da arcseldon per un equivalente user friendly.
È possibile utilizzare l'output di rs.status()
. Se secondario è sincronizzato e non è stato creato con l'opzione slaveDelay
, allora optime
e optimeDate
di secondario devono essere uguali o vicini (se ci sono operazioni in corso) a quelli di primario. In tal caso, stateStr
deve essere uguale a SECONDARY
. Quindi, se secondaria è sincronizzato si dovrebbe vedere un output simile a questo (un membro è stato rimosso dalla uscita per chiarezza):
{
"set" : "rs0",
"date" : ISODate("2013-11-08T14:58:49Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "hostname:27001",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 155,
"optime" : Timestamp(1383915748, 1),
"optimeDate" : ISODate("2013-11-08T13:02:28Z"),
"self" : true
},
{
"_id" : 2,
"name" : "hostname:27003",
"health" : 0,
"state" : 8,
"stateStr" : "SECONDARY",
"uptime" : 0,
"optime" : Timestamp(1383915748, 1),
"optimeDate" : ISODate("2013-11-08T13:02:28Z"),
"lastHeartbeat" : ISODate("2013-11-08T14:58:48Z"),
"lastHeartbeatRecv" : ISODate("2013-11-08T14:58:42Z"),
"pingMs" : 0,
"syncingTo" : "hostname:27001"
}
],
"ok" : 1
}
Qui si ha l'uscita del rs.status()
per lo stesso set di repliche se uno dei secondari non è sincronizzato. Prima di tutto vedrai che optime
e optimeDate
per hostname:27003
sono diversi da primario, stateStr è impostato su RECOVERING
e c'è lo lastHeartbeatMessage
appropriato.
{
"set" : "rs0",
"date" : ISODate("2013-11-08T15:01:34Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "hostname:27001",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 320,
"optime" : Timestamp(1383922858, 767),
"optimeDate" : ISODate("2013-11-08T15:00:58Z"),
"self" : true
},
{
"_id" : 2,
"name" : "hostname:27003",
"health" : 1,
"state" : 3,
"stateStr" : "RECOVERING",
"uptime" : 14,
"optime" : Timestamp(1383915748, 1),
"optimeDate" : ISODate("2013-11-08T13:02:28Z"),
"lastHeartbeat" : ISODate("2013-11-08T15:01:34Z"),
"lastHeartbeatRecv" : ISODate("2013-11-08T15:01:34Z"),
"pingMs" : 0,
"lastHeartbeatMessage" : "still syncing, not yet to minValid optime 527cfc90:19c4",
"syncingTo" : "hostname:27001"
}
],
"ok" : 1
}
Se secondario è stato realizzato con slaveDelay
poi optime
e optimeDate
possono essere diverse, ma stateStr
e lastHeartbeatMessage
indicherà se c'è qualche ritardo.
grazie mille, sembra "(non raggiungibile/sano)" dovrebbe essere "SECONDARIO" – irmorteza
Hai ragione :) – zero323
Grazie per il chiarimento sui campi 'optime' e' optimeDate'. Durante l'aggiornamento da 2.4 a 2.6, il messaggio 'syncingTo' non andava via, quindi non ero sicuro che ci fosse un problema nella sincronizzazione corretta. –