--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.

Когда нет базовой базы данных, не применяется никаких параметров --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 установленной в ON), для каждого клиента выделяется кэш двоичного журнала, если сервер поддерживает какие-либо транзакционные хранилища данных. Если данные для транзакции превышают объем буфера памяти, избыточные данные сохраняются во временном файле. При активном шифровании двоичного журнала на сервере буфер памяти не шифруется, но любой временный файл, используемый для хранения кэша двоичного журнала, шифруется. После завершения каждой транзакции кэш двоичного журнала сбрасывается путём очистки буфера памяти и обнуления временного файла, если он использовался.

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

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

binlog_checksum

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

Установка этой переменной на источнике в значение, не распознаваемое репликой, заставляет реплику установить собственное значение binlog_checksum в NONE и остановить репликацию с ошибкой. Если вы беспокоитесь о совместимости со старыми репликами, вы можете явно установить значение на NONE.

Группа репликации в MySQL 9.2 поддерживает контрольные суммы, поэтому члены группы могут использовать значение по умолчанию.

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

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

binlog_direct_non_transactional_updates

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

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

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

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

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

binlog_encryption

Включает шифрование для файлов двоичного журнала и файлов журнала репликации на этом сервере. По умолчанию значение равно OFF. ON включает шифрование для файлов двоичного журнала и файлов журнала репликации. Для включения шифрования не нужно включать двоичный протокол логирования на сервере, поэтому вы можете зашифровать файлы журнала репликации на реплике, у которой нет двоичного журнала. Для использования шифрования необходимо установить и настроить плагин keyring для предоставления MySQL Server’s keyring service. Инструкции по этому поводу см. в разделе 8.4.4, «MySQL Keyring». Любой поддерживаемый плагин keyring может использоваться для хранения ключей шифрования двоичного журнала.

При первом запуске сервера с включённым шифрованием двоичного журнала, перед инициализацией двоичного журнала и журнала репликации генерируется новый ключ шифрования двоичного журнала. Этот ключ используется для шифрования пароля файла для каждого файла двоичного журнала (если на сервере включено двоичное протоколирование) и файла журнала репликации (если на сервере включены каналы репликации), а дополнительные ключи, сгенерированные из паролей файлов, используются для шифрования данных в файлах. Файлы журнала репликации шифруются для всех каналов, включая каналы применения Group Replication и новые каналы, созданные после активации шифрования. Файлы индексов двоичного журнала и журнала репликации никогда не шифруются.

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

Если вы деактивируете шифрование, изменив системную переменную binlog_encryption на OFF, файл двоичного журнала и файлы журнала репликации будут сразу же переротаны, и всё последующее протоколирование будет без шифрования. Ранее зашифрованные файлы не будут автоматически расшифрованы, но сервер по-прежнему сможет их прочитать. Для активации или деактивации шифрования во время работы сервера требуется привилегия BINLOG_ENCRYPTION_ADMIN (или устаревшая привилегия SUPER). Каналы приложения Group Replication не включены в запрос переротации журнала репликации, поэтому протоколирование без шифрования для этих каналов не начнется, пока их журналы не будут переротированы в ходе нормальной работы.

Дополнительную информацию о шифровании файлов двоичного журнала и файлов журнала репликации см. в разделе 19.3.2, «Шифрование файлов двоичного журнала и файлов журнала репликации».

binlog_error_action

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

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

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

binlog_expire_logs_seconds

Устанавливает период истечения срока действия двоичного журнала в секундах. По истечении срока действия файлы двоичного журнала могут быть автоматически удалены. Возможные удаления происходят при запуске и при сбросе двоичного журнала. Сброс журнала происходит, как указано в разделе 7.4, «Журналы MySQL Server».

По умолчанию период истечения срока действия двоичного журнала составляет 2592000 секунд, что равно 30 дням (30*24*60*60 секунд).

Автоматическое удаление двоичного журнала можно отключить, установив системную переменную binlog_expire_logs_auto_purge в значение OFF. Это имеет приоритет над любым значением для binlog_expire_logs_seconds.

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

binlog_expire_logs_auto_purge

