Ci sono diversi modi per configurare la replica dei database con MySQL. Il più utilizzato è la configurazione master-slave, anche se da diverso tempo è possibile utilizzare MySQL Fabric (su cui scriverò un articolo più avanti).

 

Il processo di replica consente di avere copie multiple dei dati di MySQL sincronizzando automaticamente dal server master al server slave. Questo consente di avere un server di database di backup che in caso di guasti può diventare il master, oppure semplicemente può essere utlilizzato per ripristinare i database all'ultima transaction disponibile. In pratica ogni transazione SQL viene eseguita sul master e sugli slave in modod tale da avere sempre due server completamente allineati. I server possono avere configurazioni diverse, quello che conta è che i database vengano replicati attraverso un utente dedicato. I software possono poi accedere ai dati in lettura su tutti i server del poll e in scrittura solo sul master. Per questo consiglio comunque di valutare attentamente se sia il caso di impiegare la replica o un cluster di mysql fabric.

 

Configurare l'instanza master di MySQL

Per configurare l'istanza master bisogna modificare il file di configurazione di MySQL, generalmente /etc/mysql/my.cnf

Aprite il file di configurazione my.cnf, e trovate queste righe, modificandole così:

bind-address = 0.0.0.0  
server-id = 1  
log-bin = /var/log/mysql/mysql-bin  
binlog-ignore-db = “mysql”  

Dovete decommentare le righe server-id e log-bin, aggiungere la riga inlog-ignore-db = “mysql” al file di configurazione di default. Potreste anche lavorare su un nuovo file che poi dovreste linkare alla configurazione del demone MySQL, oppure potreste anche creare un nuovo demone MySQL con una nuova configurazione. Per esempio potreste creare un demone di test che viene poi bindato ad una porta non ancora utilizzata, lasciando intaccato il MySQL originale, solo per scopi di test.

Note:

  • bind-address configura l'idirizzo dell'interfaccia che deve essere bindata al demone. Di default è configurato su 127.0.0.0 per consentire connessioni client solo da localhost. Se il vostro demone di replica si troverà su una VLAN dedicata, allora configurate solo l'IP dedicato alla replica.

  • server-id è un integer che viene assegnato ad ogni server MySQL. Ogni server deve avere un id univoco. Viene normalmente assegnato in sequenza.

  • log-bin attiva e configura la directory per il bin-log.

  • binlog-ignore-db fondamentale parametro che consente di NON replicare il database di sistema, che deve chiaramente essere diverso.


Configurare l'utenza di replica sul server master

Accedete al server MySQL e create l'utenza dedicata alla replica:

mysql> grant replication slave on *.* TO 'replica-user'@'<SLAVE>' identified by '<some_password>';  
mysql> flush privileges;  
mysql> quit  

Questo creerà l'utente replica-user, assegnandogli i diritti di replica. Questo utente esisterà solo sul server master, perché i database mysql, che contengono le configurazioni del server mysql, sono differenti e rimarranno indipendenti tra di loro.

Per verificare se l'utente è configurato correttamente, provate ad effettuare l'accesso dal server slave verso il master, impersonando l'utente replica-user:

mysql -h<MASTER> -ureplication -p  

Se tutto è stato configurato correttamente, avrete accesso al server MySQL.


Ottenere le coordinate del replication master binary log

Per configurare la replica sullo slave, dovrete ottenere la posizione attuale sul binary log. Si tratta dell'id dell'ultima SQL transaction.

Effettuate il log sul server MySQL master ed eseguite questa query:

mysql> FLUSH TABLES WITH READ LOCK;  
mysql > SHOW MASTER STATUS;  
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |     1234 |              | mysql            |
+------------------+----------+--------------+------------------+

La posizione in questo output di esempio è 1234.


Configurate l'istanza slave.

Come con l'istanza master, dobbiamo configurare il file di MySQL con l'id del server, in /etc/mysql/my.cnf.

Anche in questo consiglio di utilizzare una VLAN dedicata e un indirizzo raggiungibile solo all'interno di una subnet dedicata alla replica MySQL.

bind-address = 0.0.0.0  
server-id = 2  

Ora, configuriamo i dettagli del master sulla shell MySQL del server slave (dopo aver riavviato il demone ovviamente).

mysql>stop slave;  
mysql>CHANGE MASTER TO MASTER_HOST='<MASTER>', MASTER_USER='replica-user', MASTER_PASSWORD='<replica-user password>', MASTER_LOG_FILE='mysql-bin.0000001', MASTER_LOG_POS=1234;  
mysql>start slave;  

Le prove

Se tutto è andato a buon fine, la vostra istanza slave sta già replicando i dati dal server master.

Per verificare, effettuate l'accesso al MySQL sul server slave ed eseguite questa query : show slave status \G.

L'output somiglierà a questo:

mysql> show slave status \G  
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: mysqltest01
                  Master_User: replica-user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000002
          Read_Master_Log_Pos: 1515
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 1661
        Relay_Master_Log_File: mysql-bin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1515
              Relay_Log_Space: 1958
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No  
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1

 

Consiglio anche di effettuare delle query di scrittura sul master e verificare trmaite la lettura sullo slave.

Vedrete poi tutti i database ricrearsi e popolarsi sullo slave in breve tempo. Una volta terminato l'allineamento, la sincronizzazione sarà immediata.

In caso di perdita di connettività, quando questa sarà ripristinata la sincronizzazione riprenderà automaticamente.

Per attivare più slave ripetete semplicemente i passaggi riguardanti la configurazione del demone, utilizzando lo stesso utente di replica.

 

 

Pin It

ImpresaCloud

ImpresaCloud

Richiedi riparazione

5 facili step per la riparazione della tua pratica

Laboratorio di informatica e di elettronica

Cerchi informazioni sulle riparazioni in laboratorio? Hai qualche curiosità riguardo la riparazione di qualche scheda elettronica in particolare? Nella sezione Riparazioni del nostro Blog troverai moltissime informazioni utili e curiosità riguardanti il mondo dell'informatica e dell'elettronica.

 

Software gestionali

Nel nostro Blog troverai gratis tante informazioni utili riguardo i nostri software gestionali, guide passo-passo per l'utilizzo dei programmi, suggerimenti e aiuto.

 

Sistemistica informatica

Nel Blog Sistemistica troverai interessanti articoli scritti dal nostro team riguardanti il mondo di BSD, Linux, e dei Server Windows. Tutorial, best-practices, e tanto altro.

 

Notizie

Notizie interessanti riguardanti l'elettronica e l'informatica.