Атомарные операции DDL

Начиная с MariaDB 10.6.1, мы улучшили читаемость операций DDL (Data Definition Language), сделав большинство из них атомарными, а остальные — устойчивыми к сбоям, даже если сервер аварийно завершит работу в середине операции.

Архитектура атомарных/устойчивых к сбоям операций DDL (MDEV-17567) позволяет ей работать со всеми движками хранения.

Определения

• Атомарность означает, что операция либо выполняется успешно (и записывается в двоиковый журнал), либо полностью отменяется.
• Устойчивость к сбоям означает, что в случае сбоя после перезапуска сервера все таблицы будут согласованы, на диске не останется временных файлов или таблиц, а двоичный журнал будет соответствовать состоянию сервера.
• DDL — язык определения данных.
• DML — язык манипулирования данными.
• «Журнал восстановления DDL» или «журнал DDL» — это новый журнал, ddl_recovery.log по умолчанию, который хранит все операции DDL в процессе. Он используется для восстановления состояния сервера в случае внезапного сбоя.

Обзор

До версии 10.6 в случае сбоя существовала небольшая вероятность того, что произойдёт одно из следующих:

• Могли остаться временные таблицы, начинающиеся с #sql-alter или #sql-shadow, или временные файлы, оканчивающиеся на ''.
• Таблица в движке хранения и файл .frm таблицы могли оказаться несинхронизированными.
• При переименовании нескольких таблиц переименовывались только некоторые из них.

Какие операции DDL теперь атомарные

• CREATE TABLE, за исключением случаев использования с CREATE OR REPLACE, которая обеспечивает только устойчивость к сбоям.
• RENAME TABLE и RENAME TABLES.
• CREATE VIEW
• CREATE SEQUENCE
• CREATE TRIGGER
• DROP TRIGGER
• DROP TABLE и DROP VIEW. Удаление нескольких таблиц обеспечивает только устойчивость к сбоям.
• ALTER TABLE

• ALTER SEQUENCE не указана выше, так как она реализуется как DML.

Какие операции DDL теперь устойчивы к сбоям

Удаление нескольких таблиц (DROP TABLE).

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

CREATE OR REPLACE TABLE

CREATE OR REPLACE TABLE foo реализуется следующим образом:

DROP TABLE IF EXISTS foo;
CREATE TABLE foo ...

Это означает, что если произойдёт сбой во время CREATE TABLE, то исходная таблица 'foo' будет удалена, даже если новая таблица не была создана. Если таблица не была пересоздана, двоичный журнал будет содержать DROP TABLE.

DROP DATABASE

DROP DATABASE реализуется следующим образом:

loop over all tables
  DROP TABLE table

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

Атомарность с разными движками хранения

Атомарные/устойчивые к сбоям операции DDL работают со всеми движками хранения, которые либо имеют атомарные DDL внутри, либо способны повторно выполнить DROP или RENAME в случае сбоя.

Это должно быть справедливо для большинства движков хранения. Те, которым требуется доработка:

• Движок хранения S3.
• Движок разбиения таблиц. Разбиение должно быть атомарным в большинстве случаев, но некоторые известные проблемы ещё требуют тестирования и исправления.

Файл журнала восстановления DDL

Новый параметр запуска --log-ddl-recovery=path (ddl_recovery.log по умолчанию) позволяет указать местоположение файла журнала DDL. Это полезно в основном в случае использования файловой системы на постоянной памяти, так как в ходе операций DDL с этим файлом происходит много синхронизаций.

Этот файл содержит все операции DDL, которые находятся в процессе выполнения.

При запуске сервера MariaDB файл журнала DDL копируется в файл с тем же базовым именем, но с -backup.log суффиксом. Это делается для того, чтобы можно было выяснить причину сбоя в случае неудачного восстановления.

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

Выводы

• Мы считаем, что чёткое разделение слоёв приводит к более легко поддерживаемому решению. Реализация атомарных операций DDL в MariaDB 10.6 внесла минимальные изменения в API движков хранения, в основном для встроенных операций ALTER TABLE.
• В нашей реализации InnoDB не потребовалось изменения формата файлов, помимо журнала отмены RENAME, который был добавлен в MariaDB 10.2.19 для повторной реализации TRUNCATE с безопасностью резервного копирования. Достаточно правильного использования принципов проектирования (журналы записи вперёд и транзакции; теперь создание файлов следует протоколу ARIES). Мы убрали «обходные пути» (максимум одна CREATE или DROP на транзакцию) и правильно реализовали rollback и purge триггеры для таблицы InnoDB SYS_INDEXES.
• Быстро было найдено и исправлено множество ошибок восстановления DDL в InnoDB благодаря https://rr-project.org. Мы всё ещё работаем над одной проблемой: файлы данных не должны удаляться до завершения транзакции DDL.

Благодаря атомарным/устойчивым к сбоям операциям DDL, сервер MariaDB теперь гораздо стабильнее и надёжнее в нестабильных средах. Сейчас продолжается работа по устранению нескольких оставшихся проблем, упомянутых выше, чтобы все операции DDL стали атомарными. Целевой релиз для этого — MariaDB 10.7.

См. также

• MDEV-17567 Атомарные операции DDL. Данная запись MDEV содержит ссылки на все остальные записи, связанные с атомарными операциями, содержащие много информации о способах реализации.