2013-10-30 9 views
18

c'è la replica con tre membri (primario, secondario, secondario). Supponiamo uno dei secondari in giù per un giorno, dopo il ritorno secondario alla replica come posso trovare, è ancora sincronizzato o no?Come controllare il secondario è ora sincronizzato o meno

L'ho fatto in ambiente di test, ma non sono riuscito a trovare dati utili da rs.status() e db.printReplicationInfo().

c'è "lunghezza del registro dall'inizio alla fine" in db.printReplicationInfo(). ma è un grande momento per impostazione predefinita e cresce quando secondario è inattivo.

risposta

25

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.

+0

grazie mille, sembra "(non raggiungibile/sano)" dovrebbe essere "SECONDARIO" – irmorteza

+0

Hai ragione :) – zero323

+0

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. –

1

Ho scritto un piccolo script per la shell mongoDB. Mostra un diff tra optime e optimeDate. È possibile utilizzarlo invece di confrontare i membri del set di repliche manualmente.

var isMaster = rs.isMaster(); 
var me = isMaster.me; 

if(!isMaster.ismaster && isMaster.secondary) 
{ 
    var status = rs.status(); 
    var master = isMaster.primary; 

    var masterOptime = 0; 
    var masterOptimeDate = 0; 
    var myOptime = 0; 
    var myOptimeDate = 0; 

    for(var i = 0 ; i < status.members.length ; i++) 
    { 
     var member = status.members[i]; 
     if(member.name == me) 
     { 
      if(member.stateStr == "SECONDARY") { 
       myOptime = member.optime.getTime(); 
       myOptimeDate = member.optimeDate.getTime(); 
      } 
      else 
      { 
       print(me + ' is out of sync ' + member.stateStr); 
       break; 
      } 
     } 
     else if(member.name == master) 
     { 
      masterOptime = member.optime.getTime(); 
      masterOptimeDate = member.optimeDate.getTime(); 
     } 

    } 

    if(myOptime && myOptimeDate) 
    { 
     var optimeDiff = masterOptime - myOptime; 
     var optimeDateDiff = masterOptimeDate - myOptimeDate; 

     print('optime diff: ' + optimeDiff); 
     print('optimeDate diff: ' + optimeDateDiff); 
    } 

} 
else 
{ 
    print(me + ' is not secondary'); 
} 
8

Aggiornamento 13 feb 2017

d'accordo con la risposta accettata che rs.status() offre informazioni adeguate ed è un comando facile da ricordare. Tuttavia, (personalmente usando Mongo 3 ora), mi piace molto anche la praticità e la leggibilità di rs.printSlaveReplicationInfo().

dà un qualcosa di output come:

rs.printSlaveReplicationInfo() 

source: node-2:27017 
    syncedTo: Mon Feb 13 2017 06:15:17 GMT-0500 (EST) 
    0 secs (0 hrs) behind the primary 
source: node-3:27017 
    syncedTo: Mon Feb 13 2017 06:15:16 GMT-0500 (EST) 
    1 secs (0 hrs) behind the primary 

Come si può vedere, è facile per ottenere un senso se la sincronizzazione tra i nodi nel set di repliche è sano o meno.