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

Стандартные пространства имен undo создаются в месте, определённом переменной innodb_undo_directory. Если переменная innodb_undo_directory не определена, стандартные пространства имен undo создаются в каталоге данных. Файлы данных стандартных пространств имен undo имеют имена undo_001 и undo_002. Соответствующие имена пространств имен undo, определённые в словаре данных, — innodb_undo_001 и innodb_undo_002.

Дополнительные пространства имен undo могут быть созданы во время выполнения с помощью SQL-выражений. См. Добавление пространств имен undo.

Начальный размер пространства имени undo обычно составляет 16 МБ. Начальный размер может отличаться, когда новое пространство имени undo создаётся операцией обрезки. В этом случае, если размер расширения файла больше 16 МБ, и предыдущее расширение произошло в течение последней секунды, новое пространство имени undo создаётся с размером, составляющим четверть размера, определённого переменной innodb_max_undo_log_size.

Пространство имени undo расширяется как минимум на 16 МБ. Для обработки агрессивного роста размер расширения файла удваивается, если предыдущее расширение произошло менее чем за 0,1 секунды. Удвоение размера расширения может происходить несколько раз до максимального значения 256 МБ. Если предыдущее расширение произошло более 0,1 секунды назад, размер расширения уменьшается вдвое, что также может происходить несколько раз до минимального значения 16 МБ. Если для пространства имени undo определён параметр AUTOEXTEND_SIZE, оно расширяется до большего из значений AUTOEXTEND_SIZE и размера расширения, определённого описанной выше логикой. Сведения о параметре AUTOEXTEND_SIZE см. в Разделе 17.6.3.9, «Настройка размера AUTOEXTEND_SIZE табличного пространства».

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

CREATE UNDO TABLESPACE tablespace_name ADD DATAFILE 'file_name.ibu';

Имя файла пространства имени undo должно иметь расширение .ibu. Не разрешается указывать относительный путь при определении имени файла пространства имени undo. Разрешается использование полного пути, но путь должен быть известен InnoDB. Известные пути — те, которые определены переменной innodb_directories. Рекомендуется использовать уникальные имена файлов пространств имен undo для предотвращения потенциальных конфликтов имён файлов при перемещении или клонировании данных.

При запуске сканируются каталоги, определённые переменной innodb_directories, на предмет файлов пространств имен undo. (Сканирование также проходит по подкаталогам.) Каталоги, определённые переменными innodb_data_home_dir, innodb_undo_directory и datadir, автоматически добавляются в значение innodb_directories, независимо от того, определена ли переменная innodb_directories явно. Следовательно, пространство имени undo может находиться в путях, определённых любыми из этих переменных.

Если имя файла пространства имени undo не содержит путь, пространство имени undo создаётся в каталоге, определённом переменной innodb_undo_directory. Если эта переменная не определена, пространство имени undo создаётся в каталоге данных.

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

Чтобы просмотреть имена и пути пространств имен undo, запросите данные из таблицы INFORMATION_SCHEMA.FILES:

SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES
  WHERE FILE_TYPE LIKE 'UNDO LOG';

Экземпляр MySQL поддерживает до 127 пространств имен undo, включая два стандартных пространства имен undo, созданных при инициализации экземпляра MySQL.

Пространства имен undo могут быть удалены с помощью синтаксиса DROP UNDO TABALESPACE. См. Удаление пространств имен undo.

Пространства таблиц отката, созданные с помощью синтаксиса CREATE UNDO TABLESPACE, могут быть удалены во время работы с помощью синтаксиса DROP UNDO TABALESPACE.

Пространство таблиц отката должно быть пустым перед удалением. Чтобы очистить пространство таблиц отката, его сначала нужно пометить как неактивное, используя синтаксис ALTER UNDO TABLESPACE, чтобы пространство таблиц больше не использовалось для назначения сегментов отката новым транзакциям.

ALTER UNDO TABLESPACE tablespace_name SET INACTIVE;

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

DROP UNDO TABLESPACE tablespace_name;

Состояние пространства таблиц отката можно отслеживать, запросив таблицу схемы информации INNODB_TABLESPACES.

SELECT NAME, STATE FROM INFORMATION_SCHEMA.INNODB_TABLESPACES
  WHERE NAME LIKE 'tablespace_name';

Состояние inactive указывает, что сегменты отката в пространстве таблиц отката больше не используются новыми транзакциями. Состояние empty указывает, что пространство таблиц отката пустое и готово к удалению или к повторной активации с помощью оператора ALTER UNDO TABLESPACE tablespace_name SET ACTIVE. Попытка удалить пространство таблиц отката, которое не пустое, возвращает ошибку.

Значения по умолчанию пространств таблиц отката (innodb_undo_001 и innodb_undo_002), созданные при инициализации экземпляра MySQL, удалить нельзя. Однако их можно сделать неактивными с помощью оператора ALTER UNDO TABLESPACE tablespace_name SET INACTIVE. Перед тем, как сделать неактивным пространство таблиц отката по умолчанию, должно существовать другое пространство таблиц отката. В любое время должно быть как минимум два активных пространства таблиц отката для поддержки автоматического усечения пространств таблиц отката.

