--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, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

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

USE db4;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.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.7.2 этот параметр приводил к тому, что инструкции, содержащие полные имена таблиц, не протоколировались, если не была указана базовая база данных (то есть, когда SELECT DATABASE() возвращал NULL). В MySQL 5.7.2 и выше, когда базовая база данных не задана, никакие параметры --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_cache_size

Размер кэша для хранения изменений в двоичном журнале во время транзакции.

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

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

binlog_checksum

При включении этой переменной источник записывает контрольную сумму для каждого события в двоичном журнале. binlog_checksum поддерживает значения NONE (выключено) и CRC32. По умолчанию значение CRC32. Вы не можете изменить значение binlog_checksum внутри транзакции.

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

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

Установка этой переменной на источнике в значение, не распознаваемое репликой, приводит к установке репликой своего значения 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, и данный оператор реплицируется в формате на основе строк.

Эта переменная не влияет, когда формат двоичного журнала равен ROW или MIXED.

binlog_error_action

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

В MySQL 5.7.7 и выше эта переменная по умолчанию имеет значение ABORT_SERVER, что заставляет сервер останавливать протоколирование и завершать работу всякий раз, когда он сталкивается с такой ошибкой в двоичном журнале. При перезапуске восстановление происходит так же, как и в случае неожиданной остановки сервера (см. Раздел 16.3.2, «Обработка неожиданной остановки реплики»).

Если binlog_error_action установлено на IGNORE_ERROR, если сервер сталкивается с такой ошибкой, он продолжает текущую транзакцию, записывает ошибку, затем останавливает протоколирование и продолжает выполнение обновлений. Для возобновления двоичного протоколирования необходимо снова включить log_bin, что требует перезапуска сервера. Эта настройка обеспечивает обратную совместимость со старыми версиями MySQL.

В предыдущих выпусках эта переменная называлась binlogging_impossible_mode.

binlog_format

Эта системная переменная задаёт формат бинарного протоколирования и может принимать любое из значений STATEMENT, ROW или MIXED. См. Раздел 16.2.1, «Форматы репликации». Настройка вступает в силу при включении бинарного протоколирования на сервере, что происходит, когда системная переменная log_bin установлена в значение ON. В MySQL 5.7 бинарное протоколирование по умолчанию выключено, и его необходимо включить с помощью опции --log-bin.

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

До MySQL 5.7.7 значением по умолчанию был STATEMENT. В MySQL 5.7.7 и более поздних версиях по умолчанию используется ROW. Исключение: в NDB Cluster значение по умолчанию MIXED; репликация на основе инструкций не поддерживается для NDB Cluster.

Установка значения сеанса этой системной переменной является ограниченной операцией. Пользователь сеанса должен иметь достаточные привилегии для установки ограниченных переменных сеанса. См. Раздел 5.1.8.1, «Привилегии на системные переменные».

Правила, определяющие, когда изменения этой переменной вступают в силу и как долго действует эффект, такие же, как и для других системных переменных MySQL-сервера. Дополнительную информацию см. в Разделе 13.7.4.1, «Синтаксис SET для задания переменных».

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

Подробности о том, как обрабатываются хранимые программы (хранимые процедуры и функции, триггеры и события) при установке каждого формата бинарного протоколирования, см. в Разделе 23.7, «Протоколирование хранимых программ».

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

Попытка изменить формат в этих случаях приводит к ошибке.

Изменение формата протоколирования на сервере источника репликации не приводит к изменению формата протоколирования на реплике. Изменение формата репликации во время работы репликации может вызвать проблемы, если реплика имеет включенное бинарное протоколирование, а изменение приводит к тому, что реплика использует формат STATEMENT протоколирования, в то время как источник использует формат ROW или MIXED. Реплика не может преобразовать записи бинарного лога, полученные в формате ROW протоколирования, в формат STATEMENT для использования в собственном бинарном логе, что может привести к сбою репликации. Дополнительную информацию см. в Разделе 5.4.4.2, «Указание формата бинарного лога».

Формат бинарного лога влияет на поведение следующих параметров сервера:

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

