--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 8.4 поддерживает контрольные суммы, поэтому участники группы могут использовать значение по умолчанию.

Изменение значения 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.

Формат двоичного журнала

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

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

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

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

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

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

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

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

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

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

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

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

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

Задержка синхронизации групповой фиксации двоичного журнала

Управляет количеством микросекунд, которые ожидает фиксация двоичного журнала, прежде чем синхронизировать файл двоичного журнала на диск. По умолчанию 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 на основе строк каждый событие изменения строки содержит два изображения: «до» (before), столбцы которого сопоставляются при поиске строки, подлежащей обновлению, и «после» (after), содержащее изменения. Обычно 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 8.4 сервера не имеет бинарного журнала, он может принимать, обрабатывать и отображать сжатые данные транзакций независимо от значения 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 8.4, если параметр --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.7, «Двоичное протоколирование хранимых программ».

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 с транзакциями, используйте следующие значения: