La réplication peut être contrôlée depuis l'interface SQL.
Voici un résumé des commandes disponibles :
Commande
|
Description
|
SLAVE START
|
Démarre le thred esclave.
Depuis MySQL 4.0.2, vous pouvez ajouter les options
IO_THREAD
ou
SQL_THREAD
à cette commande, pour démarrer le thread I/O ou le thread SQL.
Le thread I/O lit les requêtes depuis le maître, et les stockent dans le log
de relais. Le thread SQL lit le log de relais, et exécute les requêtes.
(Esclave) |
SLAVE STOP
|
Stoppe le thread esclave. Comme
SLAVE START
, cette commande
peut être utilisée avec les options
IO_THREAD
et
SQL_THREAD
.
(Esclave) |
SET SQL_LOG_BIN=0
|
Désactive le log binaire, si l'utilisateur a les droits de
SUPER
.
Ignoré sinon. (Maître) |
SET SQL_LOG_BIN=1
|
Réactive le log binaire, si
Re-enables update logging, si l'utilisateur a les droits de
SUPER
.
Ignoré sinon. (Maître) |
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=n
|
Ignore les
n
prochains événements du maître. Uniquement
valide lorsque le thread esclave ne fonctionne pas, sinon une erreur
est affichée. Très pratique pour corriger des petits problèmes de réplications. |
RESET MASTER
|
Efface tous les logs binaires dans le fichier d'index, et vide
le fichier de log binaire. Dans les versions antérieures à la 3.23.26, utilisez
FLUSH MASTER
.
(Maître) |
RESET SLAVE
|
Efface la position de réplication de l'esclave dans les logs du maître.
Makes the slave forget its replication position in the master
logs. Dans les versions antérieures à la 3.23.26, cette commande s'appelait
FLUSH SLAVE
. (Esclave) |
LOAD TABLE tblname FROM MASTER
|
Télécharge une copie des tables depuis le maître vers l'esclave. Implémentée
principalement pour le débogage de
LOAD DATA FROM MASTER
, mais certains
utilisateurs ``gourmets'' pourront la trouver pratique pour d'autres
utilisations. Ne l'utilisez pas si vous vous considérez comme un
utilisater ``non-hacker''. (Esclave) |
LOAD DATA FROM MASTER
|
Disponible depuis 4.0.0. Prend une copie des données du maître et les
transfère vers l'esclave. Met à jour les valeurs de
MASTER_LOG_FILE
et
MASTER_LOG_POS
de manière à ce que l'esclave démarre la réplication
depuis la position correcte. Cette commande respecte les règles d'exclusion
des tables et des bases spécifiées dans les options
replicate-*
. Actuellement
fonctionne uniquement avec les tables
MyISAM
et pose un verrou global
en lecture sur toutes les tables, pour faire la sauvegarde. Dans le futur, il
est prévu de rendre cette commande compatible avec les tables
InnoDB
et de supprimer le besoin du verrou global pour faire une
sauvegarde non bloquante. |
CHANGE MASTER TO master_def_list
|
Change les paramètres du maître avec les valeurs spécifiées
dans l'argument
master_def_list
et redémarre le thread esclave.
master_def_list
est une liste séparée par des virgules, avec les
variables suivantes :
MASTER_HOST
,
MASTER_USER
,
MASTER_PASSWORD
,
MASTER_PORT
,
MASTER_CONNECT_RETRY
,
MASTER_LOG_FILE
et
MASTER_LOG_POS
. Par exemple :
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;
|
Vous n'avez pas besoin de spécifier les valeurs que vous ne souhaitez pas
changer. Les valeurs omises conserveront leur valeur actuelle, même si vous
modifiez l'hôte ou le port. Dans ce cas, l'esclave supposer que puisque vous
vous connectez à un nouvel hôte ou un nouveau port, le maître est différent.
Par conséquent, il les anciennes valeurs de log et position ne sont plus applicables,
et il va automatiquement leur donner la valeur de la chaîne vide, et de 0, respectivement,
qui sont les valeurs de démarrage. Notez qui si vous redémarrez l'esclave
il va se souvenir de son ancien maître. Si vous ne le souhaitez pas,
il suffit d'effacer le fichier
master.info
avant de le redémarrer, et l'esclave
va lire la valeur depuis le fichier
my.cnf
ou la ligne de commande.Cette commande est pratique pour configurer un esclave lorsque vous avez
une sauvegarde du maître, et que vous avez sauvé la valeur du log et de son
offset chez le maître. Vous pouvez alors exécuter la commande
CHANGE MASTER TO MASTER_LOG_FILE='log_name_on_master',
MASTER_LOG_POS=log_offset_on_master
sur l'esclave après avoir restauré
la sauvegarde. (Esclave) |
SHOW MASTER STATUS
|
Fournit les informations de statut sur le
point de contrôle du fichier de log binaire du maître. (Maître) |
SHOW SLAVE HOSTS
|
Disponible depuis la version 4.0.0. Cette
commande liste les esclaves actuellement enregistré auprès du maître. (Maître) |
SHOW SLAVE STATUS
|
Fournit les informations essentielles sur
le statut de l'esclave. (Esclave) |
SHOW MASTER LOGS
|
Uniquement disponible depuis la version
3.23.28. Liste les logs binaires sur le maître. Vous devriez utiliser cette
commande avant d'utiliser la commande
PURGE MASTER LOGS TO
pour savoir
lesquels vous voulez effacer. (Maître) |
SHOW BINLOG EVENTS [ IN 'logname' ] [ FROM pos ]
[ LIMIT [offset,] rows ]
|
Affiche les événements dans le log binaire. Initialement utilisé
pour le test et le débogage dans le log binaire, mais il peut aussi
être utilisé par les clients habituels qui, pour une raison ou une
autre, ont besoin de lire le contenu du log binaire. (Maître) |
SHOW NEW MASTER FOR SLAVE WITH MASTER_LOG_FILE='logfile' AND
MASTER_LOG_POS=pos AND
MASTER_LOG_SEQ=log_seq AND MASTER_SERVER_ID=server_id
|
Cette commande est utilisée lorsque l'esclave d'un maître probablement
mort ou indisponible doit être redirigé vers un autre maître qui
fait la réplication du même maître. La commande va retourner
les nouvelles coordonnées de réplication (le nom du point de contrôle
dans le fichier de log binaire et son offset). Le résultat de la
commande peut être utilisé dans un appel à la commande
CHANGE MASTER TO
. Les utilisateurs normaux ne doivent jamais
exécuter cette commande. Elle est réservée à l'utilisation interne
par le code de réplication sans erreur. Nous risquons de changer
cette syntaxe, si vous trouvons un autre moyen plus intuitif de faire
cette opération. |
PURGE MASTER LOGS TO 'logname'
|
Disponible depuis la version 3.23.28. Efface tous les
logs de réplication qui sont listés dansle fichier d'index
de réplication, comme étant des logs déjà utilisés. Le log qui est
spécifié devient alors log courant. Exemple :
PURGE MASTER LOGS TO 'mysql-bin.010'
|
Cette commande ne fait rien et échoue avec une erreur si vous avez un
esclave actif qui est actuellement en train de lire un des fichiers de logs
que vous essayez d'effacer. Cependant, si vous avez un esclave qui dort,
et que vous effacez un des logs qu'il voudra lire plus tard, l'esclave
ne pourra pas effectuer la réplication lorsque son temps arrivera.
La commande est sûre lorsque d'autres esclaves effectue la réplication : vous
n'aurez pas à les arrêter.
Vous devez d'abord vérifier tous les esclaves, avec la commande
SHOW SLAVE STATUS
pour voir quels logs ils utilisent, pour faire
une liste des logs sur le maître avec la commande
SHOW MASTER LOGS
,
trouver le plus vieux log de tous (si tous les esclaves sont
mis à jours, cela doit être le dernier de la liste), effectuer une sauvegarde
optionnelle de tous les logs, puis supprimer les logs du serveur.
|