Sur le maître comme sur l'esclave, vous devez utiliser l'option
server-id
pour donner un identifiant unique ID
à chaque serveur. Vous pouvez choisir un entier dans l'intervalle
de 1 à 2^32 − 1 pour chaque maître et esclave. Exemple :
server-id=3
Les options que vous pouvez utiliser sur le maître pour contrôler les logs sont décrites dans la section Section 5.9.4, « Le log binaire ».
La table suivante décrit les options que vous pouvez utiliser sur les serveurs esclaves. Vous pouvez les spécifier en ligne de commande, ou dans le fichier d'options.
Les gestionnaires de réplication gèrent les options de manière
spéciale, sans le sens où elles sont ignorées si un fichier
master.info
existe lorsque l'esclave est
lancé, et qu'il contient des valeurs pour les options. Les
options suivantes sont gérées de cette manière :
--master-host
--master-user
--master-password
--master-port
--master-connect-retry
Depuis MySQL 4.1.1, les options suivantes sont gérées de manière particulière :
--master-ssl
--master-ssl-ca
--master-ssl-capath
--master-ssl-cert
--master-ssl-cipher
--master-ssl-key
Le format du fichier master.info
de version
4.1.1 a changé pour inclure les options SSL. De plus, en version
4.1.1, le fichier inclut le nombre de lignes comme première
ligne. Si vous passez d'une ancienne version vers un serveur
4.1.1, le nouveau serveur va mettre à jour le fichier
master.info
avec le nouveau format au
démarrage. Toutefois, si vous rétrogradez en version 4.1.1, vous
devrez supprimer la première ligne avant de relancer votre vieux
serveur. Notez que dans ce cas, le serveur ancien ne pourra pas
utiliser les connexions sécurisées pour communiquer avec le
maître.
Si aucun fichier master.info
n'existe lors du
lancement de l'esclave, il utiliser les valeurs de ces options.
Cela arrivera lorsque vous lancez un serveur de réplication en
tant qu'esclave, pour la première fois, ou si vous avez utilisé
la commande RESET SLAVE
et arrêté puis
relancé le serveur.
Cependant, si master.info
existe lorsque
l'esclave démarre, il utilisera les valeurs dans le fichier et
ignorera les valeurs spécifiées en ligne de commande, ou dans le
fichier d'options master.info
.
Si vous redémarrez le serveur avec différentes options de
démarrage que les valeurs qui sont dans le
master.info
, ces nouvelles valeurs n'auront
pas d'effet, car le serveur continuera d'utiliser
master.info
. Pour utiliser différentes
valeurs, vous devez relancer le serveur après avoir supprimé
master.info
, ou, de préférence, utilise la
commande CHANGE MASTER TO
pour remettre à
zéro les valeurs durant l'exécution.
Supposez que vous spécifiez cette option dans votre fichier
my.cnf
:
[mysqld] master-host=un_hote
La première fois que vous démarrez le serveur en tant qu'esclave
de réplication, il va lire et utiliser cette option dans le
fichier my.cnf
. Le serveur va ensuite
enregistrer les valeurs courantes dans le fichier
master.info
. Au prochain démarrage du
serveur, il va lire les valeurs dans le fichier
master.info
. Si vous modifiez
my.cnf
pour spécifier un nouvel hôte, cela
n'aura pas d'effet. Vous devez utiliser la commande
CHANGE MASTER TO
.
Comme le serveur donne la priorité au fichier
master.info
sur les options de démarrage
décrites, vous pourriez ne pas souhaiter utiliser les options de
démarrage pour ces valeurs, et plutôt, les spécifier avec la
commande CHANGE MASTER TO
. Voir
Section 13.6.2.1, « CHANGE MASTER TO
».
Cet exemple illustre une utilisation plus complète des options de démarrage pour configurer un serveur esclave :
[mysqld] server-id=2 master-host=db-master.mycompany.com master-port=3306 master-user=pertinax master-password=freitag master-connect-retry=60 report-host=db-slave.mycompany.com
La liste suivante décrit les options de démarrage qui
contrôlent la réplication : De nombreuses options peuvent être
remises à zéro pendant que le serveur fonctionne, en utilisant
la commande CHANGE MASTER TO
. Sinon, des
options comme --replicate-*
peuvent être
utilisées lorsque le serveur esclave démarre. Nous envisageons
de corriger cela.
--log-slave-updates
Dit à l'esclave d'enregistrer les modifications effectuées
par son thread SQL dans son propre log binaire. Par défaut,
cette option est à Off. Pour que cette option ait un effet,
l'esclave doit être lancé avec le log binaire activé :
c'est l'option --log-bin
option.
--log-slave-updates
sert lorsque vous voulez
faire une chaîne de serveur de réplication. Par exemple :
A -> B -> C
C'est-à-dire, A sert de maître à l'esclave B, et B sert de
maître à l'esclave C. Pour que cela fonctionne, avec B qui
sert d'esclave et de maître simultanément, vous devez lancer
B avec l'option --log-slave-updates
. A et B
doivent être lancés avec le log binaire activé.
--log-warnings
Fait que l'esclave affiche plus de message sur ses activités. Par exemple, il vous alertera s'il réussi à se reconnecter après un problème de connexion, ou le démarrage de thread esclaves.
Cette option n'est pas limitée à la réplication. Elle produit des alertes sur toutes la gamme des activités du serveur.
--master-connect-retry=seconds
Le nombre de secondes qu'un esclave attend avant de tenter de
se reconnecter au maître, dans le cas où le maître et
l'esclave perdent la connexion. La valeur du fichier
master.info
a priorité, si elle est
disponible. Par défaut, elle vaut 60.
--master-host=host
Spécifie l'hôte ou l'IP du maître de réplication. Si cette
option n'est pas fournie, le thread esclave ne sera pas
lancé. La valeur inscrite dans le fichier
master.info
a priorité, si elle peut
être lue. Un meilleur nom pour cette option aurait été
--bootstrap-master-host
, mais il est trop
tard.
--master-info-file=file_name
Le nom à utiliser pour le fichier dans lequel l'esclave
stocke les informations sur le maître. Par défaut, c'est
mysql.info
, dans le dossier de données.
--master-password=password
Le mot de passe que l'esclave utilise lors de l'identification
auprès du maître. Si le mot de passe n'est pas configuré,
la chaîne vide est utilisée. La valeur inscrite dans le
fichier master.info
a priorité, si elle
peut être lue.
--master-port=port_number
Le port du maître que l'esclave utilise lors de
l'identification auprès du maître. Si le port n'est pas
configuré, la valeur de la variable
MYSQL_PORT
est utilisée. Si vous n'y avez
pas touché lors de la compilation avec
configure
, ce doit être 3306. La valeur
inscrite dans le fichier master.info
a
priorité, si elle peut être lue.
--master-ssl
,
--master-ssl-ca=file_name
,
--master-ssl-capath=directory_name
,
--master-ssl-cert=file_name
,
--master-ssl-cipher=cipher_list
,
--master-ssl-key=file_name
Ces options servent à configurer la réplication chiffrée,
lorsque la connexion avec le maître utilise SSL. Leurs
significations respectives est la même que les options
--ssl
, --ssl-ca
,
--ssl-capath
, --ssl-cert
,
--ssl-cipher
, --ssl-key
décrites dans Section 5.6.7.5, « Options SSL en ligne de commande ».
Ces options sont disponibles depuis MySQL 4.1.1.
--master-user=username
Le nom d'utilisateur que l'esclave utilise lors de
l'identification auprès du maître. Le compte doit avoir les
droits de REPLICATION SLAVE
(avant MySQL
4.0.2, il devait avoir les droits de FILE
).
Si l'utilisateur maître n'est pas configuré, l'utilisateur
test
est utilisé. La valeur inscrite dans
le fichier master.info
a priorité, si
elle peut être lue. Si l'utilisateur maître n'est pas
configuré, la valeur test
est utilisée.
--max-relay-log-size=#
Pour faire la rotation automatique des logs. See
Section 13.5.3.18, « Syntaxe de SHOW VARIABLES
».
Cette option est disponible depuis MySQL 4.0.14.
--read-only
Cette option fait que le serveur n'autorise aucune
modification, hormis celles du thread esclave, ou celle des
utilisateurs ayant les droits de SUPER
.
Cela peut être utile si vous voulez vous assurer que
l'esclave ne re¸oit aucune modification des clients.
Cette option est disponible depuis MySQL 4.0.14.
--relay-log=filename
Pour spécifier la localisation et le nom qui doivent être
utilisés pour les logs de relais. Les noms par défaut sont
de la forme host_name-relay-bin.nnn
, où
host_name
est le nom du serveur esclave et
nnn
indique le numéro de séquence du log
de relais. Vous pouvez utiliser ces options pour avoir des
noms de fichier de log de relais indépendants du nom d'hôte,
ou si vos logs ont tendances à devenir très grands (et que
vous ne voulez pas réduire la valeur de
max_relay_log_size
) et que vous devez les
mettre dans un autre dossier, ou simplement pour accélérer
la vitesse d'équilibrage entre deux disques.
--relay-log-index=filename
Pour spécifier la localisation et le nom qui doivent être
utilisés pour le fichier d'index du log de relais. Le nom par
défaut est host_name-relay-bin.index
, où
host_name
est le nom du serveur esclave.
--relay-log-info-file=filename
Pour donner au fichier relay-log.info
un
autre nom ou pour le placer dans un autre dossier. Le nom par
défaut est relay-log.info
dans le
dossier de données.
--relay-log-purge={0|1}
Active ou désactive la vidange automatique des logs de
relais, dès qu'ils ne sont plus utiles. C'est une variable
globale, qui peut être dynamiquement modifiée avec
SET GLOBAL RELAY_LOG_PURGE=0|1
. Sa valeur
par défaut est 1.
Cette option est disponible depuis MySQL 4.1.1.
--relay-log-space-limit=#
Limite la taille maximale de tous les fichiers de logs de
relais sur l'esclave (une valeur de 0 signifie ``sans
limite''). C'est utile lorsque vous avez un petit disque sur
votre machine esclave. Lorsque la limite est atteinte, le
thread d'I/O fait une pause : il ne lit plus rien dans le log
binaire du maître, jusqu'à ce que le thread SQL ait avancé,
et effacé des fichiers de logs. Notez que cette limite n,est
pas absolue : il se peut que le thread SQL requiert plusieurs
événements pour être capable d'effacer les fichiers de log
de relais. Dans ce cas, le thread d'I/O va dépasser la
limite, jusqu'à ce que l'effacement devienne possible. Sans
cela, des blocages pourraient survenir, ce qui arrivait sur
les versions antérieures à la 4.0.13). Avec
--relay-log-space-limit
, il ne faut pas
utiliser de valeur inférieure à deux fois la taille de
--max-relay-log-size
(ou
--max-binlog-size
si
--max-relay-log-size
vaut 0) car dans ce cas,
il y a des chances que le thread d'I/O attende de l'espace
libre par ce que --relay-log-space-limit
est
dépassée, mais que le thread SQL n'ait pas de logs à
effacer, et ne peut donc libérer le thread d'I/O, for¸ant le
thread d'I/O à ignorer temporairement
--relay-log-space-limit
.
--replicate-do-db=db_name
Indique à l'esclave qu'il doit restreindre la réplication
aux commandes qui utilisent la base de données
db_name
par défaut (c'est à dire celle
qui est sélectionnée avec la commande
USE
). Pour spécifier plusieurs base de
données, utilisez cette option aussi souvent que nécessaire.
Note que cela ne va pas autoriser les commandes multi-bases,
comme UPDATE some_db.some_table SET
foo='bar'
si une base de données différente ou
qu'aucune base de données n'est sélectionnée. Si vous avez
besoin que les commandes multi-bases fonctionnent, assurez
vous que vous avez MySQL 3.23.28 ou plus récent, et utilisez
--replicate-wild-do-table=db_name.%
. Lisez
les notes qui suivent cette liste d'options.
Un exemple qui pourrait ne pas fonctionner comme vous
l'attendez : si l'esclave est lancé avec
--replicate-do-db=sales
et que vous émettez
une commande sur le maître, la commande
UPDATE
suivante ne sera pas répliquée :
USE prices; UPDATE sales.january SET amount=amount+1000;
Si vous avez besoin de répliquer des commandes multi-bases,
utilisez l'option
--replicate-wild-do-table=db_name.%
à la
place.
La raison principale de ce comportement ``vérifie juste la
base par défaut'' est qu'il est difficile de savoir si une
requête doit être répliquée, uniquement à partir de la
requête. Par exemple, si vous utilisez une requête
multi-tables DELETE
oui multi-tables
UPDATE
, qui a des conséquences dans
d'autres bases. La vérification de la base courante est aussi
très rapide.
--replicate-do-table=db_name.table_name
Dit à l'esclave qu'il doit restreindre la réplication à une
table spécifiée. Pour spécifier plusieurs tables, il faut
utiliser cette directive plusieurs fois, une fois par table.
Cela fonctionnera pour les mises à jours multi-bases, au
contraire de --replicate-do-db
. Lisez les
notes qui suivent cette liste d'options.
--replicate-ignore-db=db_name
Indique à l'esclave qu'il doit ne doit pas assurer la
réplication avec les commandes qui utilisent la base de
données db_name
par défaut (c'est à dire
celle qui est sélectionnée avec la commande
USE
). Pour spécifier plusieurs base de
données, utilisez cette option aussi souvent que nécessaire.
Note que cela ne va pas autoriser les commandes multi-bases,
comme UPDATE some_db.some_table SET
foo='bar'
si une base de données différente ou
qu'aucune base de données n'est sélectionnée. Si vous avez
besoin que les commandes multi-bases fonctionnent, assurez
vous que vous avez MySQL 3.23.28 ou plus récent, et utilisez
--replicate-wild-do-table=db_name.%
. Lisez
les notes qui suivent cette liste d'options.
Un exemple qui pourrait ne pas fonctionner comme vous
l'attendez : si l'esclave est lancé avec
--replicate-ignore-db=sales
et que vous
émettez une commande sur le maître, la commande
UPDATE
suivante ne sera pas répliquée :
USE prices; UPDATE sales.january SET amount=amount+1000;
Si vous avez besoin de répliquer des commandes multi-bases,
utilisez l'option
--replicate-wild-ignore-table=db_name.%
à la
place.
--replicate-ignore-table=db_name.table_name
Dit à l'esclave qu'il ne doit pas répliquer les commandes
qui touche à la table spécifiée, même si d'autres tables
sont modifiées dans la même commande. Pour spécifier
plusieurs tables, il faut utiliser cette directive plusieurs
fois, une fois par table. Cela fonctionnera pour les mises à
jours multi-bases, au contraire de
--replicate-ignore-db
. Lisez les notes qui
suivent cette liste d'options.
--replicate-wild-do-table=db_name.table_name
Dit à l'esclave qu'il doit restreindre la réplication aux
tables dont le nom vérifie le masque spécifié. Le masque
peut contenir les caractères
‘%
’ et
‘_
’, qui ont la même
signification que dans les expressions régulières de la
clause LIKE
. Pour spécifier plusieurs
tables, il faut utiliser cette directive plusieurs fois, une
fois par table. Cela fonctionnera pour les mises à jours
multi-bases, au contraire de
--replicate-do-db
. Lisez les notes qui
suivent cette liste d'options.
Exemple :
--replicate-wild-do-table=foo%.bar%
va
répliquer les mises à jour qui surviennent sur toutes les
tables de toutes les bases qui commencent par
foo
, et dont le nom de table commence par
bar
.
Notez que si vous utilisez
--replicate-wild-do-table=foo%.%
, alors la
règle sera propagée à CREATE DATABASE
et
DROP DATABASE
, c'est à dire que ces deux
commandes seront répliquées si le nom de la base correspond
au masque (foo%
ici) (la magie est ici
déclenchée par %
comme masque de table.).
Si le masque de noms de tables est %
, il
accepte tous les noms de tables et les options s'appliquent
aux commandes de niveau base de données (comme
CREATE DATABASE
, DROP
DATABASE
et ALTER DATABASE
). Par
exemple, si vous utilisez
--replicate-wild-do-table=foo%.%
, les
commandes de niveau de base de données seront répliquées si
le nom de la base de données est accepté par le masque
foo%
.
Si vous voulez faire la réplication des tables du type
ma_petite%base
(ceci est le nom exact de la
base), mais que vous ne voulez pas répliquer la base
ma1petiteAABCbase
, vous devez protéger les
caractères ‘_
’ et
‘%
’ : il faut utiliser une
syntaxe équivalent à :
replicate-wild-do-table=my\_own\%db
. Et si
vous spécifiez cette option en ligne de commande, suivant
votre système, vous devrez protéger aussi le caractère
\
(par exemple, en Shell
bash
, vous devez émettre une option sous
la forme
--replicate-wild-do-table=my\\_own\\%db
).
--replicate-wild-ignore-table=db_name.table_name
Dit à l'esclave qu'il ne doit pas répliquer les tables dont
le nom vérifie le masque spécifié. Pour spécifier
plusieurs tables, il faut utiliser cette directive plusieurs
fois, une fois par table. Cela fonctionnera pour les mises à
jours multi-bases, au contraire de
--replicate-do-db
. Lisez les notes qui
suivent cette liste d'options.
Exemple :
--replicate-wild-ignore-table=foo%.bar%
n'autorisera pas de modifications dans les tables des bases
dont le nom commence par foo
et dont le nom
de table commence par bar
.
Pour des informations sur le fonctionnement du filtre, voyez
l'option --replicate-wild-ignore-table
. La
règle pour inclure des caractères littéraux est la même
que pour --replicate-wild-ignore-table
.
--replicate-rewrite-db=from_name->to_name
Dit à l'esclave de remplacer la base courante (celle qui est
sélectionnée avec USE
) par
to_name
si elle était
from_name
sur le maître. Seules les
commandes impliquant des tables peuvent être affectées.
(CREATE DATABASE
, DROP
DATABASE
ne le seront pas), et uniquement si
from_name
était la base de données
courante sur le maître. Cela ne fonctionnera pas pour les
commandes multi-bases de données. Notez que la traduction est
faite avant que les règles --replicate-*
ne
soient testées.
Si vous utilisez cette option en ligne de commande, et que
vous utilisez le caractère
‘>
’, qui peut être spécial
pour votre interpréteur Shell, protégez-le comme ceci :
shell> mysqld --replicate-rewrite-db="olddb->newdb"
--replicate-same-server-id
A utiliser sur les serveurs esclaves. Généralement, vous
pouvez spécifier la valeur 0 pour éviter les réplications
infinies. Si cette option vaut 1, l'esclave n'ignorera pas les
événements de réplication, même s'ils portent son propre
numéro d'identification. Normalement, cela n'est utile que
pour de très rares configurations. Vous ne pouvez pas mettre
cette option à 1 si --log-slave-updates
est
utilisé. Faîtes attention en démarrant MySQL 4.1, par
défaut le thread d'E/S n'écrit pas les événements dans le
log de relais s'ils portent l'identification du serveur
esclave (c'est une optimisation pour économiser l'espace
disque, par rapport à la version 4.0). Si vous voulez
utiliser --replicate-same-server-id
avec les
versions 4.1, assurez vous de démarrer l'esclave avec cette
option avant que l'esclave ne lise ses propres événements et
qu'il les fasse exécuter au thread SQL.
--report-host=host
Le nom d'hôte ou l'adresse IP de l'esclave, qui doit être
indiquée lors de l'enregistrement de l'esclave chez le
maître. Cela apparaîtra dans l'affichage de la commande
SHOW SLAVE HOSTS
. Laissez cette option vide
pour que l'esclave ne s'enregistre pas sur le maître. Notez
qu'il n'est pas suffisant pour que le maître lise l'adresse
IP de l'esclave sur la socket, une fois que l'esclave se
connecte. à cause du NAT
et des problèmes
de routages, cette IP peut être invalide pour se connecter au
maître depuis l'hôte ou les autres esclaves.
Cette option est disponible depuis MySQL 4.0.0.
--report-port=port_number
Le port de connexion indiqué par l'esclave lors de son enregistrement chez le maître. Configurez cette option si l'esclave utilise un port autre que le port par défaut, ou si vous avez installé un tunnel spécial pour le maître ou les autres esclaves. Dans le doute, laissez cette option vide.
Cette option est disponible depuis MySQL 4.0.0.
--skip-slave-start
Dit à l'esclave de ne pas lancer les threads esclaves au
démarrage du serveur L'utilisateur pourra les lancer
manuellement, avec START SLAVE
.
--slave_compressed_protocol=#
Si cette option vaut 1, alors le protocole client/serveur compressé sera utilisé, si l'esclave et le maître le supportent.
--slave-load-tmpdir=filename
Cette option vaut par défaut la variable
tmpdir
. Lorsque le thread SQL répliquer
des commandes LOAD DATA INFILE
, il extrait
les fichiers à charger du log de relais dans un fichier
temporaire, puis charge ce fichier dans la table. Si le
fichier chargé sur le maître est immense, le fichier
temporaire sera aussi grand. Il faudra donc dire à l'esclave
que placer ces fichiers temporaires sur un grand disque, qui
sera différent de tmpdir
: utilisez cette
option. Dans ce cas, vous pouvez aussi utiliser l'option
--relay-log
, car les fichiers de log de
relais seront aussi grands.
--slave-load-tmpdir
doit pointer sur un
système de fichier basés sur un disque, et non pas sur une
portion de mémoire : l'esclave doit pouvoir accéder à ce
fichier pour répliquer la commande LOAD DATA
INFILE
, même après un redémarrage.
--slave-net-timeout=#
Le nombre de secondes à attendre des données du maître,
avant d'annuler la lecture en considérant que la connexion
est rompue, et de tenter de se reconnecter. La première
reconnexion intervient immédiatement après l'expiration du
délai. L'intervalle entre deux tentatives de connexion est
contrôlé par l'option
--master-connect-retry
.
--slave-skip-errors= [err_code1,err_code2,... |
all]
Normalement, la réplication s'arrête lorsqu'une erreur survient, ce qui vous donne l'opportunité de résoudre les incohérences manuellement. Cette option Indique au thread SQL les erreurs qu'il doit ignorer durant la réplication.
N'utilisez pas cette option si vous ne connaissez pas la raison des erreurs que vous rencontrez. S'il n'y a pas de bugs dans votre réplication, et qu'il n'y a pas de bug dans MySQL, vous ne devriez pas rencontrer d'erreurs, ni utiliser cette option. L'utilisation abusive de cette option conduit irrémédiablement l'esclave à être désynchronisé avec le maître sans que vous ne sachiez d'où vient l'erreur.
Pour les codes d'erreur, il faut utiliser les numéros
d'erreurs fournis par l'esclave dans le log d'erreur, et dans
le résultat de SHOW SLAVE STATUS
. La liste
complète des messages d'erreurs est disponible dans la
distribution source, dans le fichier
Docs/mysqld_error.txt
. Les codes d'erreur
du serveur sont aussi disponibles sur
Chapitre 26, Gestion des erreurs avec MySQL.
Vous pouvez (mais ne devez pas) utiliser la valeur très
déconseillée de all
, qui va ignorer tous
les messages d'erreur, et continuer à touiller les données
sans se préoccuper de cohérence. Inutile d'insister sur le
fait que l'intégrité de vos données n'est plus du tout
garantie. Ne vous plaignez pas si les données de votre
esclave ne ressemblent même pas du tout à celle de votre
maître : vous aurez été prévenu.
Exemples :
--slave-skip-errors=1062,1053 --slave-skip-errors=all
Voici l'ordre d'étude des règles
r--eplicate-*
, pour décider si une requête
doit être exécutée par l'esclave ou ignorée :
Existe-t-il des règles --replicate-do-db
ou
--replicate-ignore-db
?
Oui : les tester pour --binlog-do-db
et
--binlog-ignore-db
(see
Section 5.9.4, « Le log binaire »). Quel est le résultat?
ignorer la requête : ignore la requête et quitte.
exécute la requête : n'exécute pas la requête immédiatement, reporte la décision, et passe à l'étape d'après.
Non : passe à l'étape d'après.
Y-t-il des règles --replicate-*-table
?
Non : exécute la requête et quitte.
Oui : passe à l'étape d'après. Seules les tables qui
doivent être modifiées seront utilisées dans les
règles : (INSERT INTO sales SELECT * from
prices
: seule sales
sera
utilisée pour évaluer les règles. Si plusieurs tables
doivent être modifiées (modifications multi-tables), la
première table (qui correspond à un ``do'' ou
``ignore'') gagne. C'est à dire que la première table
est utilisée dans les règles de comparaison, et si
aucune décision ne peut être prise, la seconde table est
utilisée...
Y a-t-il des règles --replicate-do-table
?
Oui : Est-ce qu'une table entre dans cette liste?
Oui : exécute la requête et quitte.
Non : passe à l'étape d'après.
Non : passe à l'étape d'après.
Y a-t-il des règles
--replicate-ignore-table
?
Oui : Est-ce qu'une table entre dans cette liste?
Oui : ignore la requête et quitte.
Non : passe à l'étape d'après.
Non : passe à l'étape d'après.
Y a-t-il des règles
--replicate-wild-do-table
?
Oui : Est-ce qu'une table entre dans cette liste?
Oui : exécute la requête et quitte.
Non : passe à l'étape d'après.
Non : passe à l'étape d'après.
Y a-t-il des règles
--replicate-wild-ignore-table
?
Oui : Est-ce qu'une table entre dans cette liste?
Oui : ignore la requête et quitte.
Non : passe à l'étape d'après.
Non : passe à l'étape d'après.
Aucune règle n'a fonctionné avec
--replicate-*-table
. Y a-t-il d'autres tables
à tester?
Oui : boucle.
Non : Nous avons testé toutes les tables à mettre à
jour, et nous n'avons pas trouvé de règle les
concernant. Y a-t-il des règles
--replicate-do-table
ou
--replicate-wild-do-table
?
Oui : ignore la requête et quitte.
Non : exécute la requête et quitte.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.