Файлы журналов MySQL

Бинарный журнал обновлений

Бинарный журнал содержит всю информацию, имеющуюся в журнале обновлений, в более эффективном формате. В нем имеется информация и о времени выполнения каждого обновляющего базу запроса. В нем не содержится информации о запросах, которые не изменяют данные. Если вам нужно журналировать все запросы (например для выявления проблемного запроса), следует использовать общий журнал запросов.

Бинарный журнал применяется и при репликации подчиненного сервера (slave) с головного (master).

При запуске с ключом -log-bin[=file_name] mysqld создает файл журнала, в который вносятся данные обо всех обновляющих данные командах SQL. Если имя файла не задано, по умолчанию ему дается имя хоста с окончанием -bin. Если файлу присвоено имя, не содержащее пути доступа к нему, этот файл сохраняется в каталоге данных.

При вводе расширения в имя файла (например: -log-bin=filename.extension ) это расширение удаляется без предупреждения.

К имени файла бинарного журнала программа mysqld прибавляет специальное расширение — номер, увеличивающийся при каждом выполнении команд mysqladmin refresh, mysqladmin flush-logs, FLUSH LOGS или перезапуске сервера. При достижении файлом журнала максимального размера, заданного в параметре max_binlog_size, автоматически создается новый. Все неактивные файлы бинарных журналов можно удалить командой RESET MASTER.

На выбор данных, записываемых в журнал, влияют следующие настройки mysqld:

binlog-do-
db=database_name

binlog-ignore-
db=database_name

Чтобы была возможность определить, какие файлы журналов используются в данный момент, mysqld создает и индексный файл, содержащий имена всех находящихся в работе файлов. По умолчанию ему присваивается то же имя, что и файлу журнала, но с расширением .index. Имя этого файла можно изменить с помощью параметра -log-bin-index=[filename].

При использовании репликации удалять старые файлы журналов не стоит до тех пор, пока вы не будете уверены в том, что они никогда не понадобятся ни одной зависимой базе. Добиться такого результата можно, запуская команду mysqladmin flush-logs раз в день и затем удаляя все журналы, созданные более 3 дней назад.

Работать с файлами бинарного журнала можно с помощью программы mysqlbinlog. Обновить MySQL в соответствии с записями в журнале можно так:

shell> mysqlbinlog log-file | mysql -h server_name

С помощью программы mysqlbinlog можно даже считывать файлы журнала прямо с удаленного сервера MySQL!

При запуске mysqlbinlog с ключом -help на экран выводится дополнительная информация по работе с этой программой.

При работе с настройками BEGIN [WORK] или SET AUTOCOMMIT=0 для резервного копирования нужно использовать бинарный журнал, а не старый журнал обновлений.

Занесение данных в бинарный журнал происходит сразу по завершении исполнения запроса, но до снятия блокировок. Таким образом обеспечивается уверенность в том, что журнал ведется именно в порядке выполнения запросов.

Обновления нетранзакционных таблиц сохраняются в двоичном журнале немедленно после выполнения. Все обновления ( UPDATE, DELETE или INSERT ), изменяющие данные в транзакционных таблицах (например, BDB-таблицу), находятся в кэше до вызова COMMIT. В этот момент mysqld пишет всю транзакцию целиком в двоичный журнал перед тем, как выполнить COMMIT. Каждый поток при запуске будет создавать буфер размером binlog_cache_size для буферизации запросов. Если запрос превышает этот размер, тогда поток откроет временный файл для сохранения транзакции. Временный файл будет удален при выходе потока.

При запуске каждого потока создается буфер запросов, объем которого соответствует значению параметра binlog_cache_size. Если запрос не помещается в буфере, поток создаст временный файл для кэша. Временный файл удаляется по завершении работы потока.

Параметр max_binlog_cache_size (по умолчанию 4Гб) позволяет ограничить общий объем памяти, используемой для кэширования мультитранзакционного запроса. Если транзакция больше этого — будет произведен откат.

При использовании журнала обновлений или бинарного журнала параллельные операции вставки будут преобразованы в нормальные операции вставки в командах CREATE ... SELECT и INSERT ... SELECT. Это сделано специально — для того, чтобы обеспечить возможность создания точной копии таблиц путем объединения резервной копии с журналом.