Полный журнал изменений данных (Binary Update Log)
В будущем полный журнал изменений данных(binary update log) заменит журнал обновлений (update log), так что мы рекомендуем Вам перейти к использованию этого журнала как можно скорее! Полный журнал изменений данных(binary update log) содержит всю информацию, которую содержит журнал обновлений (update log), но в более эффективном формате. Он содержит также информацию о том, как долго выполнялся каждый запрос, который модифицировал базу данных.
Вы можете использовать опции binlog-do-db=database_name Будет обрабатываться только указанная база данных binlog-ignore-db=database_name Будут игнорироваться указанные базы данных
При использовании команд mysqladmin refresh mysqladmin flush-logs SQL оператор «FLUSH LOGS» или перезапуска сервера к расширению имени файла журнала будет добавляться инкрементальный номер.
Чтоб учитывать какие файлы журналов использовались Mysqld создает индексный файл, у которого имя совпадает с полным журналом изменений данных(binary update log), и имеет расширение ‘.index’. Вы можете поменять имя этого файла, указав опцию —log-bin-index=[filename].
Если Вы используете репликацию, Вы не должны удалить старые полные журналы изменений данных(binary update log), пока Вы не уверены, что никакой резервный сервер не будет использовать их. Один из вариантов делать mysqladmin flush-logs один раз в день и затем удалять любые файлы регистрации, у которых дата старше, чем 3 дня. Вы можете просмотреть полный журнал изменений данных(binary update log), командой mysqlbinlog. mysqlbinlog log-file | mysql -h server_name Дополнительные ключи Вы можете узнать, запустив команду mysqlbinlog —help
Если Вы используете BEGIN [WORK] или SET AUTOCOMMIT=0, Вы должны использовать полный журнал изменений данных(binary update log) вместо журнала обновлений (update log). Запись журнала происходит сразу, после выполнения запроса, перед выполнением возможных блокировок. Это гарантирует достоверную запись журнала Все обновления (UPDATE, DELETE or INSERT) кэшируются до операции COMMIT, если вы используете транзакции (таблицы BDB). Если Вы не используете транзакции — изменения сохраняются немедленно. Каждый поток при старте заполняет буфер размером (binlog_cache_size) для записи запросов. Если запрос больше чем размер этого буфера, используется временный файл, который будет удален при закрытии потока. Чтоб ограничить максимальный размер буфера, используйте опцию max_binlog_cache_size гарантировать, что Вы можете освежать точную копию ваших таблиц, применяя файл регистрации на резервировании (копии).
ВАЖНО! Полный журнал изменений данных (Binary Update Log) начинается с определенного момента времени. Ваши резервные сервера должны иметь точные копии данных на момент запуска журнала. В будущих версиях MySQL 4.0 это будет устранено, но на текущий момент Вам необходимо блокировать сервер для записи, и поставит блокировку на чтение, когда вы будете делать слепок текущие базы данных
При правильной конфигурации резервный сервер соединяется с основным и ждет данных по модификации. Если соединение прерывается, то резервный сервер пытается соединиться снова, каждые master-connect-retry сек. Резервный сервер отмечает момент отключения. Основной сервер не определяет, сколько подключено к нему резервных серверов.