Включает или отключает автоматическое удаление файлов двоичного журнала. Установка этой переменной в значение ON (по умолчанию) включает автоматическое удаление; установка в значение OFF отключает автоматическое удаление. Интервал ожидания перед удалением управляется переменной binlog_expire_logs_seconds.

Эта переменная не влияет на PURGE BINARY LOGS.

binlog_format

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

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

Значение по умолчанию — ROW. Исключение: в NDB Cluster значение по умолчанию — MIXED; репликация на основе утверждений не поддерживается для NDB Cluster.

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

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

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

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

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

Попытка переключения формата репликации в любом из этих случаев (или попытка установить текущий формат репликации) приведёт к ошибке. Однако можно использовать PERSIST_ONLY (SET @@PERSIST_ONLY.binlog_format), чтобы изменить формат репликации в любое время, так как это действие не изменяет текущее значение глобальной системной переменной и вступает в силу только после перезапуска сервера.

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

Изменение формата протоколирования на сервере-источнике не приводит к изменению формата протоколирования у реплики. Переключение формата репликации во время работы репликации может вызвать проблемы, если у реплики включено двоичное протоколирование, и изменение приводит к тому, что у реплики используется STATEMENT формат протоколирования, в то время как у источника используется ROW или MIXED формат протоколирования. Реплика не может преобразовать записи двоичного журнала, полученные в формате протоколирования ROW, в формат STATEMENT для использования в своём собственном двоичном журнале, поэтому такая ситуация может привести к сбою репликации. Для получения дополнительной информации см. Раздел 7.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 может увеличить количество параллельных транзакций, фиксируемых на любом сервере, который имеет (или может иметь после отключения) реплику, и, следовательно, может увеличить параллельное выполнение на репликах. При настройке 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

binlog_max_flush_queue_time устарело и будет удалено в будущих версиях MySQL. Ранее эта системная переменная контролировала время в микросекундах для продолжения чтения транзакций из очереди сброса перед продолжением группового подтверждения. Сейчас она не оказывает никакого влияния.

binlog_order_commits

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

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

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

binlog_rotate_encryption_master_key_at_startup

Указывает, вращается ли главный ключ шифрования двоичного журнала при запуске сервера. Главный ключ шифрования двоичного журнала — это ключ шифрования двоичного журнала, используемый для шифрования паролей файлов двоичного журнала и файлов репликации на сервере. При первом запуске сервера с включенным шифрованием двоичного журнала (binlog_encryption=ON) генерируется новый ключ шифрования двоичного журнала и используется в качестве главного ключа шифрования двоичного журнала. Если системная переменная binlog_rotate_encryption_master_key_at_startup также установлена в ON, при каждом перезапуске сервера генерируется дополнительный ключ шифрования двоичного журнала и используется в качестве главного ключа шифрования двоичного журнала для всех последующих файлов двоичного журнала и файлов репликации. Если системная переменная binlog_rotate_encryption_master_key_at_startup установлена в OFF, что является значением по умолчанию, существующий главный ключ шифрования двоичного журнала используется повторно после перезапуска сервера. Для получения дополнительной информации о ключах шифрования двоичного журнала и главном ключе шифрования двоичного журнала см. Раздел 19.3.2, «Шифрование файлов двоичного журнала и файлов репликации».

binlog_row_event_max_size

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

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

binlog_row_image

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

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

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

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

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

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

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

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

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

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

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

binlog_row_metadata

Настраивает объём метаданных таблицы, добавляемых в двоичный журнал при использовании протоколирования на основе строк. При установке в MINIMAL, по умолчанию, логируются только метаданные, относящиеся к SIGNED флагам, набору символов столбцов и типам геометрий. При установке в FULL протоколируется полная информация о метаданных таблиц, например имя столбца, ENUM или SET строковые значения, информация PRIMARY KEY и т. д.

Расширенные метаданные служат следующим целям:

binlog_row_value_options

