Журнал редоктования InnoDB

Обзор

Журнал редоктования используется InnoDB при восстановлении после сбоя. Файлы журнала редоктования имеют имена, похожие на ib_logfileN, где N — целое число. Начиная с MariaDB 10.5, существует только один журнал редоктования, поэтому файл всегда будет называться ib_logfile0. Если переменная системы innodb_log_group_home_dir настроена, то файлы журнала редоктования будут созданы в этом каталоге. В противном случае они будут созданы в каталоге, определённом переменной системы datadir.

Влияние сброса на производительность и согласованность

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

Группа коммитов бинарного журнала и сброс журнала редоктования

В MariaDB 10.0 и выше, когда установлено innodb_flush_log_at_trx_commit=1 (по умолчанию) и включён бинарный журнал, теперь в InnoDB во время коммита происходит на одну синхронизацию с диском меньше (две синхронизации делятся между группой транзакций вместо трёх). Подробнее см. Группа коммитов бинарного журнала и производительность сброса InnoDB.

Ёмкость группы журналов редоктования

Ёмкость группы журнала редоктования — это общий объём всех журналов редоктования InnoDB. Релевантными факторами являются:

• Начиная с MariaDB 10.5, имеется 1 журнал редоктования. Для MariaDB 10.4 и более ранних версий количество файлов журнала редоктования настраивается переменной системы innodb_log_files_in_group.
• Размер каждого файла журнала редоктования настраивается переменной системы innodb_log_file_size. Его можно безопасно установить в гораздо большее значение с MariaDB 10.5. До MariaDB 10.9, для изменения размера требовался перезапуск сервера. С MariaDB 10.9, переменную можно изменять динамически.

Ёмкость группы журнала редоктования определяется следующим вычислением:

innodb_log_group_capacity = innodb_log_file_size * innodb_log_files_in_group

Например, если innodb_log_file_size установлена в 2G и innodb_log_files_in_group в 2, то будет следующее:

• innodb_log_group_capacity = innodb_log_file_size * innodb_log_files_in_group
• = 2G * 2
• = 4G

Изменение ёмкости группы журнала редоктования

Количество (до MariaDB 10.4 включительно — с MariaDB 10.5 только 1 журнал редоктования) или размер файлов журнала редоктования можно изменить следующим образом:

• Остановите сервер.
• Для изменения размера файла журнала настройте innodb_log_file_size. Для увеличения количества файлов журнала (до MariaDB 10.4 включительно) настройте innodb_log_files_in_group.
• Запустите сервер.

Номер последовательности журнала (LSN)

Записи в журнале редоктования InnoDB идентифицируются с помощью номера последовательности журнала (LSN).

Проверки

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

Проверки — это одна из задач фонового потока InnoDB. Этот поток планирует проверки с интервалом в 7 секунд, когда сервер очень активен, но проверки могут происходить чаще, когда сервер менее активен.

Грязные страницы фактически не сбрасываются из пула буферов в физические файлы табличного пространства InnoDB во время проверки. Этот процесс происходит асинхронно непрерывно фоновыми потоками ввода/вывода InnoDB, настроенными переменной системы innodb_write_io_threads. Если вы хотите сделать этот процесс более агрессивным, вы можете уменьшить значение переменной системы innodb_max_dirty_pages_pct. Возможно, также потребуется лучше настроить ёмкость ввода/вывода InnoDB в вашей системе, установив переменную системы innodb_io_capacity.

Определение возраста проверки

Возраст проверки — это количество данных, записанных в журнал редоктования InnoDB с момента последней проверки.

Определение возраста проверки в InnoDB

Возраст проверки также можно определить с помощью процесса, показанного ниже.

Для определения возраста проверки InnoDB выполните следующие действия:

• Запросите SHOW ENGINE INNODB STATUS.
• Найдите раздел LOG. Например:

---
LOG
---
Log sequence number 252794398789379
Log flushed up to 252794398789379
Pages flushed up to 252792767756840
Last checkpoint at 252792767756840
0 pending log flushes, 0 pending chkp writes
23930412 log i/o's done, 2.03 log i/o's/second

• Выполните следующее вычисление:

innodb_checkpoint_age = Log sequence number - Last checkpoint at

В приведенном выше примере это будет:

• innodb_checkpoint_age = Log sequence number - Last checkpoint at
• = 252794398789379 - 252792767756840
• = 1631032539 байт
• = 1631032539 байт / (1024 * 1024 * 1024) (ГБ/байт)
• = 1,5 ГБ данных, записанных в журнал редоктования с момента последней проверки

Определение заполнения журнала редоктования

Заполнение журнала редоктования — это процент ёмкости журнала редоктования InnoDB, занимаемый грязными страницами, которые ещё не были сброшены в физические файлы табличного пространства InnoDB в ходе проверки. Следовательно, он определяется следующим вычислением:

innodb_log_occupancy = innodb_checkpoint_age / innodb_log_group_capacity

Например, если innodb_checkpoint_age равно 1.5G и innodb_log_group_capacity равно 4G, то будет следующее:

• innodb_log_occupancy = innodb_checkpoint_age / innodb_log_group_capacity
• = 1.5G / 4G
• = 0.375

Если вычисленное значение заполнения журнала редоктования слишком близко к 1.0, то ёмкость журнала редоктования InnoDB может быть слишком мала для текущей рабочей нагрузки.

Обновления MariaDB 10.8

В MariaDB 10.8 было внесено ряд улучшений в журнал редоктования:

• Автоматический размер innodb_buffer_pool_chunk_size (MDEV-25342).
• Улучшение журнала редоктования для одновременности (MDEV-14425).
• Удаление FIL_PAGE_FILE_FLUSH_LSN (MDEV-27199).

До MariaDB 10.8.1, mariadb-backup --prepare создавал файл ib_logfile0 нулевой длины в качестве подстановки. С MariaDB 10.8.1 (MDEV-14425) размер этого файла был увеличен до 12304 (0x3010) байт, а все обновления FIL_PAGE_FILE_FLUSH_LSN в первой странице системного табличного пространства удалены.

С MariaDB 10.8.1, если сервер запускается с нулевым размером ib_logfile0, предполагается, что выполняется обновление после подготовки резервной копии. Тогда начальный LSN будет считан из FIL_PAGE_FILE_FLUSH_LSN, и новый файл журнала будет создан, начиная ровно с этого LSN.

Ручное создание файла ib_logfile0 нулевого размера без ручного обновления FIL_PAGE_FILE_FLUSH_LSN в системном табличном пространстве до достаточно недавнего LSN может привести к ошибкам, таким как "LSN страницы находится в будущем". Если журнал был удалён, а некоторые изменения уже были записаны в страницы данных, могут возникнуть любые виды повреждений.

Если база данных была инициализирована с сервером, который никогда не обновлял поле FIL_PAGE_FILE_FLUSH_LSN, любые попытки запуска сервера с нулевым размером ib_logfile0 будут отклонены из-за недействительного LSN. Если это поле когда-либо обновлялось с действительным LSN более старым сервером, эта система безопасности не может работать, и сервер может "перемотать" до более раннего LSN.