5.8.4 Le log binaire

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 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. Le log général de requêtes .

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

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.

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.

Vous pouvez effacer tous les fichiers de log avec la commande RESET MASTER , ou seulement certains d'entre eux avec PURGE MASTER LOGS . Voyez Syntaxe de RESET et Commandes SQL pour contrôler les maîtres .

binlog-do-db=database_name

Indique au maître qu'il doit enregistrer les modifications si la base courante (c'est à dire, celle qui est sélectionnée par USE ) est db_name . Toutes les autres bases de données qui ne sont pas explicitement mentionnées sont ignorées. Si vous utilisez cette option, assurez vous que vous ne faites des modifications que dans la base courante.Un exemple qui ne fonctionnera pas comme on pourrait l'attendre : Si le serveur est lancé avec l'option binlog-do-db=sales , et que vous utilisez USE prices; UPDATE sales.january SET amount=amount+1000; , cette commande ne sera pas écrite dans le fichier de log binaire.

binlog-ignore-db=database_name

Indique au maître qu'il doit ne doit pas enregistrer les modifications si la base courante (c'est à dire, celle qui est sélectionnée par USE ) est db_name . Si vous utilisez cette option, assurez vous que vous ne faites des modifications que dans la base courante.Un exemple qui ne fonctionnera pas comme on pourrait l'attendre : Si le serveur est lancé avec l'option binlog-ignore-db=sales , et que vous utilisez USE prices; UPDATE sales.january SET amount=amount+1000; , cette commande sera écrite dans le fichier de log binaire.

• Y a-t-il des règles binlog-do-db ou binlog-ignore-db ?
  • Non : écrit la requête dans le log binaire, et quitte.
  • Oui : aller à l'étape suivante.
• Il y a des règles ( binlog-do-db ou binlog-ignore-db ou les deux). Y a t il une base de données courante (une base sélectionnée avec la commande USE )?
  • Non : N'écrit pas la requête, et quitte.
  • Oui : aller à l'étape suivante.
• Il y a une base de données courante. Y a-t-il des règles binlog-do-db ?
  • Oui : Est-ce que la base de données courante vérifie une des règles binlog-do-db ?
    • Oui : écrit la requête dans le log binaire, et quitte.
    • Non : N'écrit pas la requête, et quitte.
  • Non : aller à l'étape suivante.
• Il y a des règles binlog-ignore-db . Est-ce que la base de données courante vérifie une des règles binlog-ignore-db ?
  • Oui : N'écrit pas la requête, et quitte.
  • Non : écrit la requête dans le log binaire, et quitte.

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 ( Commandes de réplication ) qui va aussi modifier le fichier de log binaires pour vous depuis MySQL 4.1.

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

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.

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.

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.