In una configurazione di replica di un hosting MySQL, il parametro Seconds_Behind_Master (SBM), come visualizzato dal comando SHOW SLAVE STATUS, è comunemente usato come indicazione dell'attuale ritardo di replica dello slave . In questo post del blog, esaminiamo come comprendere e interpretare questo valore in varie situazioni.
Possibili valori di secondi dietro il maestro
Il valore di SBM, come spiegato nella documentazione di MySQL, dipende dallo stato dello slave MySQL in generale e dagli stati dello slave MySQL SQL_THREAD e IO_THREAD in particolare. Mentre IO_THREAD si connette al master e legge gli aggiornamenti, SQL_THREAD applica questi aggiornamenti allo slave. Esaminiamo i possibili valori di SBM durante i diversi stati dello slave MySQL.
Quando il valore SBM è nullo
- SBM è sempre NULL se il tuo slave è fermo o il tuo thread SQL è fermo (o non è in esecuzione).
- SBM sarà anche NULL se il thread IO viene interrotto, a condizione che il thread SQL abbia già elaborato tutti gli eventi dal registro di inoltro. Un esempio di output di SHOW SLAVE STATUS (ritagliato per mostrare solo i valori di interesse) lo dimostra:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:No
Slave_SQL_Running:Sì
Seconds_Behind_Master:NULL
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:lo slave ha letto tutti i log di inoltro; in attesa di ulteriori aggiornamenti
Recuperato_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213
Quando il valore SBM è zero o positivo
- SBM rifletterà un valore valido (>=0) quando il thread SQL sta elaborando attivamente gli eventi. Questo è vero indipendentemente dallo stato del thread IO. Ad esempio:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:No
Slave_SQL_Running:Sì
Seconds_Behind_Master:3399
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:in attesa che i lavoratori schiavi elaborino le loro code
Recuperato_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-118774
Nell'esempio sopra, possiamo vedere che lo slave è dietro il master confrontando Retrieved_GTID_Set e Executed_GTID_Set. In questi casi, Seconds_Behind_Master rappresenterà la differenza tra il timestamp dell'ultima transazione elaborata dal thread SQL e il timestamp della stessa transazione quando è stata elaborata sul master. Questo timestamp della transazione del master viene preservato tramite la replica e quindi lo slave sarà in grado di calcolare l'SBM localmente.
Inoltre, una volta che lo slave ha recuperato completamente tutti i log di inoltro, (ad es. il GTID eseguito diventa 23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213/), Seconds_Behind_Master lo farà passa a '0' se il thread IO è in esecuzione o a 'NULL' se il thread IO non è in esecuzione.
Tutorial #MySQL – Capire i secondi dietro il valore principaleFai clic per twittare
Capire la velocità di esecuzione dello slave MySQL
Presupponendo che il thread SQL e IO Thread sullo slave siano in stato di esecuzione, è possibile comprendere le velocità di esecuzione relative del master e dello slave monitorando il valore SBM. Un valore '0' coerente o un valore costante indica che lo slave sta eseguendo alla stessa velocità del master. D'altra parte, una pendenza verso l'alto per Seconds_Behind_Master indica che lo slave sta funzionando più lentamente del master.
La Console di monitoraggio di ScaleGrid per MySQL in Azure traccia i valori di SBM nel tempo per i nodi slave.
Valore zero o costante di SBM
Nell'esempio sopra, lo slave è stato avviato circa 40 ore dopo che il master aveva scritture attive. Una volta avviato, lo slave ha iniziato a replicare quei dati e vediamo che l'SBM era piuttosto piatto, indicando che lo slave veniva eseguito alla stessa velocità del master. Si noti inoltre che il calo di SBM a "0" è notevole, il che significa che sebbene l'ultima transazione eseguita dallo slave sia stata eseguita circa 40 ore prima sul master, una volta che abbiamo raggiunto, c'è un ritardo di "0".
Valori crescenti di SBM
Nel grafico sottostante, possiamo vedere che SBM è in costante aumento, il che significa che la velocità di esecuzione dello slave è inferiore rispetto a quella del master. Questo è in realtà un caso in cui stiamo eseguendo 20 thread eseguendo scritture continue sul master e uno slave a thread singolo non è in grado di tenere il passo con esso.
Infine, è importante notare che nelle nostre discussioni finora non abbiamo ipotizzato alcun collo di bottiglia nella rete. In caso di reti lente, lo stesso thread IO slave sarà in ritardo rispetto al master e, se il thread SQL è abbastanza veloce, l'SBM oscillerà tra "0" e un numero positivo. In questi casi, SBM non sarà un parametro utile per capire il reale lag con il master.
Se ti è piaciuto questo post del blog, dai un'occhiata ai nostri altri popolari tutorial sulla gestione dei database MySQL per saperne di più sull'ottimizzazione delle tue implementazioni:
- Calcolo della dimensione del pool di buffer InnoDB per il tuo server MySQL
- Tutorial MySQL – Configurazione e gestione di SSL sul tuo server MySQL
- Spiegazione di MySQL High Availability Framework – Parte I:Introduzione
