Безопасно ли удалять вращающиеся двоичные журналы MySQL?

Question

У меня есть сервер MySQL с активной бинарной регистрацией. Как только дневной файл журнала «вращается», то есть MySQL, кажется, перестает писать в него и создает новый файл журнала. Например, в настоящее время у меня есть эти файлы в / 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

и mybinlog.000006 растет.

Могу ли я просто взять mybinlog.000004 и mybinlog.000005, сжать их и перенести на другой сервер, или мне нужно сделать что-то еще раньше?

Какая информация хранится в mybinlog.index? Только информация о последнем бинарном журнале?

ОБНОВЛЕНИЕ: Я понимаю, что могу удалить журналы с помощью PURGE BINARY LOGS, который обновляет файл mybinlog.index. Однако мне нужно перенести журналы на другой компьютер перед их удалением (я проверяю, действует ли резервная копия на другом компьютере). Чтобы уменьшить размер передачи, я хочу bzip2 файлы. Что будет делать PURGE BINARY LOGS, если файлы журналов больше не «там»?

Answer 1

Вы можете удалить старые двоичные журналы. Вместо того, чтобы удалять их напрямую, безопаснее использовать MySQL-оператор PURGE BINARY LOGS, который также обновляет ваш mybinlog.index файл. В этом файле хранятся имена файлов, которые использовались для двоичного ведения журнала, см.

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

Кроме того, вы можете настроить свой MySQL-сервер для автоматического удаления старых двоичных журналов. Установите переменные max_binlog_size и expire_logs_days в конфигурации вашего сервера на соответствующие значения.

Файлы ibdata и ib_logfile не имеют ничего общего с бинарным ведением журнала. Они используются механизмом хранения innodb. Не заблуждайтесь тем, что они, кажется, не растут: если на вашем сервере есть таблицы innodb, эти файлы важны, и их удаление может привести к потере данных. Вы можете узнать больше о InnoDB в документации:

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

Answer 2

Я наконец нашел ответ на сайте MySQL. Если кому-то нужна эта информация:

До MySQL 5.0.60, PURGE BINARY LOGS TO и PURGE BINARY LOGS BEFORE не работали одинаково (и ни один не вел себя правильно), когда двоичные файлы журналов, перечисленные в файле .index, были удалены из системы с помощью некоторые другие средства (такие как использование rm в Linux). Начиная с MySQL 5.0.60, оба варианта оператора завершаются с ошибкой в ​​таких случаях. (Ошибка № 18199, Ошибка № 18453) Чтобы устранить такие ошибки, отредактируйте файл .index (который представляет собой простой текстовый файл) вручную, чтобы убедиться, что в нем перечислены только двоичные файлы журналов, которые фактически присутствуют, а затем снова запустите PURGE BINARY LOGS. заявление, которое не удалось.

Это означает, что я должен отредактировать файл .index вручную, и все будет хорошо. Интересно, что файл .index представляет собой обычный текстовый файл. Я даже не заметил этого до сих пор.

Answer 3

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

УДАЛИТЬ ВСЕ файлы bin до 3 ДНЕЙ!

или

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

Answer 4

mysql-bin.index обычно содержит все файлы .bin. Если вы удалили некоторые файлы, пожалуйста, отредактируйте .index, чтобы отразить, какие файлы доступны. Если вы удалили все .bin файлы, удалите пустой .index файл. Это решит вашу проблему.