binlog_gtid_simple_recovery

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

Когда binlog_gtid_simple_recovery=TRUE (значение по умолчанию), значения gtid_executed и gtid_purged вычисляются при запуске на основе значений Previous_gtids_log_event в последних и самых старых двоичных журналах. Описание вычисления см. в переменной системы gtid_purged. Это значение обрабатывает только два двоичных журнала во время перезапуска сервера. Если все двоичные журналы на сервере были сгенерированы с MySQL 5.7.8 или более поздней версии, binlog_gtid_simple_recovery=TRUE всегда можно безопасно использовать.

Если на сервере присутствуют двоичные журналы из MySQL 5.7.7 или более ранних версий (например, после обновления старого сервера до MySQL 8.4), с binlog_gtid_simple_recovery=TRUE, gtid_executed и gtid_purged могут быть инициализированы неправильно в следующих двух ситуациях:

Если набор GTID вычислен неправильно в любой из ситуаций, он остаётся неверным, даже если сервер позже перезапускается с binlog_gtid_simple_recovery=FALSE. Если любая из этих ситуаций актуальна или может быть актуальной на сервере, установите binlog_gtid_simple_recovery=FALSE перед запуском или перезапуском сервера.

Когда binlog_gtid_simple_recovery=FALSE установлено, метод вычисления gtid_executed и gtid_purged, как описано в переменной системы gtid_purged, изменяется на итерацию двоичных журналов следующим образом:

enforce_gtid_consistency

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

Значения, в которые можно настроить enforce_gtid_consistency, следующие:

--enforce-gtid-consistency вступает в силу только в том случае, если двоичный журнал ведётся для инструкции. Если двоичный журнал отключён на сервере, или если инструкции не записаны в двоичный журнал, потому что они удалены фильтром, согласованность GTID не проверяется и не навязывается для инструкций, которые не записаны.

Только инструкции, которые могут быть записаны с помощью безопасных для GTID инструкций, могут быть записаны, когда enforce_gtid_consistency установлено в ON, поэтому следующие операции нельзя использовать с этим параметром:

Дополнительную информацию см. в разделе 19.1.3.7 «Ограничения на репликацию с GTID».

Перед MySQL 5.7 и в ранних выпусках этой версии, булево enforce_gtid_consistency по умолчанию было OFF. Для поддержания совместимости с более ранними версиями, перечисление по умолчанию установлено в OFF, и установка --enforce-gtid-consistency без значения интерпретируется как установка значения в ON. Переменная также имеет несколько текстовых псевдонимов для значений: 0=OFF=FALSE, 1=ON=TRUE,2=WARN. Это отличается от других типов перечислений, но сохраняет совместимость с типом булевых переменных, использовавшимся в предыдущих выпусках. Эти изменения влияют на то, что возвращается переменной. Использование SELECT @@ENFORCE_GTID_CONSISTENCY, SHOW VARIABLES LIKE 'ENFORCE_GTID_CONSISTENCY' и SELECT * FROM INFORMATION_SCHEMA.VARIABLES WHERE 'VARIABLE_NAME' = 'ENFORCE_GTID_CONSISTENCY' возвращает текстовую форму, а не числовую. Это несовместимое изменение, так как @@ENFORCE_GTID_CONSISTENCY возвращает числовую форму для булевых значений, но возвращает текстовую форму для SHOW и схемы информации.

gtid_executed

При использовании в глобальной области эта переменная содержит представление набора всех транзакций, выполненных на сервере, и GTID, которые были заданы с помощью инструкции SET gtid_purged. Это то же значение, что и в столбце Executed_Gtid_Set результата выполнения команд SHOW BINARY LOG STATUS и SHOW REPLICA STATUS. Значение этой переменной — множество GTID, см. Наборы GTID для получения дополнительной информации.

При запуске сервера @@GLOBAL.gtid_executed инициализируется. См. binlog_gtid_simple_recovery для получения дополнительной информации о том, как итерационно просматриваются бинарные логи для заполнения gtid_executed. Затем GTID добавляются в набор по мере выполнения транзакций или при выполнении какой-либо инструкции SET gtid_purged.

