Sempre con riferimento a questo post, dimenticavo di annotare una cosa particolarmente utile inerente la configurazione su MySql repliche – Master & Slave – manutenzione.
Siccome il meccanismo delle repliche si basa su dei files: i bin-log (log binari) che la sezione MASTER genera al fine che gli SLAVE possano leggerla e quindi eseguirla in locale (questo molto in breve).
Allora mi sono posto una serie di domande…
- ma che fine fanno i bin-log files?
- Vengono cancellati da soli?
- Se no come si deve procedere?
Bene, quindi proviamo a rispondere a queste domande:
i files bin-log non si cancellano automaticamente, essi, al contrario, vengono lasciati sul MASTER; questo per tutta una serie di motivi; il primo ed è il più banale e semplicemente è dovuto al fatto che è corretto che risiedano sul MASTER visto che tale macchina è detentrice delle modifiche e quindi delle informazioni più aggiornate che verranno poi replicate sulle altre, inoltre i bin-log files non vengono cancellati poiché il MASTER non ha certezza che la replica sia stata effettuata su tutti gli SLAVE a lui connessi.
Quindi come e cosa fare per gestirli??
Questo controllo forse si potrebbe anche automatizzare, ma io preferisco “farlo a mano” come pianificazione programmata da parte del DB – Administrator, quindi accenneremo solo in modo rapido ad alcuni suggerimenti che nel mio caso applicheremo in vecchiaia in modo da preservare il nostro spazio disco qualora l’arteriosclerosi gi giochi dei brutti scherzi 🙂
Scherzi a parte, le operazioni da effettuare sono le seguenti:
- Determinare su tutti gli slave (in particolare quello che è più lento nel processo di replica) lo stato delle repliche effettuando un :
SHOW SLAVE STATUS\G - Annotarsi per tutti gli SLAVE lo stato delle repliche scrivendo in particolare il Master_Log_File ed il Read_Master_Log_Pos
- Una volta determinato quale sia il file e la posizione della replica più lenta si potrà così procedere all’eliminazione dei file bin-log dal MASTER che non sono più necessari.
Sempre per completezza, esistono due comandi che nello specifico sono:
SHOW MASTER LOGS – Che consente di visualizzare l’elenco dei files bin-log delle repliche sulla macchina MATER
SHOW BIN LOGS – Che consente di visualizzare l’elenco dei files bin-log delle repliche sulla macchina SLAVE
Il dettaglio dei comandi sopra esposti si trovano su:
http://dev.mysql.com/doc/refman/5.0/en/show-binary-logs.html
http://dev.mysql.com/doc/refman/5.0/en/purge-binary-logs.html
Quindi un ottimo sistema per poter eliminare i bin-log files consiste nell’utilizzare la seguente istruzione:
PURGE MASTER LOGS TO ‘nome_file_bin-log.numerofile‘;
Questa istruzione richiede al server di cancellare tutti i files dei registri binari con numeri inferiori al file menzionato che nello scenario descritto dovrebbe essere quello che è ancora in esecuzione per lo slave più lento (che di conseguenza lo sta utilizzando).
Questa operazione è normale amministrazione del DB.
- SHOW SLAVE STATUS è disponibile dalla versione MySQL 3.23.22
- PURGE MASTER LOGS è disponibile dalla versione MySQL 3.23.28
- Entrambe le istruzioni richiedono il privilegio di SUPER o
PROCESS prima della release MySQL 4.0.2
La mia insaziabile curiosità mi fa però porre un’altra domanda, anche da pigro programmatore quale io sono:
“Se è vero che ogni singola macchina potenzialmente può essere sia MATER sia SLAVE, allora ci deve essere senz’altro un modo più intelligente di automatizzare le operazioni di manutenzione sopra esposte per i bin-logs files dei vari servers.”
Per la risposta a tale domanda ci viene in aiuto il parametro expire_logs_days e per ulteriori dettagli mi riprometto di approfondire in un prossimo post; per chi invece è curioso quanto me, si legga http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_expire_logs_days per ulteriori dettagli.
