CHANGE MASTER TO
Sintassi
CHANGE MASTER ["nome_connessione"] TO def_master [, def_master] ... def_master: MASTER_BIND = 'nome_interfaccia' | MASTER_HOST = 'nome_host' | MASTER_USER = 'nome_utente' | MASTER_PASSWORD = 'password' | MASTER_PORT = num_porta | MASTER_CONNECT_RETRY = intervallo | MASTER_HEARTBEAT_PERIOD = intervallo | MASTER_LOG_FILE = 'nome_log_master' | MASTER_LOG_POS = pos_log_master | RELAY_LOG_FILE = 'nome_relay_log' | RELAY_LOG_POS = pos_relay_log | MASTER_SSL = {0|1} | MASTER_SSL_CA = 'nome_file_ca' | MASTER_SSL_CAPATH = 'nome_dir_ca' | MASTER_SSL_CERT = 'nome_file_cert' | MASTER_SSL_KEY = 'nome_file_chiave' | MASTER_SSL_CIPHER = 'lista_cifrature' | MASTER_SSL_VERIFY_SERVER_CERT = {0|1}
Spiegazione
CHANGE MASTER
TO modifica i parametri utilizzati dallo slave per connettersi e comunicare con il master. Inoltre aggiorna i contenuti dei file master.info e relay-log.info.
MASTER_USER
, MASTER_PASSWORD
,
MASTER_SSL
, MASTER_SSL_CA
,
MASTER_SSL_CAPATH
, MASTER_SSL_CERT
,
MASTER_SSL_KEY
, MASTER_SSL_CIPHER
e
MASTER_SSL_VERIFY_SERVER_CERT
forniscono allo slave informazioni su come connettersi al master.
MASTER_SSL_VERIFY_SERVER_CERT
è stato aggiunto in MySQL 5.1.18. Si usa come spiegato per l'opzione --ssl-verify-server-cert
alla pagina: http://dev.mysql.com/doc/refman/5.1/en/ssl-options.html
MASTER_CONNECT_RETRY
specifica quanti secondi deve attendere prima di riprovare a connettersi. Il default è 60. Il numero massimo di tentativi di riconnessione è determinato dall'opzione server --master-retry-count
; per ulteriori informazioni, si veda http://dev.mysql.com/doc/refman/5.1/en/replication-options.html.
Le opzioni SSL (MASTER_SSL
,
MASTER_SSL_CA
, MASTER_SSL_CAPATH
,
MASTER_SSL_CERT
, MASTER_SSL_KEY
,
MASTER_SSL_CIPHER
) e
MASTER_SSL_VERIFY_SERVER_CERT
possono essere impostate anche sugli slave compilati senza il supporto a SSL. Esse vengono salvate nel file master.info file, ma ignorate se non si utilizza un server con il supporto SSL abilitato.
Se non si specifica un certo parametro, esso mantiene il vecchio valore, eccetto dove indicato nella seguente spiegazione. Per esempio, se la password per connettersi al master viene modificata, per comunicare la nuova password allo slave è sufficiente usare le seguenti istruzioni:
STOP SLAVE; -- se la replica è in funzione CHANGE MASTER TO MASTER_PASSWORD='new3cret'; START SLAVE; -- se si vuole riavviare la replica
Non c'è bisogno di specificare i parametri che non si desidera modificare (host, porta, utente e così via).
MASTER_HOST
e MASTER_PORT
sono il nome (o l'indirizzo IP) dell'host del master e la sua porta TCP/IP.
Le prossime due opzioni sono disponibili solo in MySQL Cluster NDB 6.3 e 6.4; non sono supportate in MySQL 5.1:
MASTER_BIND
si usa con gli slave che hanno diverse interfacce di rete, e determina quale di queste viene utilizzata per connettersi al master. E' possibile determinare quale interfaccia debba essere usata anche avviando il processo mysqld dello slave con l'opzione--master-bind option
.
La possibilità di legare uno slave a una specifica interfaccia di rete è stata aggiunta in MySQL Cluster NDB 6.3.4.MASTER_HEARTBEAT_PERIOD
serve a impostare l'intervallo, in secondi, tra gli heartbeat della replica. Ogni volta che viene aggiunto un evento al log binario del master, il periodo di attesa per il prossimo heartbeat viene azzerato. L'intervallo è un valore decimale che va da 0 a 4294967 secondi, e ha una risoluzione di un centesimo di secondo; il valore non-zero più basso è quindi 0.001. Gli heartbeat sono inviati al master solo se non vi sono eventi ancora da inviare nel log binario per un periodo più lungo dell'intervallo impostato.
Impostando l'intervallo a 0 si disabilitano completamente gli heartbeat. Il valore predefinito è uguale al valore di slave_net_timeout diviso 2.
Nota: Se si imposta @@global.slave_net_timeout a un valore minore dell'attuale intervallo degli heartbeat si ottiene un warning.
EseguendoRESET SLAVE
si imposta l'intervallo al valore predefinito.MASTER_HEARTBEAT_PERIOD
è stato aggiunto in MySQL Cluster NDB 6.3.4.
Nota: La replica non può utilizzare i file dei socket di Unix. E' necessario connettersi utilizzando TCP/IP.
Se si specificano MASTER_HOST
o MASTER_PORT
, lo slave assume che il master sia cambiato (anche se si specificano gli stessi valori di prima).In tal caso, i vecchi valori del log binario del master e la posizione sono considerati come non più applicabili, pertanto se non si specificano MASTER_LOG_FILE
e MASTER_LOG_POS
nell'istruzione, verranno aggiunti automaticamente MASTER_LOG_FILE=''
e MASTER_LOG_POS=4
.
Impostare MASTER_HOST=''
— cioè impostare esplicitamente il valore a una stringa vuota — non è lo stesso che non impostarla affatto. Se la si imposta ad una stringa vuota, START SLAVE
fallisce. Questo problema verrà risolto in MySQL 6.0. (MySQL Bug #28796)
MASTER_LOG_FILE
e MASTER_LOG_POS
sono le coordinate alle quali il thread I/O dello slave dovrebbe iniziare a leggere dal master, al prossimo avvio di questo thread. Se si specifica una delle due coordinate, non è possibile specificare RELAY_LOG_FILE
o RELAY_LOG_POS
. Se non si indica né MASTER_LOG_FILE
, né MASTER_LOG_POS
, lo slave utilizza quelle che erano le ultime coordinate del thread SQL prima dell'esecuzione di CHANGE MASTER TO
. Questo fa sì che non ci sia discontinuità nella replica, anche se il thread SQL fosse in ritardo rispetto al thread I/O, nel momento in cui si è modificata, ad esempio, la password.
CHANGE MASTER TO
elimina tutti i file del relay log e ne crea uno nuovo, a meno che si specifichi RELAY_LOG_FILE
o RELAY_LOG_POS
. In questo caso, il relay log viene mantenuto; la variabile globale relay_log_purgeviene impostata silenziosamente a 0.
CHANGE MASTER TO
serve a impostare uno slave quando si ha lo snapshot del master e si ha registrato il log e la posizione corrispondente. Dopo aver caricato lo snapshot nello slave, è possibile eseguire
CHANGE MASTER TO MASTER_LOG_FILE='nome_log_sul_master'
,
MASTER_LOG_POS=posizione_log_sul_master
sullo slave.
L'esempio seguente modifica il master e le coordinate del suo log binario. E' utile quando si desidera impostare lo slave per replicare il master:
CHANGE MASTER TO MASTER_HOST='master2.mycompany.com', MASTER_USER='replication', MASTER_PASSWORD='bigs3cret', MASTER_PORT=3306, MASTER_LOG_FILE='master2-bin.001', MASTER_LOG_POS=4, MASTER_CONNECT_RETRY=10;
Il prossimo esempio mostra un'operazione che si esegue meno frequentemente. Si usa quando si desidera eseguire nuovamene i relay log dello slave per una qualche ragione. Per farlo, il master non deve essere raggiungibile. Occorre lanciare
CHANGE MASTER TO
e avviare il thread SQL:
(START SLAVE SQL_THREAD
):
CHANGE MASTER TO RELAY_LOG_FILE='slave-relay-bin.006', RELAY_LOG_POS=4025;