Журнал отката InnoDB
Обзор
При записи данных транзакцией, они всегда вставляются в индексы таблицы или данные (в буферном пуле или в физических файлах). Частные копии не создаются. Старые версии данных, изменяемых активными транзакциями InnoDB, хранятся в журнале отката. Исходные данные затем могут быть восстановлены или просмотрены с помощью согласованного чтения.
Детали реализации
Перед изменением строки она копируется в журнал отката. Каждая обычная строка содержит указатель на последнюю версию той же строки в журнале отката. Каждая строка в журнале отката содержит указатель на предыдущую версию, если таковая имеется. Таким образом, каждая изменённая строка имеет цепочку истории.
Строки никогда физически не удаляются до завершения транзакции. Если бы они были удалены, восстановление было бы невозможно. Таким образом, строки просто помечаются для удаления.
Каждая транзакция использует представление записей. Уровень транзакции определяет, как создаётся это представление. Например, READ UNCOMMITTED обычно использует текущую версию строк, даже если они не подтверждены (грязное чтение). Другие уровни изоляции требуют, чтобы самая последняя подтверждённая версия строк была найдена в журнале отката. READ COMMITTED использует разное представление для каждой таблицы, в то время как REPEATABLE READ и SERIALIZABLE используют одно и то же представление для всех таблиц.
Также существует глобальный список истории данных. При подтверждении транзакции её история добавляется в этот список истории. Порядок списка соответствует хронологическому порядку подтверждений.
Поток очистки удаляет строки в журнале отката, которые не нужны ни одному существующему представлению. Удаляются строки, для которых существует самая последняя версия, а также строки, помеченные на удаление.
Если InnoDB необходимо восстановить старую версию, она просто заменит более новую версию более старой. Когда транзакция вставляет новую строку, нет более старой версии. Однако в этом случае восстановление может быть выполнено путём удаления вставленных строк.
Последствия длительных транзакций
Понимание работы журнала отката помогает понять негативные последствия длительных транзакций.
- Длительные транзакции генерируют несколько старых версий строк в журнале отката. Эти строки, вероятно, понадобятся в течение более длительного времени, потому что другие длительные транзакции также будут их нуждаться. Поскольку эти транзакции будут генерировать больше изменённых строк, можно наблюдать некую комбинаторную взрывную ситуацию. Таким образом, журнал отката требует больше места.
- Транзакции могут потребовать чтения очень старых версий строк в списке истории, поэтому их производительность ухудшится.
Конечно, только чтение транзакций не записывает больше записей в журнал отката; однако они замедляют очистку существующих записей.
Кроме того, длительные транзакции могут более вероятно привести к тупикам, но эта проблема не связана с журналом отката.
Настройка
Журнал отката — это не файл журнала, который можно просмотреть на диске в обычном смысле, например, журнал ошибок или журнал медленных запросов, а скорее область хранения.
Журнал отката обычно является частью физического системного пространства таблиц, но начиная с MariaDB 10.0, системные переменные innodb_undo_directory и innodb_undo_tablespaces могут быть использованы для разделения на разные пространства таблиц и хранения в другом месте (возможно, на другом устройстве хранения).
Каждая часть журнала отката, относящаяся к вставке или обновлению, известна как сегмент отката. Системная переменная innodb_undo_logs задаёт количество сегментов отката, которые будут использоваться на одну транзакцию.
Связанная переменная состояния innodb_available_undo_logs хранит общее количество доступных журналов отката InnoDB.
© 2023 MariaDB
Licensed under the Creative Commons Attribution 3.0 Unported License and the GNU Free Documentation License.
https://mariadb.com/kb/en/innodb-undo-log/