binlog_group_commit_sync_delay

Управляет тем, сколько микросекунд ждёт коммит бинарного лога перед синхронизацией файла бинарного лога с диском. По умолчанию binlog_group_commit_sync_delay установлено в 0, что означает отсутствие задержки. Установка binlog_group_commit_sync_delay на определённую задержку в микросекундах позволяет синхронизировать больше транзакций вместе на диск, уменьшая общее время коммита группы транзакций, так как для больших групп требуется меньше единиц времени на группу.

Когда sync_binlog=0 или sync_binlog=1 установлены, заданная задержка binlog_group_commit_sync_delay применяется для каждой группы коммитов бинарного лога перед синхронизацией (или в случае с sync_binlog=0 — перед продолжением). Когда sync_binlog установлено в значение n больше 1, задержка применяется после каждой n-й группы коммитов бинарного лога.

Установка binlog_group_commit_sync_delay может увеличить количество параллельных транзакций, совершающих коммит на любом сервере, имеющем (или, возможно, получившем после отключения) реплику, и, следовательно, может увеличить параллельное выполнение на репликах. Для получения выгоды от этого эффекта реплики должны иметь установленное значение slave_parallel_type=LOGICAL_CLOCK, и эффект более значителен, когда установлено также binlog_transaction_dependency_tracking=COMMIT_ORDER. Важно учитывать как пропускную способность источника, так и пропускную способность реплик при настройке параметра binlog_group_commit_sync_delay.

Установка binlog_group_commit_sync_delay также может уменьшить число fsync() вызовов бинарного лога на любом сервере (источнике или реплике), имеющем бинарный лог.

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

binlog_group_commit_sync_no_delay_count

Максимальное число транзакций, ожидаемых до отмены текущей задержки, как указано в binlog_group_commit_sync_delay. Если binlog_group_commit_sync_delay установлено в 0, то этот параметр не влияет.

binlog_max_flush_queue_time

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

binlog_max_flush_queue_time устарела с MySQL 5.7.9 и в будущем будет удалена из MySQL.

binlog_order_commits

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

Транзакции записываются в бинарный журнал в тот момент, когда все участвующие движки хранения подтвердили, что транзакция готова к подтверждению. Логика группового подтверждения бинарного журнала затем подтверждает группу транзакций после их записи в бинарный журнал. Когда binlog_order_commits отключена, из-за использования нескольких потоков транзакции в группе подтверждения могут быть подтверждены в ином порядке, нежели в бинарном журнале. (Транзакции от одного клиента всегда подтверждаются в хронологическом порядке.) Во многих случаях это не имеет значения, поскольку операции, выполняемые в отдельных транзакциях, должны давать согласованные результаты, а если это не так, следует использовать одну транзакцию.

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

binlog_row_image

Для репликации MySQL на основе строк эта переменная определяет, как изображения строк записываются в бинарный журнал.

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

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

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

Значение по умолчанию — full.

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

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

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

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

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

binlog_rows_query_log_events

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

Эти информационные события обычно игнорируются программами MySQL, считывающими бинарный журнал, и, таким образом, не вызывают проблем при репликации или восстановлении из резервной копии. Чтобы их просмотреть, увеличьте уровень подробности, используя параметр mysqlbinlog --verbose дважды, либо как -vv, либо как --verbose --verbose.

binlog_stmt_cache_size

Эта переменная определяет размер кэша двоичного журнала для хранения нетранзакционных операторов, выпущенных во время транзакции.

Отдельные кэши транзакций и операторов двоичного журнала выделяются для каждого клиента, если сервер поддерживает какие-либо транзакционные хранилища данных и если на сервере включён двоичный журнал (--log-bin параметр). Если вы часто используете большие нетранзакционные операторы во время транзакций, вы можете увеличить размер этого кэша для повышения производительности. Переменные состояния Binlog_stmt_cache_use и Binlog_stmt_cache_disk_use могут быть полезны для настройки размера этой переменной. См. Раздел 5.4.4, «Двоичный журнал».

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

binlog_transaction_dependency_tracking

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

