7.4.4.5 Binary Log Transaction Compression — MySQL 9.2

7.4.4.5 Сжатие транзакций журнала двоичных логов

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

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

Сжатые данные транзакций разархивируются, когда необходимо просмотреть отдельные события, содержащиеся в них. Например, Transaction_payload_event разархивируется потоком приложения для применения событий, содержащихся в нём, на получателе. Разархивирование также выполняется при восстановлении, командой mysqlbinlog при повторном воспроизведении транзакций и операторами SHOW BINLOG EVENTS и SHOW RELAYLOG EVENTS.

Вы можете включить сжатие транзакций журнала двоичных логов на экземпляре сервера MySQL с помощью системной переменной binlog_transaction_compression, значение которой по умолчанию равно OFF. Вы также можете использовать системную переменную binlog_transaction_compression_level_zstd, чтобы установить уровень для алгоритма zstd, используемого для сжатия. Это значение определяет интенсивность сжатия от 1 (минимальная интенсивность) до 22 (максимальная интенсивность). По мере увеличения уровня сжатия увеличивается коэффициент сжатия, что уменьшает занимаемое место на диске и пропускную способность сети, необходимую для данных транзакции. Однако возрастает и интенсивность работы по сжатию данных, затрачивается время и ресурсы процессора и оперативной памяти на исходном сервере. Увеличение интенсивности сжатия не имеет линейной зависимости от увеличения коэффициента сжатия.

Установка переменных binlog_transaction_compression или binlog_transaction_compression_level_zstd (или обеих) не имеет немедленного эффекта, а применяется ко всем последующим операторам START REPLICA.

Примечание

Вы можете включить двоичный лог сжатых транзакций для таблиц, использующих хранилище NDB, во время выполнения, используя системную переменную ndb_log_transaction_compression, и управлять уровнем сжатия с помощью ndb_log_transaction_compression_level_zstd. Запуск mysqld с параметром --binlog-transaction-compression в командной строке или в файле конфигурации my.cnf приводит к автоматическому включению ndb_log_transaction_compression, и любые настройки параметра --ndb-log-transaction-compression игнорируются; чтобы отключить сжатие транзакций журнала двоичных логов только для хранилища NDB, установите ndb_log_transaction_compression=OFF в клиентской сессии после запуска mysqld.

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

События, относящиеся к идентификатору GTID для транзакции (включая анонимные события GTID).
Другие типы управляющих событий, такие как события изменения представления и события ожидания.
События инцидентов и все транзакции, которые их содержат.
Нетранзакционные события и все транзакции, которые их содержат. Транзакция, включающая смесь нетранзакционных и транзакционных хранилищ, не сжимает свои данные.
События, записанные с использованием statement-based двоичного протокола логов. Сжатие транзакций журнала двоичных логов применяется только для формата двоичного протокола логов на основе строк.

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

7.4.4.5.1 Поведение при включенном сжатии транзакций журнала двоичных логов

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

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

Важно

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

Для многопотоковых рабочих процессов каждая транзакция (включая её событие GTID и Transaction_payload_event) назначается рабочему потоку. Рабочий поток разархивирует данные транзакции и применяет отдельные события в ней по одному. Если при применении любого события в Transaction_payload_event обнаруживается ошибка, вся транзакция сообщается координатору как провалившаяся. При установке replica_parallel_type или replica_parallel_type в значение DATABASE все базы данных, затронутые транзакцией, сопоставляются перед планированием транзакции. Использование сжатия транзакций журнала двоичных логов с политикой DATABASE может уменьшить параллелизм по сравнению с несжатыми транзакциями, которые сопоставляются и планируются для каждого события.

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

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

Для операторов SHOW BINLOG EVENTS и SHOW RELAYLOG EVENTS Transaction_payload_event сначала выводится как единое целое, а затем распаковывается, и каждое событие внутри него выводится.

Для операций, ссылающихся на конечную позицию события, таких как START REPLICA с условием UNTIL, SOURCE_POS_WAIT() и sql_replica_skip_counter, необходимо указать конечную позицию сжатых данных транзакции (Transaction_payload_event). При пропускании событий с помощью sql_replica_skip_counter, сжатые данные транзакции считаются одним значением счётчика, поэтому все события внутри него пропускаются как единое целое.

7.4.4.5.2 Объединение сжатых и несжатых данных транзакций журнала бинарных логов

Серверы MySQL, поддерживающие сжатие транзакций в журнале бинарных логов, могут обрабатывать смесь сжатых и несжатых данных транзакций.

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

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

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

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

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

7.4.4.5.3 Мониторинг сжатия транзакций журнала бинарных логов

Вы можете отслеживать эффекты сжатия транзакций журнала бинарных логов, используя таблицу Performance Schema binary_log_transaction_compression_stats. Статистика включает коэффициент сжатия данных за отслеживаемый период, и вы также можете увидеть эффект сжатия на последней транзакции на сервере. Вы можете сбросить статистику, удалив таблицу. Статистика для журналов бинарных логов и журналов ретрансляции разделена, чтобы вы могли увидеть влияние сжатия для каждого типа журнала. Для получения этой статистики экземпляр сервера MySQL должен иметь журнал бинарных логов.

Таблица Performance Schema events_stages_current показывает, когда транзакция находится на стадии распаковки или сжатия своих данных транзакции и отображает ее прогресс на этой стадии. Сжатие выполняется рабочей нитью, обрабатывающей транзакцию, непосредственно перед подтверждением транзакции, при условии, что нет событий в кэше окончательного захвата, исключающих транзакцию из сжатия транзакций журнала бинарных логов (например, событий инцидентов). При необходимости распаковки она выполняется для одного события из данных транзакции за раз.

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

Вы можете включить сжатие соединений на уровне протокола для подключений репликации, используя опции SOURCE_COMPRESSION_ALGORITHMS и SOURCE_ZSTD_COMPRESSION_LEVEL оператора CHANGE REPLICATION SOURCE TO или переменную системы replica_compressed_protocol. Если вы включите сжатие транзакций журнала бинарных логов в системе, где также включено сжатие соединений, влияние сжатия соединений уменьшается, так как может быть мало возможностей для дальнейшего сжатия уже сжатых данных транзакций. Тем не менее, сжатие соединений может всё ещё работать со несжатыми событиями и заголовками сообщений. Сжатие транзакций журнала бинарных логов можно включить в сочетании со сжатием соединений, если вам нужно сохранить место на диске и пропускную способность сети. Дополнительную информацию о сжатии соединений для подключений репликации см. в разделе 6.2.8, «Управление сжатием соединений».

Для Group Replication сжатие включено по умолчанию для сообщений, превышающих порог, установленный переменной системы group_replication_compression_threshold. Вы также можете настроить сжатие сообщений, отправляемых для распределённого восстановления, путём переноса состояния из журнала бинарных логов донора, используя переменные системы group_replication_recovery_compression_algorithms и group_replication_recovery_zstd_compression_level. Если вы включите сжатие транзакций журнала бинарных логов в системе, где это настроено, сжатие сообщений Group Replication всё ещё может работать со несжатыми событиями и заголовками сообщений, но его влияние уменьшается. Дополнительную информацию о сжатии сообщений для Group Replication см. в разделе 20.7.4, «Сжатие сообщений».