Уменьшить ibdata1 и включить таблицы в отдельные файлы InnoDB

Зачем вообще трогать ibdata1

В эпоху, когда innodb_file_per_table ещё не был нормой по умолчанию, InnoDB мог складывать данные в общий файл ibdata1. Он растёт при нагрузке, а после удаления таблиц не обязан отдавать место ОС — внутри InnoDB таблицы становятся пустыми, снаружи диск «занят». На проектах с 1С‑Битрикс это заметно на VPS с маленьким диском: каталог, инфоблоки и сессии крутятся в одной инстанции MySQL.

Описанный ниже путь — полная пересборка данных вокруг «чистого» tablespace с включением раздельных файлов на таблицу. Это не «онлайн-сжатие»: нужен простой, окно обслуживания и свежий бэкап.

Подготовка: дамп и список баз

Снимите логическую копию нужных схем. Для одной базы с процедурами и без блокировки чтения под InnoDB обычно достаточно связки --single-transaction и --routines (уточняйте состав флагов под вашу версию сервера и политику бэкапов). Пример шаблона — подставьте пользователя, имя базы и путь к файлу:

mysqldump --routines --events --triggers \
  --insert-ignore --skip-lock-tables --single-transaction=TRUE \
  -u root db_name > db_name.sql

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

Удалить пользовательские схемы

Остановите запись со стороны веба, затем удалите все базы, кроме служебных mysql, performance_schema и information_schema. Делайте это осознанно: без актуального дампа шаг необратим.

Остановить сервер и убрать файлы InnoDB

Остановите демон базы удобным для дистрибутива способом (systemctl stop mysqld или service mysqld stop). После остановки удалите общий файл данных и redo-логи (пути типичны для Linux; уточните datadir в конфиге):

rm /var/lib/mysql/ibdata1 /var/lib/mysql/ib_log*

Не трогайте mysql и другие системные каталоги схемы если вы решили сохранять только служебную схему целиком — здесь предполагается сценарий с полным пересозданием общих файлов InnoDB под новый старт. В сомнительных случаях сравните с официальной инструкцией вашей версии MariaDB/MySQL.

Включить innodb_file_per_table

Откройте основной конфиг (часто /etc/my.cnf или drop-in в my.cnf.d) и в секции [mysqld] добавьте строку:

[mysqld]
innodb_file_per_table=1

После правки запустите сервер снова. Новые пользовательские таблицы InnoDB начнут жить в отдельных .ibd там, где это предусмотрено версией; большие старые куски в одном ibdata1 вы уже убрали вместе с файлом.

Восстановление из дампа

Накатите сохранённые .sql обычным для вас способом (mysql CLI, скрипт, админка). Проверьте сайт на копии до переключения прод-трафика: поисковый индекс, сессии и обмены с 1С любят всплывать именно после «хирургии» на БД.

Когда выбрать другой путь

На продакшене с жёстким SLA чаще переносят проект на новый чистый инстанс mysqldump | mysql, оставляя старый до проверки. Если цель только освободить диск без пересборки shared tablespace, иногда достаточно миграции конкретных тяжёлых таблиц или апгрейда инфраструктуры — оцените риски простоя и целостности заранее.

Итог

Переезд с раздутого ibdata1 на модель «файл на таблицу» для окружения с 1С‑Битрикс — редкая, но рабочая операция при дефиците места и наследии старых настроек InnoDB. Главное — полный резерв, ясное окно работ и проверка критичных сценариев после подъёма.