Действительно ли безопасно удалить повернутые двоичные журналы MySQL?
У меня есть сервер 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? Только информация о последнем двоичном журнале?
ОБНОВЛЕНИЕ: Я понимаю, что могу удалить журналы с ДВОИЧНЫМИ ЖУРНАЛАМИ ЧИСТКИ, который обновляет mybinlog.index файл. Однако я должен передать журналы другому компьютеру прежде, чем удалить их (я тестирую, если резервное копирование допустимо на другой машине). Для сокращения размера передачи я желаю к bzip2 файлов. Что сделают ДВОИЧНЫЕ ЖУРНАЛЫ ЧИСТКИ, если файлы журнала не будут "там" еще?
2 ответа
Наконец-то я нашел ответ на сайте MySQL. На случай, если кому-то понадобится эта информация:
До MySQL 5.0.60 ОЧИСТКА ДВОИЧНЫХ ЖУРНАЛОВ ДО и ОЧИСТКА ДВОИЧНЫХ ЖУРНАЛОВ ПЕРЕД не вели себя таким же образом (и ни один из них не вел себя правильно), когда двоичные файлы журналов, перечисленные в файле .index был удален из системы другими способами (например, с помощью rm в Linux). Начиная с MySQL 5.0.60, оба варианта оператора в таких случаях не работают с ошибкой. (Ошибка № 18199, Ошибка № 18453) Чтобы обработать такие ошибки, отредактируйте файл .index (который представляет собой простой текстовый файл) вручную, чтобы убедиться, что в нем перечислены только фактически присутствующие двоичные файлы журнала, затем снова запустите ОЧИСТКУ ДВОИЧНЫХ ЖУРНАЛОВ заявление, которое не удалось.
Это означает, что я должен отредактировать файл .index вручную, и все будет хорошо. Что интересно, файл .index - это обычный текстовый файл. Я этого даже не замечал до сих пор.
Вы можете удалить старые двоичные журналы. Вместо того, чтобы удалять их напрямую, безопаснее использовать 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