При установке в значение PARTIAL_JSON, это включает использование эффективного по объему формата двоичного журнала для обновлений, которые изменяют только небольшую часть JSON-документа, что заставляет строчную репликацию записывать в послеобразе обновления в двоичном журнале только измененные части JSON-документа, а не весь документ (см. Частичные обновления значений JSON). Это работает для оператора UPDATE, который изменяет столбец JSON с помощью любой последовательности JSON_SET(), JSON_REPLACE() и JSON_REMOVE(). Если сервер не может сгенерировать частичное обновление, используется весь документ.

Значение по умолчанию — пустая строка, что отключает использование формата. Чтобы сбросить binlog_row_value_options и вернуться к записи всего JSON-документа, установите его значение в пустую строку.

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

binlog_row_value_options=PARTIAL_JSON вступает в силу только при включенном ведении двоичного журнала и binlog_format установлено в значение ROW или MIXED. Репликация на основе операторов всегда записывает только измененные части JSON-документа, независимо от любого значения, установленного для binlog_row_value_options. Для максимального сокращения занимаемого пространства используйте binlog_row_image=NOBLOB или binlog_row_image=MINIMAL вместе с этим параметром. binlog_row_image=FULL занимает меньше места, чем любой из этих, поскольку полный JSON-документ хранится в предобразе, а частичное обновление — только в послеобразе.

Вывод mysqlbinlog включает частичные обновления JSON в виде событий, закодированных как строки base-64 с использованием операторов BINLOG. Если указан параметр --verbose, mysqlbinlog отображает частичные обновления JSON как читаемый JSON с использованием псевдо-SQL операторов.

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

binlog_rows_query_log_events

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

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

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

binlog_stmt_cache_size

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

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

Если вы часто используете большие нетранзакционные операторы во время транзакций, вы можете увеличить размер этого кэша, чтобы повысить производительность, уменьшив или устранив необходимость записи во временные файлы. Переменные состояния Binlog_stmt_cache_use и Binlog_stmt_cache_disk_use могут быть полезны для настройки размера этой переменной. См. Раздел 7.4.4, «Двоичный журнал».

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

binlog_transaction_compression

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

Установка binlog_transaction_compression не оказывает немедленного влияния, а применяется ко всем последующим операциям START REPLICA.

Когда включено сжатие бинарных журналов транзакций, данные транзакции сжимаются, а затем записываются в файл бинарного журнала как одно событие (Transaction_payload_event). Сжатые данные транзакций остаются в сжатом состоянии, пока они отправляются в поток репликации репликам, другим членам группы Group Replication или клиентам, таким как mysqlbinlog, и записываются в релейный журнал по-прежнему в сжатом виде. Сжатие бинарных журналов транзакций, таким образом, экономит место на диске как у источника транзакции, так и у получателя (а также для их резервных копий), а также экономит полосу пропускания сети при отправке транзакций между серверными экземплярами.

Для того, чтобы binlog_transaction_compression=ON имело непосредственное воздействие, необходимо включить ведение бинарного журнала на сервере. Если на экземпляре MySQL 9.2 сервера нет бинарного журнала, он может принимать, обрабатывать и отображать сжатые данные транзакций независимо от значения binlog_transaction_compression. Сжатые данные транзакций, полученные такими серверными экземплярами, записываются в сжатом виде в релейный журнал, так что они косвенно получают выгоду от сжатия, выполненного другими серверами в топологии репликации.

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

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

Вы можете использовать системную переменную ndb_log_transaction_compression, чтобы включить эту функцию для NDB. Кроме того, установка --binlog-transaction-compression=ON в командной строке или в файле my.cnf приводит к включению ndb_log_transaction_compression при запуске сервера. Дополнительную информацию см. в описании переменной.

binlog_transaction_compression_level_zstd

Устанавливает уровень сжатия для сжатия бинарных журналов транзакций на этом сервере, который включен системной переменной binlog_transaction_compression. Значение — целое число, определяющее сложность сжатия от 1 (наименьшая сложность) до 22 (наибольшая сложность). Если вы не укажете эту системную переменную, уровень сжатия устанавливается в 3.

Установка binlog_transaction_compression_level_zstd не оказывает немедленного влияния, а применяется ко всем последующим операциям START REPLICA.

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

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

