Par défaut, les logs de relais sont nommés en utilisant des noms de la forme host_name-relay-bin.nnn, où host_name est le nom de l'hôte serveur esclave, et nnn est un numéro de séquence. Les fichiers de log de relais successifs sont créés en utilisant une séquence de nombre commen¸ant à 001. L'esclave garder la trace des logs avec un fichier d'index. Le nom du fichier d'index des logs de relais est host_name-relay-bin.index. Par défaut, ces fichiers sont créés dans le dossier de données de l'esclave. Les noms par défaut peuvent être remplacés grâce aux options --relay-log et --relay-log-index du serveur. See Section 6.8, « Options de démarrage de la réplication ».

Les logs de relais ont le même format que les logs binaires, et ils peuvent être lus avec mysqlbinlog. Un log de relais est automatiquement effacé par le thread SQL aussitôt qu'il n'en a plus besoin : c'est à dire aussitôt qu'il en a exécuté les commandes. Il n'y a pas de commande pour effacer les logs de relais, car le thread SQL se charge de le faire. Toutefois, depuis MySQL 4.0.14, la commande FLUSH LOGS effectue la rotation des logs de relais, qui influence leur effacement par le thread SQL.

Un nouveau log de relais est créé dans les conditions suivantes :

Un serveur de réplication esclave crée deux autres petits fichiers dans le dossier de données. Ces fichiers sont appelés master.info et relay-log.info par défaut. Ils contiennent des informations comme celles affichées par la commande SHOW SLAVE STATUS (see Section 13.6.2, « Commandes SQL de contrôle des esclaves de réplication » pour une description de cette commande). En tant que fichier disques, ils survivent à l'extinction de l'esclave. Au prochain démarrage de l'esclave, ce dernier peut lire ces fichiers pour savoir où il en était du traitement des événements du maître et de leur lecture.

Le fichier master.info est modifié par le thread d'I/O. Avant la version 4.1, la correspondance entre les lignes du fichier et les colonnes affichées par SHOW SLAVE STATUS est la suivante :

Depuis MySQL 4.1, le fichier inclus un compteur de ligne et des informations sur les options SSL :

Le fichier relay-log.info est modifié par le thread SQL. La correspondance entre les lignes du fichier et les colonnes affichées par SHOW SLAVE STATUS est la suivante :

Lorsque vous sauvegardez les données de votre esclave, vous devriez aussi sauver ces deux fichiers, ainsi que les logs de relais. Ils ont nécessaires pour reprendre la réplication après une restauration de la base. Si vous perdez les logs de relais mais avez encore le fichier relay-log.info, vous pouvez l'étudier pour déterminer ce que le thread SQL a traité des logs binaires du maître. Puis, vous pouvez utiliser CHANGE MASTER TO avec les options MASTER_RELAY_LOG et MASTER_RELAY_POS pour dire au thread d'I/O de relire les logs depuis ce point. Cela impose que ces logs sont toujours disponibles sur le serveur.

Si votre esclave doit répliquer une commande LOAD DATA INFILE, vous devriez aussi sauver les fichiers SQL_LOAD-* qui existent dans le dossier que l'esclave utilise à cette fin. L'esclave aura besoin de ces fichiers pour reprendre la réplication des commandes LOAD DATA INFILE. Le chemin du dossier est spécifié avec l'option --slave-load-tmpdir. Sa valeur par défaut est tmpdir.