В режимах WRITESET или WRITESET_SESSION транзакции могут подтверждаться вне очереди, если вы также не установите slave_preserve_commit_order=1.

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

Значение этой переменной не может быть установлено ни на что, кроме COMMIT_ORDER, если transaction_write_set_extraction имеет значение OFF. Также следует отметить, что значение transaction_write_set_extraction нельзя изменить, если текущее значение binlog_transaction_dependency_tracking равно WRITESET или WRITESET_SESSION. Если вы измените значение, новое значение не вступит в силу на репликах до тех пор, пока реплика не будет остановлена и перезапущена с помощью команд STOP SLAVE и START SLAVE.

Количество хешей строк, которые нужно хранить и проверять для последней транзакции, изменившей заданную строку, определяется значением binlog_transaction_dependency_history_size.

binlog_transaction_dependency_history_size

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

expire_logs_days

Количество дней для автоматического удаления файлов двоичного журнала. По умолчанию 0, что означает «автоматическое удаление не производится». Возможные удаления происходят при запуске и при сбросе двоичного журнала. Сброс журнала происходит так, как указано в Раздел 5.4, «Журналы MySQL-сервера».

Для удаления файлов двоичного журнала вручную используйте инструкцию PURGE BINARY LOGS. См. Раздел 13.4.1.1, «Очистка двоичных журналов».

log_bin

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

См. Раздел 5.4.4, «Двоичный журнал».

log_bin_basename

Содержит базовое имя и путь к файлам двоичного журнала, которые могут быть установлены с помощью параметра сервера --log-bin. Максимальная длина переменной — 256. В MySQL 5.7 базовое имя по умолчанию — имя хоста с суффиксом -bin. По умолчанию расположение — директория данных.

log_bin_index

Содержит базовое имя и путь к файлу индекса двоичного журнала, который может быть установлен с помощью параметра сервера --log-bin-index. Максимальная длина переменной — 256.

log_bin_trust_function_creators

Эта переменная применяется, когда вклюжено двоичное журналирование. Она управляет тем, можно ли доверять создателям хранимых функций, чтобы они не создавали хранимые функции, которые приводят к записи небезопасных событий в двоичный журнал. Если установлено значение 0 (по умолчанию), пользователям не разрешается создавать или изменять хранимые функции, если у них нет привилегии SUPER в дополнение к привилегии CREATE ROUTINE или ALTER ROUTINE. Установка значения 0 также обеспечивает ограничение, согласно которому функция должна быть объявлена с характеристикой DETERMINISTIC или с характеристикой READS SQL DATA или NO SQL. Если переменной присвоено значение 1, MySQL не применяет эти ограничения к созданию хранимых функций. Эта переменная также применяется к созданию триггеров. См. Раздел 23.7, «Двоичное журналирование хранимых программ».

log_bin_use_v1_row_events

Используется ли двоичное журналирование версии 2. Если эта переменная равна 0 (отключено, по умолчанию), используются события двоичного журнала версии 2. Если эта переменная равна 1 (включено), сервер записывает двоичный журнал с использованием событий журнала версии 1 (единственная версия событий двоичного журнала, используемая в предыдущих выпусках), и, таким образом, создает двоичный журнал, который может быть прочитан более старыми репликами.

MySQL 5.7 по умолчанию использует события двоичного журнала строк версии 2. Однако события версии 2 не могут быть прочитаны выпусками MySQL Server до MySQL 5.6.6. Включение log_bin_use_v1_row_events заставляет mysqld записывать двоичный журнал с использованием событий журнала версии 1.

Эта переменная доступна только для чтения во время выполнения. Чтобы переключаться между двоичным журналированием событий версии 1 и версии 2, необходимо установить log_bin_use_v1_row_events при запуске сервера.

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

Для получения дополнительной информации см. Раздел 21.7.11, «Разрешение конфликтов репликации NDB Cluster».

log_builtin_as_identified_by_password

Эта переменная влияет на двоичное журналирование операторов управления пользователями. При включении переменная имеет следующие эффекты:

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

log_slave_updates