Набор транзакций, которые могут быть найдены в бинарных логах в любой момент времени, равен GTID_SUBTRACT(@@GLOBAL.gtid_executed, @@GLOBAL.gtid_purged), то есть всем транзакциям в бинарном логе, которые еще не были удалены.

Выполнение RESET BINARY LOGS AND GTIDS приводит к сбросу значения этой переменной до пустой строки. GTID не удаляются из этого набора иначе, кроме как при его очистке из-за RESET BINARY LOGS AND GTIDS.

gtid_executed_compression_period

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

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

Все транзакции (независимо от хранилища данных) записываются в таблицу mysql.gtid_executed одним и тем же процессом, и значение по умолчанию gtid_executed_compression_period — 0.

См. Сжатие таблицы mysql.gtid_executed для получения дополнительной информации.

gtid_mode

Управляет включением ведения журнала на основе GTID и типом транзакций, которые могут содержаться в логах. Вам необходимо иметь права, достаточные для установки глобальных переменных системы. См. Раздел 7.1.9.1, «Права на переменные системы». enforce_gtid_consistency должна быть установлена в ON перед установкой gtid_mode=ON. Перед изменением этой переменной см. Раздел 19.1.4, «Изменение режима GTID на работающих серверах».

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

Переход от одного значения к другому может осуществляться только по одному шагу. Например, если gtid_mode в настоящее время имеет значение OFF_PERMISSIVE, можно перейти к OFF или ON_PERMISSIVE, но не к ON.

Значения gtid_purged и gtid_executed сохраняются независимо от значения gtid_mode. Поэтому даже после изменения значения gtid_mode эти переменные содержат правильные значения.

gtid_next

Эта переменная используется для указания, как получить следующий GTID (см. Раздел 19.1.3, «Репликация с глобальными идентификаторами транзакций»).

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

gtid_next может принимать следующие значения:

Точное количество вариантов, представленных выше, зависит от значения gtid_mode; см. Раздел 19.1.4.1, «Концепции режима репликации» для получения дополнительной информации. Установка этой переменной не имеет эффекта, если gtid_mode имеет значение OFF.

После того, как эта переменная была установлена на UUID:NUMBER или UUID:TAG:NUMBER, и транзакция была подтверждена или отменена, перед выполнением любой другой инструкции необходимо выполнить явную команду SET gtid_next.

DROP TABLE или DROP TEMPORARY TABLE завершается с явным сообщением об ошибке при использовании в сочетании с невременными таблицами и временными таблицами, или временными таблицами, использующими транзакционные хранилища, с временными таблицами, использующими нетранзакционные хранилища.

Для получения дополнительной информации см. Переменную системы gtid_next а также Раздел 19.1.4, «Изменение режима GTID на онлайн-серверах».

gtid_owned

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

gtid_purged

Глобальное значение переменной системы gtid_purged (@@GLOBAL.gtid_purged) — это набор GTID, содержащий GTID всех транзакций, которые были выполнены на сервере, но не существуют ни в одном бинарном журнале на сервере. gtid_purged является подмножеством gtid_executed. Следующие категории GTID находятся в gtid_purged:

При запуске сервера глобальное значение gtid_purged инициализируется набором GTID. Сведения о том, как вычисляется этот набор GTID, можно найти в статье про переменную системы gtid_purged. Если на сервере присутствуют бинарные логи из MySQL 5.7.7 или более ранней версии, возможно, потребуется установить binlog_gtid_simple_recovery=FALSE в файле конфигурации сервера, чтобы получить правильное вычисление. Подробности о ситуациях, когда требуется это задание, можно найти в описании binlog_gtid_simple_recovery.

Для установки gtid_purged необходимо иметь TRANSACTION_GTID_TAG.

Выполнение оператора RESET BINARY LOGS AND GTIDS приводит к сбросу значения gtid_purged до пустой строки.

Вы можете установить значение gtid_purged, чтобы записать на сервере, что транзакции в определённом наборе GTID были применены, хотя они не существуют ни в одном бинарном журнале на сервере. Пример использования — восстановление резервной копии одной или нескольких баз данных на сервере, но при отсутствии соответствующих бинарных журналов, содержащих транзакции на сервере.

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