Le log binaire a remplacé l'ancien log de modifications, qui ne sera plus disponible à partir de MySQL version 5.0. Le log binaire contient toutes les informations du log de modifications, dans un format plus efficace, et compatible avec les transactions.

Le log binaire, comme le log de modifications, contient toutes les requêtes qui modifient les données. Ainsi, une commande UPDATE ou DELETE avec une clause WHERE qui ne trouve aucune ligne ne sera pas écrite dans le log. Les commandes UPDATE qui donnent à une colonne sa valeur courante sont même évitées.

Le log binaire contient aussi des informations sur le temps d'exécution de la requête dans la base. Il ne contient que des commandes qui modifient des données. Si vous voulez avoir toutes les commandes (par exemple, si vous identifiez un problème de requête, vous devez utiliser le log de requête général. See Section 5.9.2, « Le log général de requêtes ».

Le but principal de ce log est de pouvoir reprendre les modifications de la base durant les opérations de restaurations, car le log binaire contiendra les requêtes qui ont eu lieu après une sauvegarde.

Le log binaire est aussi utilisé lorsque de la réplication d'un maître par un esclave. See Chapitre 6, Réplication de MySQL.

L'utilisation du log binaire ralentit le serveur d'environ 1%. Cependant, les avantages du log binaire durant les opérations de restauration et pour la réplication sont généralement plus intéressants.

Lorsque l'option de démarrage --log-bin[=file_name] est utilisée, mysqld écrit un fichier de log contenant toutes les commandes SQL qui modifient les données. Si aucun nom de fichier n'est donné, le nom de la machine hôte est utilisé, suivi de -bin. Si un nom est donné, mais qu'il ne contient pas de chemin, le fichier sera écrit dans le dossier de données.

Si vous fournissez une extension à --log-bin=filename.extension, l'extension sera automatiquement supprimée.

mysqld va ajouter une extension au nom du fichier de log binaire qui est un nombre automatiquement incrémenté chaque fois que vous exécutez mysqladmin refresh, mysqladmin flush-logs, FLUSH LOGS ou redémarrez le serveur. Un nouveau fichier de log sera automatiquement créé lorsque le fichier en cours atteint la taille de max_binlog_size. Un fichier de log binaire peut être plus grand que max_binlog_size si vous utilisez de grandes transactions : une transaction est écrite dans le log binaire d'un seul coup, et n'est jamais répartie entre plusieurs fichiers.

Pour être capable de faire la différence entre les fichiers de logs binaire utilisés, mysqld crée aussi un fichier d'index de logs, qui porte le même nom que le fichier de log, mais avec l'extension '.index'. Vous pouvez changer le nom du fichier de log avec l'option --log-bin-index=[file_name]. N'éditez pas manuellement ce fichier durant l'exécution de mysqld ; cela va induire mysqld en erreur.

Vous pouvez effacer tous les fichiers de log avec la commande RESET MASTER, ou seulement certains d'entre eux avec PURGE MASTER LOGS. Voyez Section 13.5.4.5, « Syntaxe de la commande RESET » et Section 13.6.1, « Requêtes SQL pour contrôler les maîtres de réplication ».

Vous pouvez utiliser les options suivantes avec mysqld pour modifier ce qui est enregistré dans le fichier de log :

Pour ignorer ou forcer plusieurs bases, spécifiez l'option plusieurs fois, une fois par base.

Les règles suivante sont utilisées dans l'ordre suivant, pour décider si la requête doit aller dans le log binaire ou pas :

Par exemple, un esclave qui fonctionne avec l'option binlog-do-db=sales ne va pas écrire dans le log binaire les commandes qui concernent d'autres bases que sales (en d'autres termes, l'option binlog-do-db peut être considéré comme ``ignore les autres bases'').

Si vous utilisez la réplication, vous ne devez pas effacer les anciens log binaires jusqu'à ce que vous soyez sûrs que les esclaves n'en auront plus besoin. Une fa¸on de faire cela est d'utiliser la commande mysqladmin flush-logs une fois par jour, et d'effacer les fichiers de log qui ont plus de trois jours. Vous pouvez les supprimer manuellement, ou utilisez de préférence la commande PURGE MASTER LOGS TO (see Section 13.6, « Commandes de réplication ») qui va aussi modifier le fichier de log binaires pour vous depuis MySQL 4.1.

Un client avec le droit de SUPER peut désactiver le log binaire pour ses commandes avec SET SQL_LOG_BIN=0. See Section 13.5.2.8, « Syntaxe de SET ».

Vous pouvez examiner le fichier de log binaire avec la commande mysqlbinlog. Par exemple, vous pouvez mettre à jour le serveur MySQL depuis la ligne de commande comme ceci :

shell> mysqlbinlog log-file | mysql -h server_name

Vous pouvez aussi utiliser le programme Section 8.5, « mysqlbinlog, Exécuter des requêtes dans le log binaire » pour lire le fichier de log binaire directement dans le serveur MySQL.

Si vous utilisez les transactions, vous devez utiliser le fichier de log binaire pour les sauvegardes, plutôt que le vieux fichier de log de modifications.

L'enregistrement dans le fichier de log binaire est fait immédiatement après l'achèvement de la requête, mais avant la libération des verrous ou la validation de la requête. Cela garantit que les requêtes seront enregistrées dans l'ordre d'exécution.

Les modifications dans les tables non transactionnelles sont enregistrées dans le fichier de log binaire immédiatement après exécution. Pour les tables transactionnelles comme BDB ou InnoDB, toutes les modifications (UPDATE, DELETE ou INSERT) qui modifient les tables sont mises en cache jusqu'à ce qu'une commande COMMIT ne les envoie au serveur. A ce moment, mysqld écrit la totalité de la transaction dans le log binaire, avant d'appliquer la commande COMMIT. Tous les threads vont, au démarrage, allouer un buffer de la taille de binlog_cache_size octets pour enregistrer les requêtes. Si la requête est plus grande que ce buffer, le thread va ouvrir un fichier temporaire pour écrire la transaction. Le fichier temporaire sera supprimé dès que le thread se termine.

L'option max_binlog_cache_size (par défaut 4Go) peut être utilisé pour limiter la taille utilisée pour mettre en cache une transaction multi-requête. Si la transaction est plus grande que que cette taille, elle sera annulée.

Si vous utilisez les log de modification ou binaire, les insertions concurrentes seront converties en insertions normales lors de l'utilisation de CREATE ... SELECT ou INSERT ... SELECT. Cela garantit que vous pourrez recréer une copie exacte de la table en appliquant les même commandes sauvegardées.

Le format de log binaire est différent entre les versions 3.23, 4.0 et 5.0.0. Ces changements de formats sont nécessaires pour améliorer la réplication. MySQL 4.1 a le même format de log binaire que 4.0. See Section 6.5, « Compatibilité de la réplication entre les versions de MySQL ».