Следует ли регистрировать обновления, полученные сервером-репликой от исходного сервера, в собственном двоичном журнале реплики.

Обычно реплика не регистрирует в своем собственном двоичном журнале обновления, полученные от исходного сервера. Включение этой переменной заставляет реплику записывать обновления, выполненные ее потоком репликации SQL, в свой собственный двоичный журнал. Для того чтобы этот параметр имел какое-либо значение, реплика также должна быть запущена с параметром --log-bin для включения двоичного журналирования. См. Раздел 16.1.6, «Параметры и переменные репликации и двоичного журналирования».

log_slave_updates включается, когда требуется объединение серверов репликации. Например, может потребоваться настроить серверы репликации, используя следующую схему:

A -> B -> C

Здесь A выступает в качестве источника для реплики B, а B выступает в качестве источника для реплики C. Для того чтобы это работало, B должен быть одновременно источником и репликой. Необходимо запустить как A, так и B с --log-bin для включения двоичного журналирования, а B с включенным log_slave_updates, чтобы обновления, полученные от A, регистрировались B в своем двоичном журнале.

log_statements_unsafe_for_binlog

Если возникает ошибка 1592, управляет тем, добавляются ли сгенерированные предупреждения в журнал ошибок или нет.

master_verify_checksum

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

max_binlog_cache_size

Если для транзакции требуется больше байтов, чем это значение, сервер генерирует ошибку Для многострочной транзакции требуется более 'max_binlog_cache_size' байтов памяти. Когда gtid_mode не ON, рекомендуемое максимальное значение составляет 4 ГБ, так как в этом случае MySQL не может работать с позициями двоичного лога, превышающими 4 ГБ; когда gtid_mode равно ON, это ограничение не применяется, и сервер может работать с позициями двоичного лога произвольного размера.

Если из-за того, что gtid_mode не ON или по какой-либо другой причине вам необходимо гарантировать, что размер двоичного лога не превысит заданного значения maxsize, вы должны установить эту переменную в соответствии с приведенной здесь формулой:

max_binlog_cache_size <
  (((maxsize - max_binlog_size) / max_connections) - 1000) / 1.2

Этот расчет учитывает следующие условия:

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

Видимость 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-битных платформах и 16 ЭБ (эксабайт) на 64-битных платформах.

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

sql_log_bin

Эта переменная определяет, включено ли ведение журнала в двоичный лог для текущей сессии (при условии, что сам двоичный лог включен). Значение по умолчанию равно ON. Для отключения или включения ведения двоичного лога в текущей сессии установите системную переменную сессии sql_log_bin на OFF или ON.

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

Установка значения для этой системной переменной в сессии — это ограниченная операция. Пользователь сессии должен иметь достаточные привилегии для установки ограниченных переменных сессии. См. Раздел 5.1.8.1, «Привилегии системных переменных».

Невозможно установить значение сессии sql_log_bin внутри транзакции или подзапроса.

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

Глобальная переменная sql_log_bin является только для чтения и не может быть изменена. Глобальная область действия устарела; ожидается, что она будет удалена в будущих версиях MySQL.

sync_binlog

Управляет частотой синхронизации двоичного журнала MySQL с диском.

Для максимальной надёжности и согласованности в настройках репликации, использующих InnoDB с транзакциями, используйте следующие настройки:

transaction_write_set_extraction

Определяет алгоритм, используемый для генерации хэша, идентифицирующего записи, связанные с транзакцией. Если вы используете Group Replication, значение хэша используется для обнаружения и обработки конфликтов в распределённой системе. На 64-битных системах, работающих с Group Replication, рекомендуется установить это значение на XXHASH64, чтобы избежать ненужных коллизий хэшей, которые приводят к ошибкам сертификации и откату пользовательских транзакций. См. Раздел 17.3.1, «Требования к Group Replication». binlog_format должно быть установлено на ROW, чтобы изменить значение этой переменной. Если вы измените значение, новое значение не будет применяться на репликах до тех пор, пока реплика не будет остановлена и перезапущена с помощью команд STOP SLAVE и START SLAVE.