16.1.4.4. Двоичные Опции Журнала и Переменные

--binlog-row-event-max-size=N

Определите максимальный размер основанного на строке двоичного события журнала в байтах. Строки группируются в события, меньшие чем этот размер если возможный. Значение должно быть кратным числом 256. Значение по умолчанию 8192 с MySQL 5.6.6 и 1024 перед этим. См. Раздел 16.1.2, "Форматы Репликации".

--log-bin[=base_name]

Включите двоичному журналированию. Сервер регистрирует все операторы, которые изменяют данные на двоичный журнал, который используется для резервного копирования и репликации. См. Раздел 5.2.4, "Двоичный Журнал".

Значение опции, если дано, является базовым именем для последовательности журнала. Сервер создает двоичные файлы журнала в последовательности, добавляя числовой суффикс к базовому имени. Рекомендуется, чтобы Вы определили базовое имя (см. Раздел C.5.8, "Известные Проблемы в MySQL", по причине). Иначе, использование MySQL host_name-bin как базовое имя.

В MySQL 5.6.5 и позже, когда сервер читает запись из индексного файла, он проверяет, содержит ли запись относительный путь, и если он делает, относительная часть пути в замененном набором абсолютного пути, используя --log-bin опция. Абсолютный путь остается неизменным; в таком случае индексирование должно быть отредактировано вручную, чтобы позволить новому пути или путям использоваться. До MySQL 5.6.5 ручное вмешательство требовалось, перемещая двоичный журнал или релейные файлы журнала. (Ошибка #11745230, Ошибка #12133)

Установка этой опции вызывает log_bin системная переменная, которая будет установлена в ON (или 1), а не к базовому имени. Начинаясь с MySQL 5.6.2, двоичное имя файла журнала (с путем) доступно как log_bin_basename системная переменная.

--log-bin-index[=file_name]

Индексный файл для двоичных имен файла журнала. См. Раздел 5.2.4, "Двоичный Журнал". Если Вы опускаете имя файла, и если Вы не определяли один с --log-bin, Использование MySQL host_name-bin.index как имя файла.

--log-bin-trust-function-creators[={0|1}]

Эта опция устанавливает соответствие log_bin_trust_function_creators системная переменная. Если никакой параметр не дается, опция устанавливает переменную в 1. log_bin_trust_function_creators влияет, как MySQL осуществляет ограничения на сохраненную функцию и триггерное создание. См. Раздел 19.7, "Двоичное Журналирование Сохраненных Программ".

--log-bin-use-v1-row-events[={0|1}]

Двоичные события строки журнала версии 2 являются доступным начинанием с MySQL 5.6.6; однако, события Version 2 не могут быть считаны предыдущими выпусками MySQL Server. Установка этой опции к 1 причине mysqld, чтобы записать двоичный журнал, используя события журналирования Версии 1, который является единственной версией двоичных событий журнала, используемых в предыдущих выпусках, и таким образом производит двоичные журналы, которые могут быть считаны более старыми ведомыми устройствами. Установка --log-bin-use-v1-row-events к 0 (значение по умолчанию) заставляет mysqld использовать двоичные события журнала Версии 2.

Значение, используемое для этой опции, может быть получено из только для чтения log_bin_use_v1_row_events системная переменная.

--log-bin-use-v1-row-events имеет в основном интерес, устанавливая обнаружение конфликта репликации и использование разрешения NDB$EPOCH_TRANS() как функция обнаружения конфликта, которая требует двоичных событий строки журнала Версии 2. Таким образом, эта опция и --ndb-log-transaction-id не являются совместимыми.

Для получения дополнительной информации см. Раздел 17.6.11, "MySQL Cluster Replication Conflict Resolution".

--log-short-format

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

--binlog-do-db=db_name

Эта опция влияет на двоичный файл, входящий в систему способ, подобный пути который --replicate-do-db влияет на репликацию.

Эффекты этой опции зависят от того, используется ли основанный на операторе или основанный на строке формат журналирования, таким же образом что эффекты --replicate-do-db зависьте от, или основанная на операторе или построчная репликация используется. Следует иметь в виду, что формат, используемый, чтобы зарегистрировать данный оператор, возможно, обязательно не то же самое как обозначенное значением binlog_format. Например, операторы DDL такой как CREATE TABLE и ALTER TABLE всегда регистрируются как операторы, без отношения к формату журналирования в действительности, таким образом, следующие основанные на операторе правила для --binlog-do-db всегда применяйтесь в определении, регистрируется ли оператор.

Основанное на операторе журналирование. Только те операторы пишутся двоичному журналу где база данных значения по умолчанию (то есть, тот, выбранный USE) db_name. Чтобы определить больше чем одну базу данных, используйте эту опцию многократно, однажды для каждой базы данных; однако, выполнение так не вызывает операторы перекрестной базы данных такой как UPDATE some_db.some_table SET foo='bar' быть зарегистрированным, в то время как различная база данных (или никакая база данных) выбираются.

Пример того, что не работает, как Вы могли бы ожидать при использовании основанного на операторе журналирования: Если сервер запускается с --binlog-do-db=sales и Вы делаете следующие заявления, UPDATE оператор не регистрируется:

USE prices;UPDATE sales.january SET amount=amount+1000;

Главная причина для этого "только проверяет, что поведение" базы данных значения по умолчанию состоит в том, что трудно от одного только оператора знать, должно ли это быть тиражировано (например, если Вы используете многократную таблицу DELETE операторы или многократная таблица UPDATE операторы, которые действуют через многократные базы данных). Это также быстрее, чтобы проверить только базу данных значения по умолчанию, а не все базы данных, если нет никакой потребности.

Другой случай, который, возможно, не самоочевиден, происходит, когда данная база данных тиражируется даже при том, что это не было определено, устанавливая опцию. Если сервер запускается с --binlog-do-db=sales, следующий UPDATE оператор регистрируется даже при том, что prices не был включен, устанавливая --binlog-do-db:

          USE sales;UPDATE prices.discounts SET percentage = percentage + 10;

Поскольку sales база данных значения по умолчанию когда UPDATE заявление делается, UPDATE регистрируется.

Основанное на строке журналирование. Журналирование ограничивается базе данных db_name. Только изменения к таблицам, принадлежащим db_name регистрируются; база данных значения по умолчанию не имеет никакого эффекта на это. Предположите, что сервер запускается с --binlog-do-db=sales и основанное на строке журналирование в действительности, и затем следующие операторы выполняются:

USE prices;UPDATE sales.february SET amount=amount+100;

Изменения к february таблица в sales база данных регистрируется в соответствии с UPDATE оператор; это происходит действительно ли USE заявление было сделано. Однако, при использовании основанного на строке формата журналирования и --binlog-do-db=sales, изменения производятся следующим UPDATE не регистрируются:

USE prices;UPDATE prices.march SET amount=amount-25;

Даже если USE prices оператор был изменен на USE sales, UPDATE эффекты оператора все еще не были бы записаны двоичному журналу.

Другое важное различие в --binlog-do-db обработка для основанного на операторе журналирования в противоположность основанному на строке журналированию происходит относительно операторов, которые обращаются к многократным базам данных. Предположите, что сервер запускается с --binlog-do-db=db1, и следующие операторы выполняются:

USE db1;UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;

Если Вы используете основанное на операторе журналирование, обновления к обеим таблицам пишутся двоичному журналу. Однако, при использовании основанного на строке формата, только изменения к table1 регистрируются; table2 находится в различной базе данных, таким образом, она не изменяется UPDATE. Теперь предположите это, вместо USE db1 оператор, a USE db4 оператор использовался:

USE db4;UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;

В этом случае, UPDATE оператор не пишется двоичному журналу при использовании основанного на операторе журналирования. Однако, при использовании основанного на строке журналирования, изменения к table1 регистрируется, но не это к table2— другими словами, только изменения к таблицам в базе данных, названной --binlog-do-db регистрируются, и выбор базы данных значения по умолчанию не имеет никакого эффекта на это поведение.

--binlog-ignore-db=db_name

Эта опция влияет на двоичный файл, входящий в систему способ, подобный пути который --replicate-ignore-db влияет на репликацию.

Эффекты этой опции зависят от того, используется ли основанный на операторе или основанный на строке формат журналирования, таким же образом что эффекты --replicate-ignore-db зависьте от, или основанная на операторе или построчная репликация используется. Следует иметь в виду, что формат, используемый, чтобы зарегистрировать данный оператор, возможно, обязательно не то же самое как обозначенное значением binlog_format. Например, операторы DDL такой как CREATE TABLE и ALTER TABLE всегда регистрируются как операторы, без отношения к формату журналирования в действительности, таким образом, следующие основанные на операторе правила для --binlog-ignore-db всегда применяйтесь в определении, регистрируется ли оператор.

Основанное на операторе журналирование. Говорит серверу не регистрировать любой оператор где база данных значения по умолчанию (то есть, тот, выбранный USE) db_name.

До MySQL 5.6.12, эта опция, вызванная любые операторы, содержащие полностью определенные имена таблиц, которые не будут зарегистрированы, если не было никакой определенной базы данных значения по умолчанию (то есть, когда SELECT DATABASE() возвратился NULL). В MySQL 5.6.12 и позже, когда нет никакой базы данных значения по умолчанию, нет --binlog-ignore-db опции применяются, и такие операторы всегда регистрируются. (Ошибка #11829838, Ошибка #60188)

Основанный на строке формат. Говорит серверу не регистрировать обновления к любым таблицам в базе данных db_name. Текущая база данных не имеет никакого эффекта.

При использовании основанного на операторе журналирования не работает следующий пример, как Вы могли бы ожидать. Предположите, что сервер запускается с --binlog-ignore-db=sales и Вы делаете следующие заявления:

USE prices;UPDATE sales.january SET amount=amount+1000;

UPDATE оператор зарегистрирован такой случай потому что --binlog-ignore-db применяется только к базе данных значения по умолчанию (определенный USE оператор). Поскольку sales база данных была определена явно в операторе, оператор не фильтровался. Однако, при использовании основанного на строке журналирования, UPDATE эффекты оператора не пишутся двоичному журналу, что означает что никакие изменения для sales.january таблица регистрируется; в этом экземпляре, --binlog-ignore-db=sales причины все изменения, произведенные в таблицах в копии ведущего устройства sales база данных, которая будет проигнорирована в целях двоичного журналирования.

Чтобы определить больше чем одну базу данных, чтобы проигнорировать, используйте эту опцию многократно, однажды для каждой базы данных. Поскольку имена базы данных могут содержать запятые, список будет обработан как имя единственной базы данных, если Вы предоставите список разделенных запятой значений.

Недопустимо использовать эту опцию, если Вы используете обновления перекрестной базы данных, и Вы не хотите, чтобы эти обновления были зарегистрированы.

--binlog-checksum={NONE|CRC32}

Включение этой опции заставляет ведущее устройство писать контрольные суммы для событий, записанных двоичному журналу. Набор к NONE отключить, или имя алгоритма, который будет использоваться для того, чтобы генерировать контрольные суммы; в настоящий момент только контрольные суммы CRC32 поддерживаются. С MySQL 5.6.6, CRC32 значение по умолчанию.

Эта опция была добавлена в MySQL 5.6.2.

--master-verify-checksum={0|1}

Включение этой опции заставляет ведущее устройство проверять события от двоичного журнала, используя контрольные суммы, и останавливаться с ошибкой в случае несоответствия. Отключенный по умолчанию.

Эта опция была добавлена в MySQL 5.6.2.

--max-binlog-dump-events=N

Эта опция используется внутренне тестовым комплектом MySQL для тестирования репликации и отладки.

--sporadic-binlog-dump-fail

Эта опция используется внутренне тестовым комплектом MySQL для тестирования репликации и отладки.

--binlog-rows-query-log-events

Добавленный в MySQL 5.6.2, эта опция включает binlog_rows_query_log_events. Должен быть установлен в OFF (значение по умолчанию), генерируя журналы для MySQL 5.6.1 или более раннего ведомого сервера или версии mysqlbinlog.

log_bin

Включается ли двоичный журнал. Если --log-bin опция используется, тогда значение этой переменной ON; иначе это OFF. Эта переменная сообщает только относительно состояния двоичного журналирования (включил или отключил); это фактически не сообщает о значении который --log-bin устанавливается.

См. Раздел 5.2.4, "Двоичный Журнал".

log_slave_updates

Должны ли обновления, полученные ведомым сервером от главного сервера, быть зарегистрированы к собственному двоичному журналу ведомого устройства. Двоичное журналирование должно быть позволено на ведомом устройстве для этой переменной иметь любой эффект. См. Раздел 16.1.4, "Репликация и Двоичные Опции Журналирования и Переменные".

binlog_cache_size

Размер кэша, чтобы содержать изменения к двоичному журналу во время транзакции. Двоичный кэш журнала выделяется для каждого клиента, если сервер поддерживает какие-либо транзакционные механизмы хранения и если у сервера есть двоичный включенный журнал (--log-bin опция). Если Вы часто используете большие транзакции, можно увеличить этот размер кэша, чтобы получить лучшую производительность. Binlog_cache_use и Binlog_cache_disk_use переменные состояния могут быть полезными для настройки размера этой переменной. См. Раздел 5.2.4, "Двоичный Журнал".

binlog_cache_size устанавливает размер для кэша транзакции только; размером кэша оператора управляют binlog_stmt_cache_size системная переменная.

binlog_checksum

Когда включено, эта переменная заставляет ведущее устройство писать контрольную сумму для каждого события в двоичном журнале. binlog_checksum поддерживает значения NONE (отключенный) и CRC32. Значение по умолчанию CRC32 с MySQL 5.6.6, NONE перед этим.

Когда binlog_checksum отключается (значение NONE), сервер проверяет, что пишет только полные события в двоичный журнал при записи и проверяя длину события (а не контрольная сумма) для каждого события.

Изменение значения этой переменной заставляет двоичный журнал быть повернутым; контрольные суммы всегда не пишутся всему двоичному файлу журнала, и никогда только части одного.

Эта переменная была добавлена в MySQL 5.6.2.

В MySQL 5.6.6 и позже, устанавливая эту переменную на ведущем устройстве к значению, нераспознанному ведомым устройством, заставляет ведомое устройство устанавливать свое собственное binlog_checksum значение к NONE, и остановить репликацию с ошибкой. (Ошибка #13553750, Ошибка #61096), Если обратная совместимость с более старыми ведомыми устройствами является беспокойством, можно хотеть установить значение явно в NONE.

binlog_direct_non_transactional_updates

Из-за проблем параллелизма, ведомое устройство может стать непоследовательным, когда транзакция содержит обновления и к транзакционным и к нетранзакционным таблицам. MySQL пытается сохранить причинную связь среди этих операторов при записи нетранзакционных операторов в кэш транзакции, который сбрасывается на фиксацию. Однако, проблемы возникают, когда модификации, сделанные к нетранзакционным таблицам от имени транзакции сразу, становятся видимыми к другим соединениям, потому что эти изменения не могут быть сразу записаны в двоичный журнал.

binlog_direct_non_transactional_updates переменная предлагает одно возможное обходное решение этой проблеме. По умолчанию эта переменная отключается. Включение binlog_direct_non_transactional_updates причины обновляют к нетранзакционным таблицам, которые будут записаны непосредственно двоичному журналу, а не кэшу транзакции.

binlog_direct_non_transactional_updates работы только для операторов, которые тиражируются, используя основанный на операторе двоичный формат журналирования; то есть, это работает только когда значение binlog_format STATEMENT, или когда binlog_format MIXED и данный оператор тиражируется, используя основанный на операторе формат. Эта переменная не имеет никакого эффекта, когда двоичный формат журнала ROW, или когда binlog_format устанавливается в MIXED и данный оператор тиражируется, используя основанный на строке формат.

В MySQL 5.6 эта переменная не имеет никакого эффекта, когда двоичный формат журнала ROW или MIXED. (Ошибка #51291)

binlog_format

Эта переменная устанавливает двоичный формат журналирования, и может быть любым из STATEMENT, ROW, или MIXED. См. Раздел 16.1.2, "Форматы Репликации". binlog_format устанавливается --binlog-format опция при запуске, или binlog_format переменная во времени выполнения.

В MySQL 5.6 формат значения по умолчанию STATEMENT. Исключение: Для MySQL Cluster NDB 7.3, значение по умолчанию MIXED; основанная на операторе репликация не поддерживается для MySQL Cluster.

Вы должны иметь SUPER полномочие установить или глобальную переменную или сеанс binlog_format значение.

Управление правил, когда изменения к этой переменной вступают в силу и сколько времени эффект длится, является тем же самым что касается других системных переменных сервера MySQL. См. Раздел 13.7.4,"SET Синтаксис", для получения дополнительной информации.

Когда MIXED определяется, основанная на операторе репликация используется, за исключением случаев, где только построчная репликация, как гарантируют, приведет к надлежащим результатам. Например, это происходит, когда операторы содержат определяемые пользователем функции (UDF) или UUID() функция. Исключение к этому правилу - это MIXED всегда использует основанную на операторе репликацию для сохраненных функций и триггеров.

Есть исключения, когда невозможно переключить формат репликации во времени выполнения:

Попытка переключить формат в те случаи приводит к ошибке.

Двоичный формат журнала влияет на поведение следующих параметров сервера:

Эти эффекты обсуждаются подробно в описаниях отдельных опций.

binlog_max_flush_queue_time

Сколько времени в микросекундах, чтобы продолжить читать транзакции из очереди сброса перед продолжением групповой фиксации (и синхронизировать журнал к диску, если sync_binlog больше чем 0). Если значение 0 (значение по умолчанию), нет никакого тайм-аута, и сервер продолжает читать новые транзакции, пока очередь не пуста.

Обычно, binlog_max_flush_queue_time может остаться установленным в 0. Если серверные процессы большое количество соединений (например, 100 или больше) и много коротких транзакций с требованиями низкой задержки, может быть полезно установить значение, больше чем 0, чтобы вызвать более частые сбросы к диску.

Эта переменная была добавлена в MySQL 5.6.6.

binlog_order_commits

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

Эта переменная была добавлена в MySQL 5.6.6.

binlog_row_image

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

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

В MySQL 5.6 можно заставить сервер регистрировать все или минимальные строки, используя binlog_row_image системная переменная. Эта переменная фактически принимает одно из трех возможных значений, как показано в следующем списке:

Значение по умолчанию full. В MySQL 5.5 и более ранней, всей строке изображения всегда используются для обоих исходных видов записи и после изображений. Если Вы должны тиражировать от MySQL 5.6 (или позже) ведущее устройство к ведомому устройству, выполняющему предыдущую версию MySQL, ведущее устройство должно всегда использовать это значение.

При использовании minimal или noblob, удаляет и обновления, как гарантируют, будут работать правильно на данную таблицу, если и только если следующие условия являются истиной и для источника и для целевых таблиц:

(Другими словами таблицы должны быть идентичными с возможным исключением, индексирует, которые не являются частью первичных ключей таблиц.)

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

Установка этой переменной не имеет никакого эффекта, когда двоичный формат журналирования STATEMENT. Когда binlog_format MIXED, установка для binlog_row_image применяется к изменениям, которые регистрируются, используя основанный на строке формат, но эту установку никакого эффекта на изменения, зарегистрированные как операторы.

Установка binlog_row_image или на глобальном или на сеансовом уровне не вызывает неявную фиксацию; это означает, что эта переменная может быть заменена, в то время как транзакция происходит, не влияя на транзакцию.

binlog_rows_query_log_events

binlog_rows_query_log_events системная переменная влияет на основанное на строке журналирование только. Когда включено, это заставляет MySQL 5.6.2 или более поздний сервер писать информационные события журнала, такие как события журнала запросов строки в его двоичный журнал. Эта информация может использоваться для отладки и связанных целей; такой как получение исходного запроса, выпущенного на ведущем устройстве, когда это не может быть восстановлено от обновлений строки.

Эти события обычно игнорируются MySQL 5.6.2 и более поздними программами, читая двоичный журнал и так не вызовите проблемы, тиражируясь или восстанавливая от резервного копирования. Это не истина для mysqld или mysqlbinlog от MySQL 5.6.1 или ранее: Когда более старая версия программы, читая журнал встречается с информационным событием журнала, это перестало работать, и прекращает читать в той точке. Сделать двоичный журнал читаемым ведомыми серверами MySQL репликации и другими читателями (например, mysqlbinlog) от MySQL 5.6.1 или более раннего распределения, binlog_rows_query_log_events должен быть отключен во время журналирования.

binlog_stmt_cache_size

Эта переменная определяет размер кэша для двоичного журнала, чтобы содержать нетранзакционные заявления, сделанные во время транзакции. Разделите двоичную транзакцию журнала, и кэши оператора выделяются для каждого клиента, если сервер поддерживает какие-либо транзакционные механизмы хранения и если у сервера есть двоичный включенный журнал (--log-bin опция). Если Вы часто используете большие нетранзакционные операторы во время транзакций, можно увеличить этот размер кэша, чтобы получить лучшую производительность. Binlog_stmt_cache_use и Binlog_stmt_cache_disk_use переменные состояния могут быть полезными для настройки размера этой переменной. См. Раздел 5.2.4, "Двоичный Журнал".

binlog_cache_size системная переменная устанавливает размер для кэша транзакции.

log_bin_basename

Содержит имя и полный путь к двоичному файлу журнала. В отличие от этого log_bin системная переменная, log_bin_basename отражает набор имени с --log-bin параметр сервера.

log_bin_basename системная переменная была добавлена в MySQL 5.6.2.

log_bin_use_v1_row_events

Шоу, используется ли двоичное журналирование Версии 2, доступное начинание с MySQL 5.6.6. Значение 1 шоу, что сервер пишет двоичный журнал, используя события журналирования Версии 1 (единственная версия двоичных событий журнала, используемых в MySQL 5.6.5 и предыдущих выпусках MySQL Server), и таким образом создание двоичного журнала, который может быть считан более старыми ведомыми устройствами. 0 указывает, что двоичные события журнала Версии 2 используются.

Эта переменная только для чтения. Чтобы переключиться между двоичным двоичным журналированием события Версии 1 и Версии 2, необходимо перезапустить mysqld с --log-bin-use-v1-row-events опция.

Кроме, выполняя обновления MySQL Cluster Replication, --log-bin-use-v1-events имеет в основном интерес, устанавливая обнаружение конфликта репликации и использование разрешения NDB$EPOCH_TRANS(), который требует регистрации событий строки двоичных знаков Версии 2. Таким образом, эта опция и --ndb-log-transaction-id не являются совместимыми.

Для получения дополнительной информации см. Раздел 17.6.11, "MySQL Cluster Replication Conflict Resolution".

master_verify_checksum

Включение этой переменной заставляет ведущее устройство исследовать контрольные суммы, читая из двоичного журнала. master_verify_checksum отключается по умолчанию; в этом случае ведущее устройство использует длину события от двоичного журнала, чтобы проверить события, так, чтобы только полные события были считаны из двоичного журнала.

Эта переменная была добавлена в MySQL 5.6.2.

max_binlog_cache_size

Если транзакция требует больше чем это много байтов памяти, сервер генерирует Составную транзакцию требуемые больше чем 'max_binlog_cache_size' байты ошибки хранения. Минимальное значение 4096. Минимальное значение 4096. Максимальное возможное значение 16EB (эксабайты). Максимальное рекомендуемое значение составляет 4 Гбайт; это - то, вследствие того, что MySQL в настоящий момент не может работать с двоичными позициями журнала, больше чем 4 Гбайт.

max_binlog_cache_size устанавливает размер для кэша транзакции только; верхним пределом для кэша оператора управляют max_binlog_stmt_cache_size системная переменная.

В MySQL 5.6, видимости к сеансам max_binlog_cache_size соответствия тот из binlog_cache_size системная переменная; другими словами изменяя его эффекты значения только новые сеансы, которые запускаются после значения, изменяются.

max_binlog_size

Если запись к двоичному журналу заставляет текущий размер файла журнала превышать значение этой переменной, сервер вращается, двоичные журналы (закрывает текущий файл и открывает следующий). Минимальное значение составляет 4096 байтов. Максимальное и значение по умолчанию составляет 1 Гбайт.

Транзакция пишется в одном блоке двоичному журналу, таким образом, это никогда не разделяется между несколькими двоичными журналами. Поэтому, если у Вас есть большие транзакции, Вы могли бы видеть двоичные файлы журнала, больше чем max_binlog_size.

Если max_relay_log_size 0, значение max_binlog_size применяется к релейным журналам также.

max_binlog_stmt_cache_size

Если нетранзакционные операторы в пределах транзакции требуют больше чем это много байтов памяти, сервер генерирует ошибку. Минимальное значение 4096. Максимальные и значения по умолчанию составляют 4 Гбайт на 32-разрядных платформах и 16EB (эксабайты) на 64-разрядных платформах.

max_binlog_stmt_cache_size устанавливает размер для кэша оператора только; верхним пределом для кэша транзакции управляют исключительно max_binlog_cache_size системная переменная.

sync_binlog

Если значение этой переменной больше чем 0, сервер MySQL синхронизирует свой двоичный журнал с диском (использование fdatasync()) после sync_binlog группы фиксации пишутся двоичному журналу. Значение по умолчанию sync_binlog 0, который не делает никакой синхронизации с диском — в этом случае, сервер полагается на операционную систему, чтобы время от времени сбрасывать содержание двоичного журнала что касается любого другого файла. Значение 1 является самым безопасным выбором, потому что в случае катастрофического отказа Вы теряете самое большее одну группу фиксации от двоичного журнала. Однако, это - также самый медленный выбор (если у диска нет поддержанного батареей кэша, который делает синхронизацию очень быстро).