Справочное руководство по MySQL версии 4.1.1-alpha
Глава 4.9.4 Бинарный журнал обновлений
Бинарный журнал обновлений в скором времени должен полностью заменить журнал обновлений, так что мы рекомендуем вам как можно скорее перейти на его использование!
Бинарный журнал содержит всю информацию, имеющуюся в журнале обновлений, в более эффективном формате. В нем имеется информация и о времени выполнения каждого обновляющего базу запроса. В нем не содержится информации о запросах, которые не изменяют данные. Если вам нужно журналировать все запросы (например для выявления проблемного запроса), вам следует использовать общий журнал запросов. See section 4.9.2 Общий журнал запросов.
Бинарный журнал используется и при репликации подчиненного сервера (slave) с головного (master) (see section 4.10 Репликация в MySQL).
При запуске с ключом --log-bin[=file_name] mysqld создает файл журнала, в который вносятся данные обо всех обновляющих данные командах SQL. Если имя файла не задано, по умолчанию ему дается имя хоста с окончанием -bin. Если файлу присвоено имя, не содержащее пути доступа к нему, этот файл сохраняется в каталоге данных.
При вводе расширения в имя файла (например: --log-bin=filename.extension) это расширение удаляется без предупреждения.
К имени файла бинарного журнала программа mysqld прибавляет специальное расширение - номер, увеличивающийся при каждом выполнении команд mysqladmin refresh, mysqladmin flush-logs, FLUSH LOGS или перезапуске сервера. При достижении файлом журнала максимального размера, заданного в параметре max_binlog_size, автоматически создается новый. Все неактивные файлы бинарных журналов можно удалить командой RESET MASTER (see section 4.5.4 Синтаксис команды RESET.
На выбор данных, записываемых в журнал, влияют следующие настройки mysqld:
Указывает головному серверу что он должен журналировать обновления в двоичный журнал если текущая (т.е. выбранная) база данных - это 'database_name'. Остальные базы данных, особо не отмеченные, игнорируются. Имейте в виду, что если вы используете эту опцию, то вам следует делать обновления только в этой базе данных. (пример: binlog-do-db=some_database)
Заставляет master отказаться от занесения в журнал обновлений определенной базы данных (пример: binlog-ignore-db=some_database)
Чтобы была возможность определить, какие файлы журналов используются в данный момент, 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 для резервного копирования нужно использовать бинарный журнал, а не старый журнал обновлений.
Занесение данных в бинарный журнал происходит сразу по завершении исполнения запроса, но до снятия блокировок. Таким образом обеспечивается уверенность в том, что журнал ведется именно в порядке выполнения запросов.
Updates to non-transactional tables are stored in the binary log immediately after execution.
Обновления нетранзакционных таблиц сохраняются в двоичном журнале немедленно после выполнения. Все обновления (UPDATE, DELETE или INSERT), изменяющие данные в транзакционных таблицах (например, BDB-таблицу) находятся в кэше до вызова COMMIT. В этот момент mysqld пишет всю транзакцию целиком в двоичный журнал перед тем, как выполнить COMMIT. Каждый поток при запуске будет создавать буффер размером binlog_cache_size для буферизации запросов. Если запрос превышает этот размер, тогда поток откроет временный файл для сохранения транзакции. Временный файл будет удален при выходе потока.
При запуске каждого потока создается буфер запросов, объем которого соответствует значению параметра binlog_cache_size. Если запрос не помещается в буфере, поток создаст временный файл для кэша. Временный файл удаляется по завершении работы потока.
Параметр max_binlog_cache_size (по умолчанию 4Гб) позволяет ограничить общий объем памяти, используемой для кэширования мультитранзакционного запроса. Если транзакция больше этого - будет произведен откат.
При использовании журнала обновлений или бинарного журнала параллельные операции вставки будут преобразованы в нормальные операции вставки в командах CREATE ... SELECT и INSERT ... SELECT. Это сделано специально - для того, чтобы обеспечить возможность создания точной копии таблиц путем объединения резервной копии с журналом.
