MySql repliche – come leggere un bin-log file

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:
http://www.tonchella.it/mysql-repliche-master-slave/ => MySql repliche – Master & Slave
http://www.tonchella.it/mysql-repliche-master-slave-manutenzione/ => MySql repliche – Master & Slave – manutenzione

A cosa potrebbe servire “smontare” ed analizzare un bin-log file?? Continue reading

MySql repliche – Master & Slave – manutenzione

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…
Continue reading

MySql repliche – Master & Slave

Sebbene questo articolo esula molto dal corso che mi ero proposto di redigere di volta in volta, in quanto tratta di argomenti di configurazione molto avanzata, reputando tali nozioni utilissime dal punto di vista sistemistico, ho deciso di inserire tale post comunque, costruendo una categoria ad hoc, relativa così ad argomenti più avanzati….

Insomma una cosa dedicata ai più “smanettoni” 🙂 …

La procedura che segue è stata ovviamente tratta dal sito ufficiale:
http://dev.mysql.com/doc/refman/5.1/en/replication.html

Innanzitutto, per chi non lo sapesse già, il meccanismo di replica qui descritto è detto anche asincrono, poichè le operazioni di scrittura vengono eseguite da un database primario detto Master e solo successivamente (se pur dopo un tempo brevissimo in alcuni casi) da un server secondario detto Slave. Per una replica sincrona è necessario utilizzare invece il MySQL Cluster, riguardo al quale spero prima o poi di scrivere un articolo…

Gli scopi di questo meccanismo sono:

  1. disponibilità del dato – in caso di problemi sul sever che ospita il Master possiamo rapidamente modificare impostazioni di slave in modo tale da modificare l’indirizzo IP della macchina e configurarlo come fosse il nuovo Master, in tal modo si eroga un servizio più continuo per le postazioni clients.
  2. bilanciamento del carico – avendo cura di effettuare le operazioni di scrittura  esclusivamente sul Master, possiamo utilizzare anche lo Slave in lettura, dividendo così il carico di lavoro sulle due macchine (particolarmente utile in presenza di quantitativi di dati piuttosto rilevanti).
  3. backup anche frequenti sia con dump che da filesystem – senza caricare eccessivamente o fermare il servizio sul Master, perchè viene sfruttato lo Slave.

Continue reading