15.1.1 Atomic Data Definition Statement Support — MySQL 9.2

15.1.1 Поддержка атомарных операторов языка определения данных (DDL)

MySQL 9.2 поддерживает атомарные операторы языка определения данных (DDL). Эта функция называется атомарным DDL. Атомарный оператор DDL объединяет обновления словаря данных, операции движка хранения и записи в бинарный журнал, связанные с операцией DDL, в одну атомарную операцию. Операция либо завершается успешно, при этом соответствующие изменения сохраняются в словаре данных, движке хранения и бинарном журнале, либо отменяется, даже если сервер прерывается во время выполнения операции.

Примечание

Атомарный DDL не является транзакционным DDL. Операторы DDL, атомарные или нет, неявно завершают любую активную транзакцию в текущем сеансе, как если бы вы выполнили COMMIT перед выполнением оператора. Это означает, что операторы DDL не могут выполняться в рамках другой транзакции, в операторах управления транзакциями, таких как START TRANSACTION ... COMMIT, или комбинироваться с другими операторами в рамках одной транзакции.

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

Функция атомарного DDL описана в следующих разделах данного раздела:

Поддерживаемые операторы DDL

Функция атомарного DDL поддерживает операторы DDL для таблиц и не для таблиц. Операции DDL, относящиеся к таблицам, требуют поддержки движка хранения, тогда как операции DDL, не относящиеся к таблицам, этого не требуют. В настоящее время только движок хранения InnoDB поддерживает атомарный DDL.

Поддерживаемые операторы DDL для таблиц включают в себя CREATE, ALTER и DROP операторы для баз данных, табличных пространств, таблиц и индексов, а также оператор TRUNCATE TABLE.
Поддерживаемые операторы DDL, не относящиеся к таблицам, включают:
- CREATE и DROP операторы, а также, применительно к случаю, ALTER операторы для хранимых программ, триггеров, представлений и загружаемых функций.
- Операторы управления учетными записями: CREATE, ALTER, DROP и, применительно к случаю, RENAME операторы для пользователей и ролей, а также GRANT и REVOKE операторы.

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

Операторы DDL, относящиеся к таблицам, которые включают движок хранения, отличный от InnoDB.
INSTALL PLUGIN и UNINSTALL PLUGIN операторы.
INSTALL COMPONENT и UNINSTALL COMPONENT операторы.
CREATE SERVER, ALTER SERVER и DROP SERVER операторы.

Характеристики атомарного DDL

Характеристики атомарных операторов DDL включают в себя следующее:

Обновления метаданных, записи в бинарный журнал и операции движка хранения (если применимо) объединены в одну атомарную операцию.
В процессе операции DDL нет промежуточных подтверждений на уровне SQL.
Применимо к случаю:
- Состояние кешей словаря данных, процедур, событий и загружаемых функций согласуется со статусом операции DDL, то есть кеши обновляются, чтобы отразить, была ли операция DDL успешно завершена или отменена.
- Методы движка хранения, участвующие в операции DDL, не выполняют промежуточных подтверждений, и движок хранения регистрирует себя как часть операции DDL.
- Движок хранения поддерживает восстановление и откат операций DDL, что выполняется на стадии Post-DDL операции DDL.
Видимое поведение операций DDL атомарно.

Поведение операторов DDL

В этом разделе описываются некоторые важные аспекты поведения операторов DDL при использовании движка хранения, поддерживающего атомарные DDL, такого как InnoDB.

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

