6 Réplication de MySQL
Manuel de Référence MySQL 4.1 : Version Française
. Introduction à la réplication . Présentation de l'implémentation de la réplication . Détails d'implémentation de la réplication ->Comment mettre en place la réplication . Compatibilité de la réplication entre les versions de MySQL . Fonctionnalités de la réplication et problèmes connus . Options de démarrage de la réplication . FAQ de la réplication . Correction de problèmes courants . Rapporter des bugs de réplication
|
6.4 Comment mettre en place la réplication
Voici les instructions pour mettre en place la réplication sur votre
serveur MySQL. Nous supposons que vous voulez répliquer toutes vos bases, et que
vous ne l'avez jamais configuré auparavant. Vous aurez besoin d'éteindre
brièvement le serveur principal pour suivre toutes les instructions.
La procédure est écrite pour configurer un esclave seul, mais elle peut être
répétée pour configurer plusieurs esclaves.
Si cette méthode n'est pas la plus simple pour configurer un esclave,
ce n'est pas la seule. Par exemple, si vous avez déjà une sauvegarde des
données du maître, et que le maître a déjà un identifiant de serveur,
et le log binaire activé, vous pouvez configurer l'esclave sans éteindre
le serveur et sans bloquer les mises à jours. Pour plus de détails, voyez
FAQ de la réplication .
Si vous voulez administrer une architecture de réplication MySQL, nous vous
suggérons de commencer par étudier, tester et expérimenter toutes les commandes
mentionnées dans les chapitres Commandes SQL pour contrôler les maîtres et Commandes SQL pour contrôler les esclaves .
Vous devriez aussi vous familiariser
avec les options de démarrage décrites dans la section Options de réplication .
- Assurez vous que vous avez une version récente de MySQL installée comme
maître et comme esclave. Assurez vous que ces versions sont compatibles entre
elles, conformément à la table présentée dans la section Mettre à jour une architecture de réplication .
Ne nous rapportez pas de bugs tant que vous n'avez pas vérifié que le problème
persiste dans la dernière version de MySQL.
- Créez un utilisateur MySQL spécial pour la réplication sur le maître, avec
les droits de
FILE
(dans les versions plus anciennes que la
versions 4.0.2) ou le droit de
REPLICATION SLAVE
pour les nouvelles
versions. Vous devez aussi lui donner les droits de connexion depuis tous les
esclaves. Si l'utilisateur ne fait que de la réplication (ce qui est recommandé),
vous n'avez pas à lui donner d'autres droits.
Le nom d'hôte du compte doit être tel que chaque serveur esclave peut l'utiliser
pour se connecter au maître.
Par exemple, pour créer un utilisateur appelé
repl
qui peut accéder au maître,
vous pourriez utiliser une commande comme :
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%' IDENTIFIED BY '<password>';
|
Pour les versions de MySQL antérieure à la 4.0.2, utilisez cette commande :
mysql> GRANT FILE ON *.* TO repl@'%' IDENTIFIED BY '<password>';
|
Si vous envisagez d'utiliser
LOAD TABLE FROM MASTER
ou
LOAD DATA FROM MASTER
sur l'esclave, vous devez donner les droits
supplémentaires suivants :
-
Donnez le droit de
SUPER
et
RELOAD
.
-
Donnez le droit de
SELECT
pour toutes les tables que vous voulez
charger. Toutes les tables maîtres dans lesquelles l'esclave ne
pourra pas utiliser
SELECT
seront ignorées par
LOAD DATA FROM MASTER
.
- Si vous utiliez des tables MyISAM, déchargez toutes les tables et blocs
en utilisant la commande
FLUSH TABLES WITH READ LOCK
.
mysql> FLUSH TABLES WITH READ LOCK;
|
puis faire une sauvegarde des données de votre maître.Le plus simple pour cela (sous Unix) et d'utiliser la commande
tar
pour produire une archive de votre dossier de données total. Le dossier
de données dépend de votre installation.
shell> tar -cvf /tmp/mysql-snapshot.tar .
|
Si vous voulez que vos archives incluent seulement une base de données
appelée
cette_base
, utilisez cette commande :
shell> tar -cvf /tmp/mysql-snapshot.tar ./cette_base
|
Puis copiez le fichier d'archive dans le dossier
/tmp
sur le serveur
esclave. Sur cette machine, placez vous dans le dossier de données du serveur
et décompressez l'archive locale avvec cette commande :
shell> tar -xvf /tmp/mysql-snapshot.tar
|
Il n'est pas besoin de répliquer la base
mysql
. Si c'est le cas, vous pouvez
l'exclure de votre archive. Vous n'avez pas besoin d'inclure les fichiers de log
dans l'archive, ou les fichiers
master.info
ou
relay-log.info
.Lorsque le verrou de lecture a été posé par
FLUSH TABLES WITH READ LOCK
et est en action,
lisez les valeurs courantes du fichie de log et de son offset sur le maître :
mysql > SHOW MASTER STATUS; +---------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +---------------+----------+--------------+------------------+ | mysql-bin.003 | 73 | test,bar | foo,manual,mysql | +---------------+----------+--------------+------------------+ 1 row in set (0.06 sec)
|
La colonne
File
montre le nom du fichier de log, et la colonne
Position
affiche l'offset. Dans l'exemple ci-dessus, le nom du fichier
de log est
mysql-bin.003
et son offset est 73. Notez ces valeurs. Vous en
aurez besoin pour configurer l'esclave.Une fois que vous avez pris une sauvegarde et enregistré le nom de fichier,
et son offset, vous pouvez réactiver l'activité sur votre maître :
Si vous utilisez des tables
InnoDB
, l'outil idéal est
InnoDB
Hot Backup,
qui est disponible pour ceux qui achètent des licences commerciales MySQL,
du support ou l'outil lui-même. Il fait un sauvegarde cohérente du maître,
enregistre le nom du fichier de log binaire et son offset,
pour que cette archive soit directement utilisée par l'esclave plus tard.
Pour plus d'informations sur cet outil, voyez
http://www.innodb.com/order.php .Sans
Hot Backup
, le mieux pour faire une sauvegarde rapide d'une base
InnoDB
est d'arrêter le serveur, puis de copier les fichiers de données
InnoDB
, leurs logs, et leur fichier de définition (
.frm
). Pour enregistrer
le fichier de log courant et son offset, vous devez utiliser les commandes suivantes
lors de l'extinction du serveur :
mysql> FLUSH TABLES WITH READ LOCK; mysql> SHOW MASTER STATUS;
|
Et ensuite, enregistrer le nom du fichier et son offset, lu dans le résultat
de la commande
SHOW MASTER STATUS
présentée précédemment.
Une fois que vous
avez ces informations, éteignez le serveur
sans déverrouiller
les tables,
pour vous assurer qu'il va bien s'arrêter dans l'état que vous avez noté :
shell> mysqladmin -uroot shutdown
|
Une alternative, valable pour les deux types de tables MyISAM et
InnoDB
,
est de prendre un export SQL du maître, au lieu d'une copie binaire.
Pour cela, vous pouvez utiliser l'utilitaire
mysqldump --master-data
sur votre maître, puis exécuter les commandes SQL sur votre esclave. Toutefois,
c'est plus lent que de faire une copie binaire.
Si le maître fonctionnait sans l'option
--log-bin
, le nom du fichier
de log et l'offset seront vides, lorsqu'ils sont demandé à
SHOW MASTER STATUS
et
mysqldump
sera vide aussi. Dans ce cas,
utilisez la chaîne vide (
''
)comme nom de fichier de log, et la valeur
4 comme offset.
- Dans le fichier
my.cnf
du maître, ajoutez les options
log-bin
et
server-id=unique number
, où
master_id
doit être un entier positif
entre 1 et 2^32 -{} 1, à la section
[mysqld]
et redémarrez le serveur.
Il est très important que l'identifiant des esclaves soient différents de celui
du maître. Pensez à
server-id
comme à une valeur
comparable à une adresse IP : elle identifie de manière unique
un serveur dans la communauté des réplicateurs.
[mysqld] log-bin server-id=1
|
Si ces options ne sont pas présentes, ajoutez-les, et redémarrez le serveur.
- Arrêtez le serveur qui va servir d'esclave, et ajoutez les lignes suivantes
dans son fichier
my.cnf
:
[mysqld] server-id=slave_id
|
La valeur de
slave_id
, comme la valeur de
master_id
, doit être
un entier, entre 1 et 2^32 -{} 1. De plus, il est très important que l'identifiant
de l'esclave soit différent de celui du maître. Par exemple :
Si vous configurez plusieurs esclaves, chacun d'entre eux doit avoir
une valeur
server-id
distincte de celle du maître et des autres
esclaves. Pensez aux
server-id
comme étant des adresses IP :
ces identifiants repèrent de manière unique un esclave dans la
communauté de réplication.
Si vous ne spécifiez pas de valeur pour
server-id
, il prendra la valeur
de 1 si vous n'avez pas défini de valeur pour
master-host
, sinon,
il prendra la valeur de 2. Notez que dans le cas où vous omettez
server-id
, un maître refusera laconnexion à tous les esclaves.
Par conséquent, omettre
server-id
est uniquement valable pour
des opérations de sauvegarde avec log binaire.
- Copiez la sauvegarde des données dans vos esclaves. Assurez vous que les
droits sur ces données sont corrects. L'utilisateur qui fait fonctionner
MySQL doit avoir les droits d'écriture et de lecture sur ces fichiers,
tout comme le maître l'avait.
Si vous avez fait une sauvegarde avec
mysqldump
, lancez d'abord les
esclaves (voir prochaine étape).
- Redémarrez les esclaves. S'il était déjà configuré pour
la réplication, lancez l'esclave avec l'option
--skip-slave-start
.
Vous pouvez uassi lancer l'esclave avec l'option
--log-warnings
.
De cette manière, vous aurez plus de détails sur les problèmes que
l'esclave rencontrera (problèmes réseau, d'identification, etc.)
- Si vous avez fait une sauvegarde du maître avec l'utilitaire
mysqldump
,
chargez l'export avec la commande suivante :
shell> mysql -u root -p < dump_file.sql
|
- Exécutez la commande sur l'esclave, en remplaçant les valeurs entre
crochets
<>
par les valeurs que vous aviez lu sur le maître,
ou qui sont valables pour votre système :
mysql> CHANGE MASTER TO -> MASTER_HOST='<master host name>', -> MASTER_USER='<replication user name>', -> MASTER_PASSWORD='<replication password>', -> MASTER_LOG_FILE='<recorded log file name>', -> MASTER_LOG_POS=<recorded log offset>;
|
La table suivante vous donne les tailles maximales de ces variables :
MASTER_HOST
|
60
|
MASTER_USER
|
16
|
MASTER_PASSWORD
|
32
|
MASTER_LOG_FILE
|
255
|
- Lancez les threads esclaves.
Après avoir suivi les instructions ci-dessus, les esclaves doivent se
connecter au maître, et rattraper les modifications qui ont eu lieu depuis
la sauvegarde des données.
Si vous avez oublié de spécifier un
server-id
pour un esclave, vous
allez obtenir l'erreur suivante dans le fichier d'erreur :
Warning: one should set server_id to a non-0 value if master_host is set. The server will not act as a slave.
|
Si vous avez oublié de le faire pour le maître, les esclaves ne pourront
pas se connecter avec le maître.Si un esclave n'est pas capable de faire la réplication pour une raison
quelconque, vous allez trouvez le message d'erreur dans le fichier de log
d'erreurs de l'esclave.
Une fois qu'un esclave a activé la réplication, vous trouverez
deux fichiers dans son dossier de données :
master.info
et
relay-log.info
.
L'esclave utilise ces deux fichiers pour savoir où il en est des logs du maître.
Ne supprimer pas et n'éditez pas
ces fichiers, à moins que vous
ne sachiez bien ce que vous faites. Même dans ce cas, il est préférable
d'utiliser la commande
CHANGE MASTER TO
.
NOTE
: le contenu du fichier
master.info
est priorité par rapport
a certaines versions spécifiées en ligne de commande, ou dans le fichier
my.cnf
. Voyez Options de réplication pour plus de détails.
Une fois que vous avez une sauvegarde, vous pouvez l'utiliser pour configurer
d'autres esclaves, en suivant la procédure concernant l'esclave, ci-dessus. Vous
n'aurez pas besoin d'une autre sauvegarde du maître.
|