Последние версии MySQL (начиная с версии 3.23.14) поддерживают сохранение еще одной разновидности журнала обновлений, который хранит в двоичном, а не в текстовом формате. Это наиболее эффективный формат хранения данных. Кроме того, в двоичном файле хранится более детальная информация, чем в стандартном журнале обновлений. Утилита под названием mysqlbinlog преобразует двоичный журнал в текстовый, что позволяет его прочитать. Двоичный журнал обновлений создается при запуске сервера с параметром - -log-bin.
Листинг 15.7.
[root@host]# /usr/local/mysql/bin/mysql_safe --log-bin
По умолчанию файл этого журнала имеет имя, состоящее из имени узла с последующим суффиксом -bin и порядкового номера, идентифицирующего данный журнал.
На заметку
Активизировать двоичный журнал обновлений нужно при настройке процедуры репликации между главным и подчиненным серверами (см. о репликации в главе 17, "Механизм репликации MySQL").
Для обновления этих журналов используется команда FLUSH LOGS, которая приводит к закрытию сервера с последующим открытием журналов регистрации. Для двоичных журналов эта команда закрывает текущий журнал и создает новый журнал с новым порядковым номером, после чего старый журнал можно заархивировать.
Ценность процедуры сброса журналов можно оценить при изучении проблемы истечения срока годности журналов и их ротации, но об этом речь пойдет в следующем разделе.

Временные задержки
Обновления, являющиеся частью транзакции, не выполняются немедленно; они хранятся в кэш-памяти до момента выполнения всей транзакции. После получения сервером MySQL команды COMMIT, все операторы, входящие в транзакцию, протоко­лируются в двоичный журнал, а затем изменения сохраняются в базу данных. Если часть транзакции по какой-либо причине не выполняется, вся транзакция откатывается, при этом изменения в двоичный журнал не заносятся.

Срок годности и ротация журналов
При сильной загрузке сервера журналы очень быстро приобретают большие размеры (постепенно заполняя собою дисковое пространство). Поэтому журналами необходимо управлять с использованием даты и механизма ротации во избежание лишних проблем. 
Ротация журналов представляет собой один из методов решения этой проблемы. Ротация журналов заключается в создании конечного количества журналов с последовательной заменой устаревших журналов новыми, причем таким образом, чтобы за один цикл удалялся один устаревший журнал. Например, если у нас есть файл под именем query_log, после первой ротации он будет переименован в журнал query_log.1, после чего будет создан новый файл query_log. Во время следующей ротации файл query_log.1 будет переименован в файл query_log.2, query_log - query_log.1, после чего будет создан новый файл с именем (вы, конечно же, догадались каким) query_log. Во время последней ротации самый старый файл будет заменен самым новым. То, какой объем такой информации будет храниться и как часто будет производиться процедура ротации, зависит от количества ротаций и количества созданных при этом файлов. Это количество варьируется в зависимости от ваших условий, но чаще всего новые файлы регистрации создаются ежедневно, а ротация производится на протяжении недели тоже ежедневно.
Процедура ротации хорошо применима к журналам, идентифицированным не числом, а именем. Если вы имеете дело с пронумерованными файлами журналов регистрации, только что описанный метод переименования файлов может нарушить план нумерации. В таком случае, пронумерованные журналы можно обрабатывать с использованием заданных сроков годности, удаляя или архивируя их в случае истечения этого срока годности. Этот метод называется истечением срока годности журнала.
Написание сценария расчета срока годности - задача довольно сложная. Подробнее об этом можно узнать в руководстве по MySQL, находящемся по адресу http://www. mysql.com/doc/en/Log_file_maintenance.html.