Оператор DROP TABLE завершается с ошибкой, если указанной таблицы не существует, и никаких изменений не вносится, независимо от движка хранения.
Операторы CREATE DATABASE и DROP DATABASE полностью атомарны и безопасны при сбоях, при условии, что все таблицы в указанной базе данных используют движок хранения, поддерживающий атомарные DDL. В этом случае оператор либо успешно добавляет или удаляет все объекты, либо отменяется.
Для таблиц, которые не используют движок хранения, поддерживающий атомарные DDL, удаление таблиц происходит вне атомарной транзакции DROP TABLE или DROP DATABASE. Такие удаления таблиц записываются в двоичный журнал индивидуально, что ограничивает расхождения между движком хранения, словарем данных и двоичным журналом не более чем одной таблицей в случае прерывания операции DROP TABLE или DROP DATABASE. Для операций, удаляющих несколько таблиц, любые таблицы, не использующие движок хранения, поддерживающий атомарные DDL, удаляются перед таблицами, которые его используют.
Операции CREATE TABLE, ALTER TABLE, RENAME TABLE, TRUNCATE TABLE, CREATE TABLESPACE и DROP TABLESPACE для таблиц, использующих движок хранения, поддерживающий атомарные DDL, полностью завершаются или отменяются, если сервер прекращает работу во время их выполнения. Операции RENAME TABLE являются атомарными только если все указанные таблицы используют движок хранения, поддерживающий атомарные DDL.
Для движков хранения, поддерживающих атомарные DDL, оператор CREATE TABLE ... SELECT записывается в двоичный журнал как одна транзакция, когда используется строчно-ориентированная репликация.

В движках хранения, которые поддерживают как атомарные DDL, так и внешние ключи, создание внешних ключей не разрешено в операторах CREATE TABLE ... SELECT при использовании строчно-ориентированной репликации. Внешние ключи могут быть добавлены позже с помощью оператора ALTER TABLE.

При применении оператора CREATE TABLE ... SELECT как атомарной операции, на таблице выставляется метаданных блокировка, пока данные вставляются, что предотвращает одновременный доступ к таблице на протяжении всей операции.
Оператор DROP VIEW завершается с ошибкой, если указанного представления не существует, и никаких изменений не вносится.
Операторы управления учетными записями либо завершаются успешно для всех указанных пользователей, либо отменяются и не оказывают никакого эффекта, если произошла ошибка.

Поддержка движков хранения

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

Для поддержки отката и повтора операций DDL, InnoDB записывает журналы DDL в таблицу mysql.innodb_ddl_log, которая является скрытой таблицей словаря данных, расположенной в пространстве имен словаря данных mysql.ibd.

Чтобы просмотреть журналы DDL, которые записываются в таблицу mysql.innodb_ddl_log во время операции DDL, включите параметр конфигурации innodb_print_ddl_logs. Дополнительную информацию можно найти в разделе Просмотр журналов DDL.

Примечание

Журналы повтора для изменений в таблице mysql.innodb_ddl_log сразу же записываются на диск независимо от параметра innodb_flush_log_at_trx_commit. Непосредственное сохранение журналов повтора предотвращает ситуации, когда файлы данных изменяются операциями DDL, но журналы повтора изменений в таблице mysql.innodb_ddl_log, которые получились из этих операций, не сохраняются на диск. Такая ситуация может вызвать ошибки при отмене или восстановлении.

Движок хранения InnoDB выполняет операции DDL в фазах. Операции DDL, такие как ALTER TABLE, могут выполнять фазы Подготовка и Выполнение несколько раз до фазы Подтверждение.

Подготовка: Создание необходимых объектов и запись журналов DDL в таблицу mysql.innodb_ddl_log. Журналы DDL определяют, как выполнить обратное и прямое выполнение операции DDL.
Выполнение: Выполнение операции DDL. Например, выполнение процедуры создания для операции CREATE TABLE.
Подтверждение: Обновление словаря данных и подтверждение транзакции словаря данных.
После DDL: Повторное выполнение и удаление журналов DDL из таблицы mysql.innodb_ddl_log. Для обеспечения возможности безопасного отката без создания несоответствий, такие операции с файлами, как переименование или удаление файлов данных, выполняются на этой заключительной фазе. На этой фазе также удаляются динамические метаданные из таблицы словаря данных mysql.innodb_dynamic_metadata для DROP TABLE, TRUNCATE TABLE и других операций DDL, которые перестраивают таблицу.

