Salve a tutti, per chi aveva già letto i miei post precedenti in merito alle repliche di MySQL (link sotto a seguire), vorrei semplicemente mostrare come sia possibile, avendo un bin-log file prodotto da un master, sfruttarlo per poter visualizzare le istruzioni passo – passo che sono state eseguite e di conseguenza replicate poi sugli slave che siete andati a configurare.
Post precedenti in merito alle repliche sono:
https://www.tonchella.it/mysql-repliche-master-slave/ => MySql repliche – Master & Slave
https://www.tonchella.it/mysql-repliche-master-slave-manutenzione/ => MySql repliche – Master & Slave – manutenzione
A cosa potrebbe servire “smontare” ed analizzare un bin-log file?? Una spiegazione valida su cosa sono e a cosa servano i bin-log file la si può trovare qui:
http://dev.mysql.com/doc/refman/5.0/en/binary-log.html
Vediamo subito qualche esempio di caso d’uso…
Mai successo che qualche programma scritto male, oppure qualche utente mal intenzionato “rovini” i vostri dati?
Nel caso in cui si verifichi una tale situazione, le repliche che avevamo tanto duramente configurato, non ci preservano da tali inconvenienti, semmai possono però renderci la vita assai più facile nel caso in cui la macchina fisica subisca un failover dovuto ad un guasto hardware, essendoci più macchine il problema è risolto grazie alla ridondanza dei sistemi.
Oppure nel caso in cui la nostra ditta sia dislocata in più siti geografici diversi, le repliche potrebbero aiutare al miglioramento della disponibilità dei dati aziendali e all’incremento delle performance sulla disponibilità dei dati stessi.
Ma nel caso visto sopra??
Quando i dati vengono scritti in modo errato le repliche provvedono (in modo anche abbastanza efficiente) a diffondere gli errori a tutti i nodi dei vari server slave…
Quindi, che fare??
Ebbene voi direte: “esiste pur sempre il backup da cui poter recuperare una situazione valida ed effettuando il restore direttamente sul master esso provvederà poi alla propagazione dei dati corretti a tutti gli altri slave!”
Certamente, questa potrebbe essere una soluzione sicuramente valida!
C’è però da considerare il fatto che tra l’ultimo backup (dump) e l’ipotetico “danno” potrebbero essere passate diverse ore di lavoro e, nel caso peggiore, adirittura diversi giorni, con il conseguente fatto di aver perso molte ore di lavoro prezioso !! 🙁
Quindi se volessimo sapere esattamente passo a passo quali istruzioni è andato ad eseguire il nostro server….
Se riuscissimo a fare questo, potremmo quindi pensare di effettuare un restore dell’ultimo dump valido sul master e, poi integrarlo, con le istruzioni sino ad un momento prima delle istruzioni che hanno prodotto le anomalie di inserimento o le anomalie di aggiornamento.
Tali informazioni ci consentirebbero anche di effettuare il miglioramento degli applicativi, comprendendo meglio alcune dinamiche sulle istruzioni sql che gli applicativi passano al motore di database.
Ebbene… Esiste un eseguibile che funziona da riga di comando:
mysqlbinlog.exe
Solitamente il file eseguibile (almeno su sistemi operativi Windows) si trova in C:\Program Files\MySQL\MySQL Server [vers]\bin.
Questo il suo help.
Al link seguente si trova invece la documentazione ufficiale:
http://dev.mysql.com/doc/refman/5.0/en/mysqlbinlog.html
A me in questi giorni si è rilevato particolarmente utile il suo utilizzo.
Consiglio tutti coloro che lo vogliano provare a bloccare il master, effettuare una copia fisica del file bin-log, sbloccare il master e poi provare ad utilizzare tale eseguibile, ne rimmarrete sorpresi dalla versatilità e facilità d’uso.
