Est-il prudent de supprimer les journaux binaires MySQL pivotés?

Question

J'ai un serveur MySQL avec la journalisation binaire active. Une fois par jour, le fichier journal est "pivoté", c'est-à-dire que MySQL semble arrêter d'écrire dessus et crée un nouveau fichier journal. Par exemple, j'ai actuellement ces fichiers dans/var/lib/mysql

-rw-rw---- 1 mysql mysql 10485760 Jun 7 09:26 ibdata1 
-rw-rw---- 1 mysql mysql 5242880 Jun 7 09:26 ib_logfile0 
-rw-rw---- 1 mysql mysql 5242880 Jun 2 15:20 ib_logfile1 
-rw-rw---- 1 mysql mysql 1916844 Jun 6 09:20 mybinlog.000004 
-rw-rw---- 1 mysql mysql 61112500 Jun 7 09:26 mybinlog.000005 
-rw-rw---- 1 mysql mysql 15609789 Jun 7 13:57 mybinlog.000006 
-rw-rw---- 1 mysql mysql  54 Jun 7 09:26 mybinlog.index 

et mybinlog.000006 est en croissance. Puis-je simplement prendre mybinlog.000004 et mybinlog.000005, les compresser et les transférer sur un autre serveur, ou dois-je faire autre chose auparavant?

Quelles informations sont stockées dans mybinlog.index? Seulement l'info sur le dernier journal binaire? Je comprends que je peux supprimer les journaux avec PURGE BINARY LOGS qui met à jour le fichier mybinlog.index. Cependant, j'ai besoin de transférer les logs vers un autre ordinateur avant de les supprimer (je vérifie si la sauvegarde est valide sur une autre machine). Pour réduire la taille de transfert, je souhaite bzip2 les fichiers. Qu'est-ce que PURGE BINARY LOGS fera si les fichiers journaux ne sont plus "là"?

Answer 1

J'ai finalement trouvé la réponse sur le site Web MySQL. Dans le cas où quelqu'un a besoin de ces informations:

Avant MySQL 5.0.60, PURGE BINARY JOURNAUX et PURGE BINARY JOURNAUX AVANT ne se comportait pas de la même manière (et ni l'un se comportait correctement) lorsque les fichiers journaux binaires répertoriés dans le Le fichier .index a été supprimé du système par d'autres moyens (comme l'utilisation de rm sous Linux). À partir de MySQL 5.0.60, les deux variantes de l'instruction échouent avec une erreur dans de tels cas. (Bug n ° 18199, bogue n ° 18453) Pour gérer de telles erreurs, éditez manuellement le fichier .index (qui est un simple fichier texte) pour vous assurer qu'il ne liste que les fichiers journaux binaires présents, puis réexécutez le PURGE BINARY LOGS déclaration qui a échoué.

Cela signifie que je devrais éditer le fichier .index manuellement et tout ira bien. Ce qui est intéressant, c'est que le fichier .index est un fichier texte régulier. Je n'ai même pas remarqué ça jusqu'à maintenant. EFFACER TOUS les fichiers bin avant 3 JOURS!

Answer 2

Vous pouvez supprimer les anciens journaux binaires. Au lieu de les supprimer directement, il est plus sûr d'utiliser l'instruction MySQL PURGE BINARY LOGS qui met également à jour votre fichier mybinlog.index. Ce fichier stocke que les noms de fichiers ont été utilisés pour l'enregistrement binaire, voir

http://dev.mysql.com/doc/refman/5.0/en/purge-binary-logs.html

De plus, vous pouvez configurer votre serveur MySQL pour supprimer les anciens journaux binaires automatiquement. Définissez les variables max_binlog_size et expire_logs_days dans la configuration de votre serveur sur les valeurs appropriées. Les fichiers ibdata et ib_logfile n'ont rien à voir avec la journalisation binaire. Ils sont utilisés par le moteur de stockage innodb. Ne vous méprenez pas sur le fait qu'ils ne semblent pas se développer: Si vous avez des tables innodb sur votre serveur, ces fichiers sont importants et leur suppression peut entraîner une perte de données. Vous pouvez en savoir plus sur InnoDB dans les docs:

http://dev.mysql.com/doc/refman/5.0/en/innodb-configuration.html

Answer 3

mysql> PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY; 

ou

PURGE MASTER LOGS BEFORE '2010-10-08 00:00:00';