6.8 Options de démarrage de la réplication

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

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.

• --master-host
• --master-user
• --master-password
• --master-port
• --master-connect-retry

• --master-ssl
• --master-ssl-ca
• --master-ssl-capath
• --master-ssl-cert
• --master-ssl-cipher
• --master-ssl-key

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.

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.

[mysqld]
master-host=un_hote

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

--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 Options de ligne de commande pour SSL .

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. 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 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

• Existe-t-il des règles --replicate-do-db ou --replicate-ignore-db ?
  • Oui : les tester pour --binlog-do-db et --binlog-ignore-db ( Le log binaire des mises à jour ). 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.