4.9 Les fichiers de log de MySQL
4 Administration du serveur
Manuel de Référence MySQL 4.1 : Version Française
. Le log d'erreurs . Le log général de requêtes . Le log de modification ->Le log binaire de modifications . Le log des requêtes lentes . Entretien des fichiers de log
|
4.9.4 Le log binaire de modifications
Notre objectif est de remplacer l'utilisation du log de modifications par
le log binaire de modifications. Nous vous recommandons donc de changer
de format de log le plus tôt possible.
Le log binaire contient toutes les informations qui sont disponibles dans
le log de modifications, dans un format bien plus efficace. Il contient aussi
des informations sur le temps d'exécution de la requête. Il ne contient pas
les requêtes qui n'ont pas modifié les données. Si vous voulez enregistrer
toutes les requêtes, vous devez utiliser le fichier de log 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.
Si vous fournissez une extension à
--log-bin=filename.extension
,
l'extension sera automatiquement supprimée.
Au nom du fichier de log binaire,
mysqld
va ajouter une extension 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
.
Vous pouvez effacer tous les fichiers de log inactifs avec la commande
RESET MASTER
. Syntaxe de
RESET
.
Vous pouvez utiliser les options suivantes avec
mysqld
pour modifier
ce qui est enregistré dans le fichier de log :
Option
|
Description
|
binlog-do-db=database_name
|
Indique au maître qu'il doit enregistrer les modifications des bases
spécifiées, et ignorer les autres.
(Example:
binlog-do-db=some_database
) |
binlog-ignore-db=database_name
|
Indique autre maître que les modifications des bases spécifiées ne doit
pas être enregistrées. (Exemple :
binlog-ignore-db=some_database
)
|
Pour être capable de connaître les différents fichiers de logs qui ont
été utilisés,
mysqld
va aussi créer un fichier d'index qui contient
les noms des fichiers de log utilisé. Par défaut, ils ont le même nom que
le fichier de log, avec l'extension
'.index'
.
Vous pouvez modifier le nom du fichier d'index avec l'option
--log-bin-index=[filename]
.
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 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
mysqlbinlog
pour lire le
fichier de log binaire directement dans le serveur MySQL.
mysqlbinlog --help
vous donnera plus d'informations sur comment utiliser
ce programme.
Si vous utilisez
BEGIN [WORK]
ou
SET AUTOCOMMIT=0
, 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.
|