Пространства таблиц отката, созданные с помощью синтаксиса CREATE UNDO TABLESPACE, могут быть перемещены при выключенном сервере в любой известный каталог. Известными каталогами являются те, которые определены переменной innodb_directories. Каталоги, определенные переменными innodb_data_home_dir, innodb_undo_directory и datadir, автоматически добавляются к значению innodb_directories, независимо от того, определена ли переменная innodb_directories явно. Эти каталоги и их подкаталоги сканируются при запуске для поиска файлов пространств таблиц отката. Файл пространства таблиц отката, перемещенный в любой из этих каталогов, обнаруживается при запуске и предполагается, что это то пространство таблиц отката, которое было перемещено.

Пространства таблиц отката по умолчанию (innodb_undo_001 и innodb_undo_002), созданные при инициализации экземпляра MySQL, должны находиться в каталоге, определенном переменной innodb_undo_directory. Если переменная innodb_undo_directory не определена, пространства таблиц отката по умолчанию находятся в каталоге данных. Если пространства таблиц отката по умолчанию перемещаются при выключенном сервере, сервер должен быть запущен с переменной innodb_undo_directory, настроенной на новый каталог.

Шаблоны ввода-вывода для журналов отката делают пространства таблиц отката хорошими кандидатами для хранения.

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

Значение по умолчанию для innodb_rollback_segments равно 128, что также является максимальным значением. Сведения о количестве транзакций, которые поддерживает сегмент отката, см. в Раздел 17.6.6, «Журналы отката».

Существует два метода обрезки резервных таблиц, которые могут использоваться по отдельности или в сочетании для управления размером резервной таблицы. Один метод автоматический, включенный с помощью переменных конфигурации. Другой метод — ручный, выполняемый с помощью SQL-запросов.

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

Автоматическая обрезка

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

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

mysql> SET GLOBAL innodb_undo_log_truncate=ON;

Когда переменная innodb_undo_log_truncate включена, резервные таблицы, размер которых превышает предел, определенный переменной innodb_max_undo_log_size, подлежат обрезке. Переменная innodb_max_undo_log_size динамическая и имеет значение по умолчанию 1073741824 байта (1024 МБ).

mysql> SELECT @@innodb_max_undo_log_size;
+----------------------------+
| @@innodb_max_undo_log_size |
+----------------------------+
|                 1073741824 |
+----------------------------+

Когда переменная innodb_undo_log_truncate включена:

Ручная обрезка

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

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

ALTER UNDO TABLESPACE tablespace_name SET INACTIVE;

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

Чтобы проверить состояние резервной таблицы, запросите таблицу схемы информации INNODB_TABLESPACES.

SELECT NAME, STATE FROM INFORMATION_SCHEMA.INNODB_TABLESPACES
  WHERE NAME LIKE 'tablespace_name';

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

ALTER UNDO TABLESPACE tablespace_name SET ACTIVE;

Резервную таблицу в состоянии empty также можно удалить. См. Удаление резервных таблиц.

Ускорение автоматической обрезки резервных таблиц

Поток очистки отвечает за очистку и обрезку резервных таблиц. По умолчанию поток очистки ищет резервные таблицы для обрезки один раз каждые 128 вызовов очистки. Частота, с которой поток очистки ищет резервные таблицы для обрезки, контролируется переменной innodb_purge_rseg_truncate_frequency, которая имеет значение по умолчанию 128.

mysql> SELECT @@innodb_purge_rseg_truncate_frequency;
+----------------------------------------+
| @@innodb_purge_rseg_truncate_frequency |
+----------------------------------------+
|                                    128 |
+----------------------------------------+

Чтобы увеличить частоту, уменьшите значение innodb_purge_rseg_truncate_frequency. Например, чтобы поток очистки искал резервные таблицы для обрезки один раз каждые 32 вызова очистки, установите innodb_purge_rseg_truncate_frequency в 32.

mysql> SET GLOBAL innodb_purge_rseg_truncate_frequency=32;

Влияние на производительность обрезки файлов резервных таблиц

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

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

Мониторинг обрезки резервных таблиц

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

SELECT NAME, SUBSYSTEM, COMMENT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE '%truncate%';

Дополнительную информацию об активации счетчиков и запросах данных счетчиков см. в Раздел 17.15.6, «Таблица InnoDB INFORMATION_SCHEMA Metrics».

Предел обрезки резервных таблиц

Количество операций обрезки одной и той же резервной таблицы между контрольными точками ограничено 64. Этот предел предотвращает потенциальные проблемы, вызванные чрезмерным количеством операций обрезки резервных таблиц, которые могут произойти, если innodb_max_undo_log_size установлен слишком низко на загруженной системе, например. Если предел превышен, резервную таблицу все еще можно сделать неактивной, но она не обрезается до следующей контрольной точки. В MySQL 9.2 этот предел составляет 50000.

Восстановление обрезки резервных таблиц

Операция обрезки резервной таблицы создает временный файл undo_space_number_trunc.log в каталоге журнала сервера. Этот каталог журнала определен переменной innodb_log_group_home_dir. Если во время операции обрезки произойдет сбой системы, временный файл журнала позволит процессу запуска определить резервные таблицы, которые обрезались, и продолжить операцию.

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

mysql> SHOW STATUS LIKE 'Innodb_undo_tablespaces%';
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| Innodb_undo_tablespaces_total    | 2     |
| Innodb_undo_tablespaces_implicit | 2     |
| Innodb_undo_tablespaces_explicit | 0     |
| Innodb_undo_tablespaces_active   | 2     |
+----------------------------------+-------+

Описание переменных состояния см. в Разделе 7.1.10, «Переменные состояния сервера».