28 октября 2026 года Пшемыслав Малковский опубликовал на блоге Percona утилиту innodump 0.8.1. Она читает файлы InnoDB, MyISAM и MyRocks и пишет схему вместе со строками, не поднимая MySQL или MariaDB. Код лежит в репозитории PrzemekMalkowski/innodump. Это личный эксперимент автора, не программа с поддержкой Percona.
На VPS с WordPress база обычно MariaDB или MySQL, таблицы сайта в InnoDB. Пока процесс базы жив, обычный дамп или XtraBackup остаются нормальным путём. innodump про другое утро: сервис не стартует или крутится в перезапусках, а годной копии нет. nginx и PHP-FPM утилита не трогает. Им всё равно, чем вы читаете .ibd.
Три движка и файлы, не сокет
На вход идёт каталог данных, отдельный файл таблицы, общее табличное пространство или уже снятая копия: снимок тома, каталог XtraBackup. На выходе либо пара SQL-файлов, схема и строки, либо каталог TSV под утилиты дампа MySQL Shell. В каждом примере на странице программа печатает баннер innodump 0.8.1.
Движков три. InnoDB, в том числе отдельный .ibd и общее пространство. MyISAM. MyRocks, то есть RocksDB. На обычном сайте WordPress MyRocks не встречается: он появляется, если базу ставили как Percona Server или MariaDB с этим движком. Пока таблицы сайта в InnoDB, эта ветка вам не нужна. Движок смотрится в information_schema, пока сервер ещё стартует. Когда он уже не стартует, остаются расширения: .ibd, .MYD, каталог .rocksdb или #rocksdb.
Считать такое чтение ещё одним бэкапом Малковский отказывается. У InnoDB байты на диске сами по себе не обещают цельный снимок: грязная страница может ещё не доехать до файла, запись может попасться на середине. XtraBackup для копии дочитывает журнал redo и берёт блокировки бэкапа. Политику копий он отсылает к заметке Percona про бэкап MySQL, не к innodump.
Битая страница и –skip-corrupted
Мелкий сбой вторичного индекса часто лечится тем, что индекс создают заново. Порча кластерного ключа другое дело. Сервер падает, когда запрос доходит до битой страницы: аварийный останов, рестарт, снова та же страница. Малковский ссылается на отчёты MySQL 111610 и 113706 как на знакомый вид этого круга. Вытаскивать живые строки запросами тогда долго. Одна плохая страница роняет процесс, следующую строку пробуют уже после старта.
Флаг –skip-corrupted для прохода по файлу. Программа пишет предупреждение и переходит к следующей странице. В примере файл instant_t.ibd, 130 023 424 байта, 7936 страниц по 16 384 байта. Описание схемы внутри файла записал MySQL 8.0.33, формат строк DYNAMIC, кластерный индекс PRIMARY, вторичных индексов пять. Баннер innodump 0.8.1, таблица db1.instant_t, на выход 29 колонок из 31, служебные спрятаны. Страница 100 индекса PRIMARY пропущена: младшие байты LSN в начале и в конце страницы не совпали. В SQL ушло 100 680 строк, одна страница осталась за бортом. Схема легла в sqldump_2026-10-21_16.42/db1.instant_t-schema.sql, данные в соседний файл -data.sql.
Строки с пропущенной страницы в дамп не попадают. Это дыра в восстановлении. Подменять таким файлом базу, с которой сайт уже работает, рано.
–examine и innochecksum
–examine разбирает строки и на диск ничего не пишет. В отчёте видно, сколько строк читается. Обход только по кластерному индексу, то есть по первичному ключу. Сломанный вторичный индекс этот режим не покажет. Задача другая: понять, какие строки вообще можно забрать.
Если нужна проверка страниц InnoDB на порчу, Малковский отправляет сначала к штатному innochecksum. У innodump здесь другая работа. Показать, что из файла реально разбирается в строки.
На песочнице с путём msb_11_6_2 программа узнала каталог данных по ibdata1. Нашла 6 файлов .ibd, 129 файлов .frm без пары .ibd и каталог MyRocks #rocksdb. В отчёте таблицы db1.t0 и db1.t1, плюс служебные mysql.gtid_slave_pos, innodb_index_stats, innodb_table_stats и transaction_registry. У MyRocks таблица db1.sbtest1 на 1 000 000 строк. Итог: InnoDB, 6 таблиц и 29 строк, RocksDB, одна таблица и миллион строк, всего 7 таблиц и 1 000 029 строк. Строка результата: every table read cleanly. Те 129 .frm без .ibd в словарь ibdata1 тоже не попали. В заметке это не-InnoDB таблицы, представления или общее табличное пространство, examine их не смотрит. На WordPress так выглядят VIEW и старые таблицы, которым не досталось своего .ibd.
Каталог одной базы и кэш страниц
Стенду часто не нужна согласованность на точку во времени. Зато полный подъём бэкапа ради пары баз дорог. innodump умеет снять один каталог базы.
На песочнице msb_9_7_0 Малковский снял каталог db2 с флагами –format tsv и –compression zstd. Пять .ibd: categories 10 000 строк, cities 100 000, products 100 000, sales 1 049 877, stores 100 000. Вместе 1 359 877 строк, каталог tsvdump_2026-10-21_16.58. Имена файлов вида db2@sales.tsv.zst и db2@sales.sql, плюс @.json и @.done.json. Это раскладка под быстрый импорт MySQL Shell, не под заливку дампа в ту же базу, с которой nginx отдаёт сайт.
Живой каталог или неподготовленная копия ведут себя хуже, чем кажется по числу строк. Грязная страница ещё не на диске. Страница может попасться на полузаписи. Строка окажется старой, пропавшей или с неверной пометкой. Таблица, которую только что создали в общем пространстве, может отсутствовать целиком. Для одноразового стенда в заметке это допустимо. Базу боевого сайта такой выгрузкой не подменяют.
Если читать всё же с машины, где крутится сайт, в заметке два флага про нагрузку. –io-limit режет скорость чтения, в примере стоит 30M. –direct-io открывает файл с O_DIRECT, и ядро не тащит таблицу в страничный кэш. Рядом nice, чтобы процесс не отъедал CPU у MariaDB и PHP-FPM.
Файл orders.ibd с той же песочницы, 1 500 000 строк, размер 228 МБ. Без ограничений реальное время 1,726 с, а fincore показал 192,1 МБ файла в кэше. С –direct-io и –io-limit 30M время выросло до 9,241 с, в кэше 0 байт. На VPS, где база и сайт делят несколько гигабайт RAM, второй прогон не вытесняет кэш PHP и InnoDB ради разового чтения. Согласованности эти флаги не добавляют. Они только про то, сколько места чтение занимает в памяти.
Строки с пометкой удаления
InnoDB не затирает удалённую запись сразу. Сначала пометка, место в странице живёт, пока новая запись его не займёт. Если успеть, строку ещё можно разобрать. Для этого флаг –deleted-only.
На файле sbtest1.ibd из песочницы msb_8_4_3 программа версии 0.8.1 вынула 2100 таких строк таблицы sbtest.sbtest1. Схема в sbtest.sbtest1-schema.sql, данные в sbtest.sbtest1-data-deleted.sql, каталог sqldump_2026-10-21_17.46. Формат строк DYNAMIC.
На WordPress окно короткое. Ревизии, комментарии, транзиенты и корзина пишут в те же файлы. Пока страницу не заняли заново, шанс есть. После плотной записи флаг пустое место не выдумает.
Отдельный случай в заметке, старые версии, с которыми обычные программы бэкапа уже не открывают файлы. Там тоже работа по файлам, а не подъём древнего демона рядом с текущей MariaDB сайта.
Команда из заметки, которая только считает строки и ничего не пишет, выглядит так. Путь авторский, с песочницы. На сервере это копия каталога данных или каталог уже снятого бэкапа, не путь, куда прямо сейчас пишет живой процесс.
innodump --examine --source-dir /data/sandboxes/msb_11_6_2/data/
Версия видна в баннере. В примерах на странице это 0.8.1. Перезапуск nginx, PHP-FPM и самой базы после чтения копии не нужен: файлы вы только читаете. Если база в цикле падений, её лучше держать остановленной, пока снимаете копию. Иначе она снова упрётся в ту же страницу.
Грузить результат имеет смысл в другую MariaDB или MySQL, отдельным инстансом. Имя базы и префикс таблиц WordPress должны совпасть с тем, что ждёт сайт, но это уже обычный перенос. Пока сервер стартует, обычный дамп и XtraBackup никуда не делись.