Журналы DDL повторно выполняются и удаляются из таблицы mysql.innodb_ddl_log в фазе После DDL, независимо от того, была ли операция DDL подтверждена или отменена. Журналы DDL должны оставаться только в таблице mysql.innodb_ddl_log, если сервер прекратил работу во время операции DDL. В этом случае журналы DDL повторно выполняются и удаляются после восстановления.

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

Просмотр логов DDL

Чтобы просмотреть логи DDL, которые записываются в таблицу словаря данных mysql.innodb_ddl_log во время атомарных операций DDL, включающих хранилище InnoDB, включите innodb_print_ddl_logs, чтобы MySQL записывал логи DDL в stderr. В зависимости от операционной системы хоста и конфигурации MySQL, stderr может быть файлом журнала ошибок, терминалом или окном консоли. См. Раздел 7.4.2.2, «Настройка назначения файла журнала ошибок по умолчанию».

InnoDB записывает логи DDL в таблицу mysql.innodb_ddl_log для поддержки операций отката и повтора операций DDL. Таблица mysql.innodb_ddl_log — это скрытая таблица словаря данных, которая находится в пространстве имен словаря данных mysql.ibd. Как и другие скрытые таблицы словаря данных, к таблице mysql.innodb_ddl_log нельзя получить прямой доступ в неотладочных версиях MySQL. (См. Раздел 16.1, «Схема словаря данных».) Структура таблицы mysql.innodb_ddl_log соответствует этому определению:

CREATE TABLE mysql.innodb_ddl_log (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  thread_id BIGINT UNSIGNED NOT NULL,
  type INT UNSIGNED NOT NULL,
  space_id INT UNSIGNED,
  page_no INT UNSIGNED,
  index_id BIGINT UNSIGNED,
  table_id BIGINT UNSIGNED,
  old_file_path VARCHAR(512) COLLATE utf8mb4_bin,
  new_file_path VARCHAR(512) COLLATE utf8mb4_bin,
  KEY(thread_id)
);

id: Уникальный идентификатор записи журнала DDL.
thread_id: Каждая запись журнала DDL получает thread_id, который используется для воспроизведения и удаления логов DDL, относящихся к конкретной операции DDL. Операции DDL, включающие несколько операций с файлами данных, генерируют несколько записей журнала DDL.
type: Тип операции DDL. Типы включают FREE (удаление дерева индекса), DELETE (удаление файла), RENAME (переименование файла) или DROP (удаление метаданных из таблицы словаря данных mysql.innodb_dynamic_metadata).
space_id: Идентификатор пространства имен.
page_no: Страница, содержащая информацию об алокации; например, корневая страница дерева индекса.
index_id: Идентификатор индекса.
table_id: Идентификатор таблицы.
old_file_path: Путь к старому файлу пространства имен. Используется операциями DDL, которые создают или удаляют файлы пространства имен; также используется операциями DDL, которые переименовывают пространство имен.
new_file_path: Путь к новому файлу пространства имен. Используется операциями DDL, которые переименовывают файлы пространства имен.

Этот пример демонстрирует включение innodb_print_ddl_logs для просмотра логов DDL, записанных в strderr для операции CREATE TABLE.

mysql> SET GLOBAL innodb_print_ddl_logs=1;
mysql> CREATE TABLE t1 (c1 INT) ENGINE = InnoDB;

[Note] [000000] InnoDB: DDL log insert : [DDL record: DELETE SPACE, id=18, thread_id=7,
space_id=5, old_file_path=./test/t1.ibd]
[Note] [000000] InnoDB: DDL log delete : by id 18
[Note] [000000] InnoDB: DDL log insert : [DDL record: REMOVE CACHE, id=19, thread_id=7,
table_id=1058, new_file_path=test/t1]
[Note] [000000] InnoDB: DDL log delete : by id 19
[Note] [000000] InnoDB: DDL log insert : [DDL record: FREE, id=20, thread_id=7,
space_id=5, index_id=132, page_no=4]
[Note] [000000] InnoDB: DDL log delete : by id 20
[Note] [000000] InnoDB: DDL log post ddl : begin for thread id : 7
[Note] [000000] InnoDB: DDL log post ddl : end for thread id : 7