Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial
  • Lezione 38 di 58
  • livello intermedio
Indice lezioni

Replica Master/Slave in MySQL: il lato Slave

Guida alla configurazione della replicazione Master/Slave su MySQL (con focus sul server slave), al fine di realizzare un cluster di database relazionali.
Guida alla configurazione della replicazione Master/Slave su MySQL (con focus sul server slave), al fine di realizzare un cluster di database relazionali.
Link copiato negli appunti

Prima sincronizzazione tra master e slave

Una volta configurato il server master, la prima cosa da fare è portare il server slave ad un punto zero da cui possa eseguire la sincronizzazione, ovviamente nell'ipotesi che sul server master esista già un database popolato. Per fare questo è necessario collegarsi al server master tramite shell o altro accesso, ed eseguire le query seguenti:

USE database1;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Le prime due query servono ad impedire operazioni in scrittura sul database che vogliamo replicare (e che abbiamo scelto nel file di configurazione del master). La terza query serve ad ottenere dei dati fondamentali per avviare la replicazione, dal momento che l'output da essa prodotto sarà simile al seguente:

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      151 | database1    |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Segnamoci da qualche parte il risultato dei campi File e Position (in questo caso rispettivamente mysql-bin.000001 e 151), poichè ci serviranno più avanti.

A questo punto eseguiamo un dump del database di nostro interesse con il software che utilizzate normalmente per questa operazione, oppure attraverso una shell SSH, con il comando seguente, sostituendo database1 con il nome reale del nostro database:

mysqldump -u root -p database1 > database1_dump.sql

Eseguito il dump, e segnato il numero Position restituito dalla query precedente, abbiamo uno stato di replicazione completo e possiamo (anzi, dobbiamo) rimuovere il lock in scrittura sul database. Per fare ciò, sempre sul server master eseguiamo le seguenti query:

USE database1;
UNLOCK TABLES;

L'ultima cosa che ci resta da fare per la prima sincronizzazione è l'import, sul server slave, del dump appena creato sul master. Per eseguire questo dump possiamo usare diversi software, o anche la linea di comando di mysql.

Configurare i server slave

A questo punto abbiamo terminato le operazioni da eseguire sul server master, e possiamo concentrarci esclusivamente sugli slave. Per ogni server slave dobbiamo modificare il file di configurazione di MySQL in maniera analoga a quanto fatto per il server master, ma con alcune differenze.

Anche in questo caso dobbiamo impostare la direttiva server-id assegnando un identificativo numerico univoco (quindi diverso da tutti gli altri slave, ma anche da quello assegnato al master). Per quanto riguarda i log, inoltre, dobbiamo impostare le direttive relay-log, log_bin e binlog_do_db.

La direttiva relay-log, non presente sul server master, identifica il file di log che il server slave crea in locale con i dati presi dal master. Si tratta sostanzialmente di un buffer che il server slave usa per riportarsi al passo del server master senza interrompere la copia dei dati.

Il file di configurazione minimale dello slave quindi conterrà le seguenti direttive (anche in questo caso i valori delle direttive possono essere modificati):

server-id    = 2
relay-log    = /var/log/mysql/mysql-relay-bin.log
log_bin      = /var/log/mysql/mysql-bin.log
binlog_do_db = database1

Avvio della replicazione automatica

Dopo aver riavviato il demone di MySQL sul server slave possiamo attivare la replicazione tramite l'utilizzo di due query (da eseguire sul server slave). La prima serve alla configurazione:

CHANGE MASTER TO MASTER_HOST='xxx.xxx.xxx.xxx',MASTER_USER='user_replica', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=151;

Questa query deve essere personalizzata con i dati che abbiamo ottenuto fino a questo momento:

  • MASTER_HOST rappresenta l'indirizzo IP del server master su cui è in ascolto MySQL;
  • MASTER_USER rappresenta l'utente abilitato alla replicazione che abbiamo creato sul server master;
  • MASTER_PASSWORD rappresenta la password assegnata all'utente abilitato alla replicazione;
  • MASTER_LOG_FILE è l'indicazione File che abbiamo ottenuto precedentemente nella prima parte di questa lezione;
  • MASTER_LOG_POS è l'indicazione Position che abbiamo ottenuto precedentemente nella prima parte di questa lezione.

In questo modo abbiamo impostato i dati per l'accesso alla replicazione, abbiamo indicato al server slave da dove iniziare ad eseguire la replica (perché le modifiche precedenti sono già state attuate con il dump che rappresenta il punto di partenza) e abbiamo detto al server MySQL di prepararsi ad essere uno slave. Lo slave però deve essere avviato, e per questo è necessario eseguire una nuova query:

START SLAVE;

Analogamente è possibile interrompere la replica, ad esempio per eseguire manutenzione sul server, tramite la query:

STOP SLAVE;

A seguito delle operazioni di manutenzione è possibile riavviare direttamente la replica tramite START SLAVE senza la necessità di ripercorrere tutte le tappe viste in questa lezione (quindi non è necessario eseguire un dump o configurare il master).

Controllo dello stato della replica

Per controllare se la replica è attiva possiamo eseguire una query sul server slave:

SHOW SLAVE STATUS;

In questo modo abbiamo accesso a molte informazioni sulla condizione attuale della replica. Quelle che ci interessano in questo contesto sono:

Slave_IO_State: Waiting for master to send event
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

In particolare, l'informazione più immediata è quella riportata da Slave_IO_Running: Yes ci indica che sta andando tutto bene, No significa invece che un problema sta impedendo la replica.

Ti consigliamo anche