Эта переменная не влияет на запись транзакций в таблицы NDB; используйте ndb_log_transaction_compression_level_zstd вместо этого.

binlog_transaction_dependency_history_size

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

log_bin

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

В более ранних версиях MySQL ведение бинарного журнала было отключено по умолчанию, и включалось, если вы указывали опцию --log-bin. Ведение бинарного журнала включено по умолчанию, с системной переменной log_bin установленной в ON, независимо от того, указали вы опцию --log-bin или нет. Исключением является случай, когда вы используете mysqld для ручного инициализации каталога данных, вызвав его с опцией --initialize или --initialize-insecure, когда ведение бинарного журнала отключено по умолчанию. В этом случае можно включить ведение бинарного журнала, указав опцию --log-bin.

Если опция --skip-log-bin или --disable-log-bin указана при запуске, ведение бинарного журнала отключено, с системной переменной log_bin установленной в OFF. Если указана любая из этих опций, и также указана опция --log-bin, то применяется опция, указанная позже.

Информацию о формате и управлении бинарным журналом см. в Разделе 7.4.4, «Бинарный журнал».

log_bin_basename

Содержит имя и путь к файлам бинарного журнала, которые можно задать с помощью серверного параметра --log-bin. Максимальная длина переменной составляет 256 символов. В MySQL 9.2, если параметр --log-bin не указан, используется имя по умолчанию binlog. Для совместимости с MySQL 5.7, если параметр --log-bin указан без строки или со значением пустой строки, используется имя по умолчанию host_name-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 не накладывает этих ограничений на создание хранимых функций. Эта переменная также применяется к созданию триггеров. См. Раздел 27.8, “Протоколирование бинарных данных хранимых процедур”.

log_replica_updates

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

Включение этой переменной заставляет реплику записывать обновления, полученные от источника и выполненные репликационным SQL-потоком, в собственный бинарный журнал реплики. Бинарное протоколирование, которое управляется параметром --log-bin и включено по умолчанию, также должно быть включено на реплике для протоколирования обновлений. См. Раздел 19.1.6, “Параметры и переменные репликации и бинарного протоколирования”. log_replica_updates включено по умолчанию, если вы не укажете --skip-log-bin для отключения бинарного протоколирования, в этом случае MySQL также отключает протоколирование обновлений реплики по умолчанию. Если вам нужно отключить протоколирование обновлений реплики при включённом бинарном протоколировании, укажите --log-replica-updates=OFF при запуске сервера репликации.

Включение log_replica_updates позволяет цепочку серверов репликации. Например, вы можете настроить сервера репликации таким образом:

A -> B -> C

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

log_slave_updates

Устаревшее псевдоним для log_replica_updates.

log_statements_unsafe_for_binlog

При возникновении ошибки 1592 управляет добавлением предупреждений в журнал ошибок.

master_verify_checksum

Устаревшее псевдоним для source_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 ГБ. Для зашифрованных файлов бинарного лога имеется дополнительный заголовок размером 512 байт, который включен в max_binlog_size.

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

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

При использовании GTID на сервере, когда достигнуто значение max_binlog_size, если системная таблица mysql.gtid_executed недоступна для записи GTID из текущего файла бинарного лога, бинарный лог не может быть переключен. В этой ситуации сервер реагирует в соответствии с настройкой binlog_error_action. Если IGNORE_ERROR установлено, на сервере регистрируется ошибка, и ведение бинарного лога останавливается, или если ABORT_SERVER установлено, сервер завершается.

max_binlog_stmt_cache_size

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

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

original_commit_timestamp

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

Установка значения сеанса этой системной переменной — это ограниченная операция. Пользователь сеанса должен иметь либо привилегию REPLICATION_APPLIER (см. Раздел 19.3.3, «Проверки привилегий репликации»), либо привилегии, достаточные для установки ограниченных переменных сеанса (см. Раздел 7.1.9.1, «Привилегии на системные переменные»). Однако обратите внимание, что переменная не предназначена для установки пользователями; она устанавливается автоматически инфраструктурой репликации.

source_verify_checksum

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

sql_log_bin

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

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

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

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

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

sync_binlog

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

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