4.10 Réplication de MySQL
4 Administration du serveur
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
. Comment mettre en place la réplication
. Fonctionnalités de la réplication et problèmes connus
->Options de réplication dans le fichier my.cnf
. Commandes SQL liées à la réplication
. FAQ de la réplication
. Correction de problèmes courants
|
4.10.5 Options de réplication dans le fichier my.cnf
Si vos utilisez la réplication, nous vous recommandons d'utiliser
MySQL version 3.23.30 ou plus récent. Les vieilles versions fonctionneront,
mais elles présentent des bogues et manquent les nouvelles fonctionnalités.
Certaines des options qui seront présentées ici ne seront pas forcément
disponibles dans votre version de MySQL, si vous n'utilisez pas la version
la plus récente. Pour toutes les options spécifiques à la version
4.0, il y a une note qui l'indique. Sinon, si vous découvrez une option
qui vous interesse mais qui n'est pas disponible dans votre version 3.23,
et que vous en avez vraiment besoin, mettez à jour votre installation.
Notez bien que la version 4.0 est toujours en phase alpha, et que certaines
fonctionnalités ne fonctionneront peut être pas aussi bien que prévu. Si vous
voulez vraiment essayer de nouvelles fonctionnalités de la version
4.0, nous vous recommandons de le faire de façon à ce que cela ne perturbe
pas vos applications critiques.
Sur le maître et l'esclave, vous devez utiliser l'option
server-id
.
Elle doit représenter un identifiant unique de réplication. Vous devriez
choisir une valeur unique entre 1 et 2^32-1 pour chaque maître et esclave.
Example:
server-id=3
La table suivante décrit les options que vous pouvez utiliser avec
MASTER
:
|
Option
|
Description
|
|
log-bin=filename
|
Ecrit le fichier de log binaire à la position indiquée. Notez que vis
vous donner un paramètre avec une extension (par exemple,
log-bin=/mysql/logs/replication.log
), les versions jusqu'en 3.23.24
ne fonctionneront pas correctement avec la réplication, si vous utilisez
la commande
FLUSH LOGS
. Le problème a été corrigé avec la version 3.23.25.
Si vous utilisez ce type de nom de fichier de log,
FLUSH LOGS
sera ignoré sur les logs binaires. Pour nettoyer le log,
exécutez la commande
FLUSH MASTER
, et n'oubliez pas la commande
FLUSH SLAVE
sur chacun des esclaves. En version 3.23.26 et plus récent, vous devriez utiliser
RESET MASTER
et
RESET SLAVE
. |
|
log-bin-index=filename
|
Comme l'utilisateur peut exécuter une commande
FLUSH LOGS
, nous devons
savoir quel fichier de log est actuellement actif, lequels ont été déjà utilisés,
et dans quel ordre. Cette information est stockée dans le fichier d'index de log.
Par défaut, ce fichier s'appelle
`hostname`.index
. Nous n'avez pas à le
modifier.Example:
log-bin-index=db.index
|
|
sql-bin-update-same
|
Si cette option est activée, en donnant une valeur à
SQL_LOG_BIN
vous donnerez
automatiquement la même valeur à
SQL_LOG_UPDATE
et vice-versa. |
|
binlog-do-db=database_name
|
Indique au maître qu'il doit mettre les modifications dans le fichier de log binaire,
si la base courante est la base
database_name
. Toutes les autres bases
sont ignorées. Notez que vous si vous utilisez cette option, vous devez vous assurer
que vous ne faites des modifications que dans la base courante.
Example:
binlog-do-db=sales
|
|
binlog-ignore-db=database_name
|
Indique au maître que les modifications dont la base courante est
database_name
ne doivent pas être stockées dans le log binaire.
Notez que vous si vous utilisez cette option, vous devez vous assurer
que vous ne faites des modifications que dans la base courante.Example:
binlog-ignore-db=accounting
|
La table suivante décrit les options que vous pouvez utiliser avec
SLAVE
:
|
Option
|
Description
|
|
master-host=host
|
Le nom d'hôte du maître, ou l'adresse IP de réplication.
Si cette valeur n'est pas spécifiée, l'esclave ne démarrera pas. Notez que la configuration
de
master-host
sera ignorée si il existe un fichier
master.info
valide. Il
est probable qu'un nom mieux choisi pour cette option aurait été
bootstrap-master-host
, mais il est trop tard aujourd'hui.
Example:
master-host=db-master.mycompany.com
|
|
master-user=username
|
Le nom d'utilisateur que l'esclave va utiliser pour s'identifier lors de la
connexion au maître. Cet utilisateur doit avoir les droits de
FILE
. S'utilisateur
maître n'est pas configuré, l'utilisateur
test
est utilisé. La valeur dans
master.info
aura priorité, si elle peut être lue.
Example:
master-user=scott
|
|
master-password=password
|
Le mot de passe que l'esclave va utiliser automatiquement avec le maître.
Si il n'est pas configuré, le mot de passe vide sera utilisé. La valeur dans
master.info
aura priorité, si elle peut être lue.
Example:
master-password=tiger
|
|
master-port=portnumber
|
Le port sur lequel le maître écoute. Si cette valeur n'est pas configurée,
la valeur compilée de
MYSQL_PORT
est utilisée. Si vous n'avez pas
joué avec les options du script
configure
, ce devrait être le port 3306.
La valeur dans
master.info
aura priorité, si elle peut être lue.
Example:
master-port=3306
|
|
master-connect-retry=seconds
|
Le nombre de secondes que le thread esclave va attendre avant de tenter
à nouveau de se connecter au maître, dans le cas où le maître n'est plus
joignable. Par défaut, c'est 60.
Example:
master-connect-retry=60
|
|
master-ssl
|
Disponible après la version 4.0.0. Active le mode SSL pour la réplication.
Soyez prévenu que c'est une fonctionnalité très récente.
Example:
master-ssl
|
|
master-ssl-key
|
Disponible après la version 4.0.0. Le nom du fichier de clé maître SSL.
Uniquement valable si l'option
master-ssl
est active.
Example:
master-ssl-key=SSL/master-key.pem
|
|
master-ssl-cert
|
Disponible après la version 4.0.0. Le nom du fichier de certificat SSL.
Uniquement valable si l'option
master-ssl
est active.Example:
master-ssl-key=SSL/master-cert.pem
|
|
master-info-file=filename
|
La position du fichier qui enregistre la dernière opération faite avec
le maître, durant la réplication. Le fichier par défaut est
master.info
dans le dossier de données. Vous n'avez pas besoin de modifier cela.Example:
master-info-file=master.info
|
|
report-host
|
Disponible après la version 4.0.0. Le nom d'hôte ou l'adresse IP de
l'esclave, qui doit être enregistrée lors de l'identification. Cette
valeur apparaîtra dans le résultat de la commande
SHOW SLAVE HOSTS
.
Laissez la vide si vous ne souhaitez pas que l'esclave s'enregistre lui-même.
Notez qu'il n'est pas suffisant pour le maître de simplement lire l'IP de
l'esclave dans la socket de connexion. A cause du
NAT
et d'autres problèmes
de routage, cette IP peut ne pas êtra valable pour la connexion du maître sur
l'esclave.Example:
report-host=slave1.mycompany.com
|
|
report-port
|
Disponible après la version 4.0.0. Port de connexion à l'esclave indiqué
au maître durant l'enregistrement. Utilisez cette option uniquement si
l'esclave doit écouter sur un port non standard, ou si vous avez un
tunnel particulier pour le maître. En cas de doute, laissez le vide. |
|
replicate-do-table=db_name.table_name
|
Restreint la réplication à certaines tables. Pour spécifier plus d'une
table, vous pouvez utiliser cette directive plusieurs fois, une pour
chaque table. Cette option va fonctionner pour les modifications
inter-bases, contrairement à
replicate-do-db
.
Example:
replicate-do-table=some_db.some_table
|
|
replicate-ignore-table=db_name.table_name
|
Indique à l'esclave d'ignorer les commandes qui modifie les tables
spécifiées (même si d'autres tables de la même commande sont aussi modifiées).
Pour spécifier plus d'une
table, vous pouvez utiliser cette directive plusieurs fois, une pour
chaque table. Cette option va fonctionner pour les modifications
inter-bases, contrairement à
replicate-ignore-db
.
Example:
replicate-ignore-table=db_name.some_table
|
|
replicate-wild-do-table=db_name.table_name
|
Restreint la réplication à certaines tables qui vérifient le masque d'expression
régulière indiqué. Pour spécifier plus d'une
table, vous pouvez utiliser cette directive plusieurs fois, une pour
chaque table. Cette option va fonctionner pour les modifications
inter-bases.
Example:
replicate-wild-do-table=foo%.bar%
va répliquer uniquement
les modifications qui utilisent une table dont le nom de base commence par
foo
, et le nom de table commence par
bar
.
|
|
replicate-wild-ignore-table=db_name.table_name
|
Interdit la réplication à certaines tables qui vérifient le masque d'expression
régulière indiqué. Pour spécifier plus d'une
table, vous pouvez utiliser cette directive plusieurs fois, une pour
chaque table. Cette option va fonctionner pour les modifications
inter-bases.
Example:
replicate-wild-ignore-table=foo%.bar%
va ignorer la réplication
des modifications qui utilisent une table dont le nom de base commence par
foo
, et le nom de table commence par
bar
.
|
|
replicate-ignore-db=database_name
|
Restreint la réplication aux bases de données indiquées. Pour spécifier plus d'une
base, vous pouvez utiliser cette directive plusieurs fois, une pour
chaque base. Vous ne devez pas utiliser cette option si vous faites
des modifications inter-bases et que vous ne voulez pas que
ces modifications soient prises en compte.
La principale raison de ce comportement est qu'il est difficile d'utiliser
uniquemnt la ligne de commande pour savoir si une requête doit être
répliquée ou pas. Par exemple, si vous utilisez une commande d'effacement
multi-table en MySQL 4.x, qui utilise plusieurs bases. Il est aussi très
facile de vérifier la base courante, car cela ne s'applique qu'une fois au
moment de la connexion, ou d'un changement de base.
Si vous voulez que des modifications inter-bases fonctionnent, assurez
vous que vous avez la version 3.23.28 ou plus récente, et utilisez
replicate-wild-ignore-table=db_name.%
.
Example:
replicate-ignore-db=some_db
|
|
replicate-do-db=database_name
|
Restreint la réplication aux commandes dont le nom de base
courante est
database_name
. Pour spécifier plus d'une
base, vous pouvez utiliser cette directive plusieurs fois, une pour
chaque base. Notez que cette option ne va pas autoriser la réplication
de requêtes inter-bases telles que
UPDATE some_db.some_table SET foo='bar'
lorsque vous avez
sélectionné une autre base (ou qu'aucune base n'est sélectionnée).
Si vous avez besoin de faire des modifications inter-bases, assurez vous
que vous avez la version 3.23.28 ou plus récente, et utilisez
replicate-wild-do-table=db_name.%
.
Example:
replicate-do-db=some_db
|
|
log-slave-updates
|
Indique à l'esclave d'enregistrer les modifications du thread esclave
dans le log binaire. Par défaut, cette option est inactive (off).
Vous aurez besoin de cette fonctionnalité si vous installez les
esclaves en cascade. |
|
replicate-rewrite-db=from_name->to_name
|
Reporte les modifications qui ont lieu dans une base, dans une
autre.Example:
replicate-rewrite-db=master_db_name->slave_db_name
|
|
slave-skip-errors= [err_code1,err_code2,... | all]
|
Disponible depuis la version 3.23.47 et plus récent. Indique au thread
esclave de continuer la réplication si une requête génère une erreur issue
de la liste fournie. Normalement, la réplication va s'arrêter dès qu'une
erreur survient, pour que l'utilisateur puisse corriger les incohérence manuellement.
N'utilisez pas cette option si nous ne comprenez pas complètement les
raisons qui génèrent ces erreurs. Si il y n'a pas de bogues dans vos configurations
de réplication, et pas de bogues dans MySQL, vous ne devriez jamais
interrompre la réplication. Utiliser cette option à tort et à travers
va désynchroniser les esclaves et vous n'aurez aucune idée des problèmes
qui sont survenus.Pour les codes d'erreurs, vous devez utiliser les numéros d'erreurs qui
sont fournis dans le log d'erreur de l'esclave, et dans le résultat de la
commande
SHOW SLAVE STATUS
. La liste complète des
message d'erreurs sont disponibles dans le fichier source
Docs/mysqld_error.txt
.
Vous pouvez (mais ne devriez pas) aussi utiliser la valeur hautement
dangeureuse de
all
(tous), pour ignorer toutes les erreurs de
réplication, et continuer comme si de rien n'était. Inutile de vous dire
que si vous l'utilisez, nous ne pouvons rien garantir quand à l'intégrité
de vos données. Ne venez pas vous plaindre que les données de vos
esclaves sont très différentes des données du maître : vous aurez été prévenus.
Exemple :
slave-skip-errors=1062,1053
or
slave-skip-errors=all
|
|
skip-slave-start
|
Indique au serveur esclave de ne pas démarrer l'esclave au démarrage.
L'utilisateur le démarrera manuellement plus tard, avec
SLAVE START
. |
|
slave_compressed_protocol=#
|
Si cette option vaut 1, alors le protocole compressé est utilisé entre le
maître et l'esclave, si les deux le supporte. |
|
slave_net_timeout=#
|
Le nombre de secondes d'attente de données depuis le maître, avant d'abandonner
la lecture.
|
|
