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.

