Ibdata1 что за файл
Я хотел бы понять эти файлы ibdata, поскольку они играют жизненно важную роль в процедуре восстановления после сбоя. Я не мог найти подходящие ресурсы в Интернете для этого.
Файл ibdata1 является системным табличным пространством для инфраструктуры InnoDB.
Он содержит несколько классов для информации, необходимой для InnoDB
Вы можете отделить страницы данных и индексов от ibdata1, включив innodb_file_per_table . Это приведет к тому, что любая вновь созданная таблица InnoDB будет хранить данные и индексные страницы во внешнем .ibd файле.
-
- это / var / lib / mysql
- CREATE TABLE mydb.mytable (. ) ENGINE=InnoDB; создает /var/lib/mysql/mydb/mytable.frm
- innodb_file_per_table включен, страницы данных / индекса хранятся в /var/lib/mysql/mydb/mytable.ibd
- innodb_file_per_table отключен, страницы данных / индексов хранятся в ibdata1
Независимо от того, где хранится таблица InnoDB, функциональность InnoDB требует поиска метаданных таблицы, а также сохранения и извлечения информации MVCC для поддержки соответствия ACID и изоляции транзакции. .
Вот мои прошлые статьи по отделению табличных данных и индексов от ibdata1
- Oct 29, 2010 : Мой оригинальный пост в StackOverflow
- Nov 26, 2011 : ОШИБКА 1114 (HY000) в строке 6308 в файле & Таблица user_analysis заполнена
- Feb 03, 2012 : Плановая оптимизация таблиц в MySQL InnoDB
- Mar 25, 2012 : Почему InnoDB хранит все базы данных в одном файле?
- Apr 01, 2012 : Целесообразно ли использовать innodb_file_per_table?
Если вы хотите знать, для чего ib_logfile0 и ib_logfile1 для чего они нужны, это журналы повторов InnoDB. Их никогда не следует стирать или изменять до тех пор, пока не произойдет полное нормальное отключение mysqld . Если mysqld когда-либо падает, просто запустите mysqld. Он будет считывать ib_logfile0 и ib_logfile1 проверять любые изменения данных, которые не были отправлены в буфер двойной записи в ibdata1 . Он будет воспроизводить (повторять) эти изменения. Как только они будут воспроизведены и сохранены, mysqld будет готов к новым соединениям с БД.
Как место будет сохранено в этих файлах журнала . Я имею в виду спросить . «для новых транзакций innodb, как будут использоваться те же файлы журналов, если они полностью заполнены…»
@ Uday Пространство не будет сохранено в файлах iblog, пока буфер журнала не станет пустым. Это динамический процесс, в котором пространство журнала занято и освобождается на основании остановленных изменений транзакций, записанных в буфере журнала. Эти файлы журналов полностью заполняются, когда вы выполняете огромные загрузки данных, что приводит к ошибкам Innodb, в которых указывается «InnoDB: что превышает емкость группы журналов». Это означает, что размер файла журнала должен быть больше, чтобы что-то делать. Надеюсь, мое объяснение очистило ваши сомнения.
innodb_file_per_table disabled, Data/Index Pages Stored in /var/lib/mysql/mydb/mytable.ibd и innodb_file_per_table enbled, Data/Index Pages Stored in ibdata1 должно быть наоборот, не так ли?
Случилась недавно проблемка. Получил уведомление о том, что на рабочем сервере заканчивается свободное место. Был слегка удивлен, ведь на нем хостились всего лишь тестовые версии сайтов, для демонстрации клиентам.
Начал разбираться что происходит. Первая идея – кто то, снова, нашел дыру и пытается спамить. Такое уже бывало. Рабочие папки exim (по моему) росли в размере с невероятной скоростью, пока последний не был отключен.
Теория не подтвердилась.Пришлось локализовать “распухшее” место программой du :
В моем случае это оказался файл ibdata1 – файл с базами данных.
Как выяснилось, до 5.6.6, MySQL по умолчанию не “резала” таблицы и базы на отдельные папки и файлы, а сохраняла все в один файл.Пошел смотреть какая база разрослась. Все оказалось просто – я не отключил один старый сайт на Magento CMS . Она собирала информацию о пользователях и их устройствах, переходах, действиях и чёрт знает что еще. И, внимание, хранила все это она в БД.
Не поверите, на “мертвом” сайте за 5+ лет побывало то ли 7, то ли 8 тыс человек. Которые сгенерировали по 14 000 000 (четырнадцать миллионов) записей в двух таблицах.
Порядка 7 Gb логов всего в двух табличках!Данные эти мне не нужны, поэтому TRUNCATE и дело с концом.
И вот тут меня ждал очень неприятный сюрприз – размер файла ibdata1 не уменьшился вообще.
ALTER TABLE <. >ENGINE=innodb не помогло. OPTIMIZE TABLE <. >– тоже.Решение
Нашел решние на Stackoverflow .
Оказалось, что это, типа, так и должно быть. Файл можно уменьшить только удалив ibdata1 и ib_log .4. Исправляем конфиг my.cnf
Данный файл лежит, скорее всего, где то тут: /etc/mysql/my.cnf .
Чтобы найти все места откуда забирается конфиг, можно выполнить следующую команду:Как говорит народная мудрость, “админы делятся на две категории: те, которые делают бэкапы, и те, которые уже делают”. В моем случае ответственность за несделанный бэкап упала на разработчика, то есть на меня самого. Данная статья посвящена тому, как найти выход из ситуации, подобной описанной. Надеюсь она будет полезна тем, кто не имея такого опыта, может столкнуться с подобной ситуацией.
В общем, дело было так…
Вступление
В далеком царстве, в тридевятом государствеВ одном из государственных административных учреждений, которое обслуживается нашим предприятием, стоял сервер. В качестве сервера использовался обычный настольный компьютер с не особо мощным двухядерным процессором, жестким диском на 320 Гб, без всяких там “ненужных” RAID-массивов, ничего “лишнего”, c установленной на нем cерверной Windows, кажется, 2003. И выполнял он некоторые серверные задачи, о которых я-то в силу своей должности не был особо осведомлен. Работал так практически без перерыва порядка нескольких лет.И вот, в один прекрасный день, позвал меня с моей напарницей к себе начальник отдела, дал нам задание разработать систему для этого учреждения с использованием в качестве СУБД MySQL Server 5.1. Систему мы разработали, все ей были весьма довольны, и пришла пора ее внедрять. Без всяких проблем мы с одним из наших админов, придя в офис учреждения, установили на вышеупомянутый сервер MySQL 5.1, развернули на ней базу, установили клиентское приложение на рабочие машины, запустили процесс внедрения. Работники учреждения были весьма рады системе, но осваивали ее медленно ввиду загруженности работой, совещаниями, заседаниями, обращениями граждан и т.д. Потихоньку вводили информацию, но сильно “растягивали удовольствие”. Надо было уже потихоньку начинать задумываться о стратегии бэкапа/восстановления, но я все думал о том, что это и не совсем-то мое дело, ведь я-то не админ, а разработчик. Но и админам это было совершенно безразлично. Я же себя утешал лишь тем, что пока информации мало, вот будет побольше, и если никто не начнет делать бэкапы, начну уже я. Оглядываясь назад, теперь я вижу, как легко можно было предсказать последующие события.
Через некоторое время одного из ключевых сотрудников настигло “просветление”, и за очень малый промежуток времени было введено значительное количество информации в систему, практически вся информация, которая могла быть введена на тот момент. Я об этом и думать не думал, все полагал, что они также медленно присматриваются к системе, ничего толком еще не вводя, работая себе, как и раньше, только со своими бумагами. Сотрудник же ввел быстренько информацию и ушел в отпуск на месяц.
Основные боевые действия
И вот, наступил другой “прекрасный” день, сервер упал. Причем, не программно, а аппаратно – “полетел” жесткий диск. Далее жесткий диск был сдан в фирму, занимающуюся восстановлением данных, и значительная часть информации с него была восстановлена. Однако, админы при восстановлении самого сервера, восстановили только всю информацию с диска D, про нашу MySQL никто и не вспомнил (по “счастливой случайности” она оказалась поставлена на диск C). Все это время я себе спокойно занимался другими проектами, про эти события и знать не знал.
Первым делом ищу папку Program Files, куда ставится по умолчанию MySQL. Не нахожу, но зато нахожу папку с файлами данных MySQL, в ней папка с именем той самой нашей базы. Небольшой заряд оптимизма немного разогнал тучи моего отчаяния, но… глядя на файлы *.MYD, в которых по идее должны бы быть записи таблиц, вижу, что размер их слишком мал для такого количества информации, которое было введено. Бинарные логи также не были включены, и этот вариант автоматически отпадал. Начинаю думать над этим вопросом и вспоминаю, что можно взглянуть на девелоперскую базу на нашем тестовом сервере, что я и сделал. Там я увидел, что большинство таблиц – причем, самых важных – работают на движке InnoDB, а значит, что их записи хранятся отдельно в файле ibdata* (в моем случае, только ibdata1). Выхожу на уровень выше и вижу этот заветный файл. Рядом также два лога движка InnoDB: ib_logfile0 и ib_logfile1. Открыв один из логов для просмотра в текстовом редакторе среди “кракозябр” я также увидел и куски самой информации, и тут я понял, что восстановить базу можно, по крайней мере, теоретически.
Надо было выбрать машину, где произвести попытку восстановления самой базы. Т.к. во время разработки я пользуюсь тестовым сервером, доступ к которому на уровне файловой системы мне без боя никто не даст, я решаю установить MySQL Server 5.1 и MySQL GUI Tools прямо на свою девелоперскую машину, работающую под Windows XP. Итак, все стоит, СУБД запущено, и подумав, как бы подступиться к задаче, я решаю сначала сделать экспорт скрипта создания БД с тестового сервера, и запускаю его потом на своей машине. Теперь у меня есть пустая база данных с полностью идентичной структурой и со всеми хранимыми процедурами. Останавливаю сервис MySQL, и копирую все содержимое из папки с именем нашей базы с упавшего сервера в аналогичную папку свежеустановленной локально у себя MySQL (папка с именем базы, вложенная в папку data, расположенную по пути для хранения файлов с данными указанному во время установки MySQL). При настройке локальной MySQL Server я решил указать для файлов данных InnoDB отдельную папку, куда далее скидываю восстановленный файл ibdata1. После этого перекидываю файлы InnoDB-логов (ib_logfile0 и ib_logfile1) прямо в свою папку data, где они должны быть по умолчанию.
Очередная попытка запустить MySQL снова не увенчалась успехом. Не имея реально боевого опыта в администрировании СУБД (за исключением опыта, полученного на курсах, но, опять же, по другим СУБД) я решил пойти путем эксперимента, хотя сейчас понимаю, что он совсем не был необходим. Удаляю файлы логов InnoDB, запускаю сервис MySQL и вижу, что он создает сами файлы InnoDB-логов с такими же названиями, но с размером в 20Мб.
Смотрю размер “своих” файлов с логами с упавшего сервера и вижу, что он существенно отличается и составляет 81Мб. Что-ж… останавливаю сервер, и захожу через MySQL Administrator в настройки переменных запуска (Startup Variables), вкладка InnoDB. Задаю размер log-файлов равным 81 Мб и закидываю обратно “свои” лог-файлы. MySQL запустился, но данных в интересующих меня таблицах я не увидел (хотя в таблицах, работавших на движке MyISAM, они уже были восстановлены). Немного пошарив по сети, я вычитал, что нужно запустить MySQL в режиме восстановления, для чего нужно задать значение стартовой переменно InnoDB_force_recovery равным 6. Попробовал сделать это через MySQL Administrator (ясное дело, что можно задавать параметры через GUI, а можно и редактировать файлы my.ini или my.cnf [в зависимости от версии MySQL и выбранной ОС] вручную), и, то ли я что-то не доделал, то ли что-то недосмотрел, но нужного результата не увидел. MySQL запустился как обычно, но про восстановление не сказал ни слова. “Что-ж,” – подумал я – “попробуем тогда через консоль, и еще раз явно пропишем параметр innodb_force_recovery”.
Запускаю коммандную строку Windows и ввожу:
> mysqld --console --innodb_force_recovery=6
На что в ответ получаю:
110727 10:31:52 [Note] Plugin 'FEDERATED' is disabled.
110727 10:31:52 InnoDB: Initializing buffer pool, size = 40.0M
110727 10:31:52 InnoDB: Completed initialization of buffer pool
110727 10:31:52 InnoDB: Operating system error number 32 in a file operation.
InnoDB: The error means that another program is using InnoDB's files.
InnoDB: This might be a backup or antivirus software or another instance
InnoDB: of MySQL. Please close it to get rid of this error.> mysqld --console --innodb_force_recovery=6
Пока что я не понял, в чем было дело, почему запускалось сразу два процесса. В том числе и потому, что радость охватила меня, и подключившись к базе данных через Toad for MySQL я увидел, что данные восстановленны! Эта радость отодвинула все вопросы на второй план.
Осознание победы и контрольный выстрел
“Не отходя от кассы”, я делаю дамп базы, чтобы впоследствии восстановить ее на рабочем сервере – том самом герое этой “сказки”, которому всего-то навсего поменяли жесткий диск и переустановили систему.
> mysqldump --routines -u "user" -p db_name > [path\]db_name.sql
Ввожу пароль, и получаю скрипт создания и заполнения всех таблиц базы, а также всех хранимых процедур в файле db_name.sql в указанной в параметре папке. Информация спасена!
Затем уже на рабочем сервере устанавливаю сам MySQL, настраиваю его, создаю пустую базу и скидываю в нее дамп:
В настройках клиентского приложения менять ничего не пришлось, т.к. ip-адрес и сетевое имя сервера остались теми же, что и были до падения. Зашли в систему, проверили, и – о, чудо! – вся информация на месте. Тут и сказочке конец… но остановимся на “морали сей басни".
Выводы и заключение
- Стратегия бэкапа/восстановления должна определяться уже на стадии разработки;
- В вопросах бэкапа/восстановления не надо надеяться на админов, если можешь сделать это сам; и тем более, если для тебя не составит особого труда автоматизировать этот процесс (что вполне можно сделать на примитивном уровне штатными средствами);
- Организация на предприятии и четкое регламентирование обязанностей каждого отдельного сотрудника в каждом конкретном проекте очень важны, когда мы имеем дело с IT; и современные стандарты разделения труда на IT-предприятиях очень и очень актуальны и выросли не на пустом месте;
- И все-же, если база полетела и нет бэкапа – это еще не повод сразу отчаиваться и опускать руки.
- Подставляем в папку с данными файлы данных и описаний таблиц (файлы *.frm, *.MYI и *.MYD, все в папке с именем БД — т.е. копируем всю эту папку целиком);
- В папку c файлами данных InnoDB (по умолчанию, скорее всего, это папка data, где хранятся и бинарные логи, и папки с именами БД; в моем случае я сделал для данных InnoDB отдельную папку) скидываем все файлы ibdata*. Здесь, наверное, надо отметить, что размер файлов должен соответствовать указанному в настройках. Если размеры разнятся, то можно поступить так: удалить созданный сервером файл (или файлы) вручную, и создать новый (или, соответственно, новые) с размером равным размеру имеющегося, затем запустить сервер и остановить его, и вместо созданных им файлов подставить свои. Облегчить эту операцию – чтобы не пришлось играть с настройками вручную – может MySQL Administrator. Или можно сделать еще проще – элементарно подмениь все файлы (или файл, если он один), а в файле настроек my.ini/my.cfg просто изменить размер – по идее должно сработать.
- Скидываем логи InnoDB (или подменяем, если они уже есть) туда, где они должны быть (по умолчанию, это та же папка data, где хранятся файлы с данными и описаниями, но это, опять же, может быть изменено в настройках);
- Задаем размер логов InnoDB равным размеру наших логов (если вручную – то в байтах, если в MySQL Administrator – в Мб);
- Запускаем MySQL daemon
> mysqld --console
внимательно смотрим лог, должен быть запущен сервис и выполнено восстановление; - Если восстановление не происходит, тогда в конфигурации или параметром ставим innodb_force_recovery=1 и пробуем запустить. Если не проходит, ставим innodb_force_recovery=2 и пробуем запустить. И т.д. до 6.
- И, наконец, смотрим на месте ли наши данные, и если на месте – делаем дамп базы, который потом уже разворачиваем на рабочий сервер.
Ссылки
В дополнение
PhantomTLT в комментарии подсказывает (и, опираясь на его советы, я немного скорректировал памятку выше):
Если у вас сохранился весь datadir, то никаких пустых баз с идентичной структурой создавать не нужно. Достаточно просто заменить все файлы и откорректировать размер логов InnoDB.
Далее стартуем MySQL и внимательно смотрим лог. Должен стартануть и выполнить восстановление.
Если сразу стартуете с innodb_force_recovery=6, то вы рискуете получить БД в inconsistent state. Т.е. целостность (согласованность) данных может быть нарушена.
Если вы дошли до innodb_force_recovery=6 и это не помогло, то очень грустно — нужно восстанавливать в полуручном режиме.
Как же раздражает, когда на сервере место заканчивается. Прямо слов нет.
Причем происходит это постоянно. И заканчивается, главное, "под ноль", до последнего байта, в результате чего все "падает".
Заходишь, чистишь набежавшие логи, системные бэкапы, разросшиеся таблицы в базе данных (в том же Друпал 7 была бага - таблицы с кэшем сами не очищались и за пару месяцев легко до гигабайта разрастались, хотя Друпал 8 в этом плане тоже не сильно лучше). "Окэй, пару гигабайт выгадал, живем." Но через месяц-другой по новому кругу.
Потом хостер накинул сверху еще гигабайт 5 пространства в качестве апгрейта аккаунта - жил спокойно с полгодика. А сейчас вот снова "Free space: 220MB". Как так?
Нет, ну в самом деле, как так? Ось Дебиан, из софта все по-минимуму, сайтов всего 10, из которых большинство заглушки, какое-то реальное место занимают только два-три. И при этом уходит суммарно 30 гигабайт. Так же быть не должно?
Пошел инвестигейтить, хотя надо было этим заняться еще очень давно.
Так, сайты весят сколько и должны, чуть меньше 10 гигов. Остается еще 20 гигабайт, не может же Дебиан столько "съесть".
Стал "пробивать" все подряд, сначала корневые директории, потом их содержимое. И через пять минуток натыкаюсь на это:
15 гигабайт! И что это вообще такое?
Беглое гугление показало, что ibdata1 - системный файл MySQL, в котором хранится вся информация по базам InnoDB. Проблема в том, что этот файлик умеет только в рост. Даже если дропнуть все таблицы подчистую - ibdata1 не уменьшится ни на байт. Создать новую таблицу - ibdata1 вырастет. Удалить ее через минуту - ibdata1 не изменится. Или даже снова увеличится.
Вот он и продолжал расти, день ото дня, месяц к месяцу. По чуть-чуть, но все же. За четыре года с момента изначального разворачивания окружения у меня и "накапало" 15 гигов. Ведь баз данных за это время было создано и удалено десятки, если не сотни.
Как сие пофиксить? Увы, только фактически "реланчем".
И раз: бэкапим все наши InnoDB базы, за исключением системных information_schema, mysql и performance_schema.
И два: дропаем все наши базы (акромя системых information_schema, mysql и performance_schema соответственно).
И три: выключаем MySQL.
И четыре: в конфигурационный файл my.cnf добавляем эту строчку:
Нужна для того, чтобы данные со всех InnoDB баз перестали писаться в один файлик ibdata1, и под каждую таблицу создавался свой системный файл. Вроде для MySQL 5.6 это стоит по дефолту, но у меня MySQL 5.5.
И пять: удаляем этот самый файлик ibdata1, а также файлы логов ib_logfile0 и ib_logfile1 (лежат там же).
И шесть: включаем MySQL.
И семь: импортируем наши дампы обратно.
Проверяем освободившееся место. Было 220 мегабайт. Стало 14 гигабайт. Счастье-то какое!
См. комментарии (кратко: MyISAM не имеет никакого отношения к ibdata1, если база состоит только из таких таблиц, то ее можно не трогать, также в зависимости от версии MySQL системная база mysql может содержать таблицы типа InnoDB - в таком случае их имеет смысл тоже бэкапить и восстанавливать).
1. Делаем дамп базы
Надо учесть, что базы mysql и performance_schema мы удалять не будем.
Самый простой способ, если баз не так много:Если баз много, то можно воспользоваться такой конструкцией:
Если баз, которые хочется исключить, больше двух, то можно, конечно, все их перечислить в примере выше. Но как по мне, так увеличивается вероятность ошибиться.
Поэтому я предлагаю сделать 3 простых шага:Комментарии
Нормальная тема, такая дырища в плане ресурсов на пустом месте.
Угу, погулил, у людей там и на сотни гигов разрастается, а если есть большая InnoDB табличка с частым insert/delete, так вообще в небеса улетает. По-хорошему, надо продолжать оптимизировать конфиги дальше, где возможно перейти на MyISAM, и т. д., но меня пока устроил и такой быстрофикс.
Здравствуйте. Столкнулся с такой же проблемой. Вы в статье написали первым пунктом, что нужно бэкапить все базы. Получается даже information_schema, mysql и performance_schema тоже бэкапить? И потом восстанавливать их из бэекапа?
Ответ на Здравствуйте. Столкнулся с… от Николай Александров
Нет, системные базы (information_schema, mysql и performance_schema) трогать не надо, они как были, так и остаются. Только созданные "пользовательские", я в том числе бэкапил и пересоздавал и базу под phpmyadmin, т. к. по сути тоже стороннее приложение.
Ответ на Добрый день!… от tulvit
Ответ на Спасибо за ответ. Может было… от Николай Александров
Пост поправил, спасибо!
Получается базы на MyISAM тоже можно не трогать, не удалять?
Погуглил чуток - так и есть, ibdata1 не имеет никакого отношения к MyISAM, соответственно удалять последние не нужно.
Хотя попутно возник еще один вопрос - системные базы, та же mysql, имеют таблицы как типов MyISAM, так и InnoDB и других. По идее, если мы их не бекапим, то после удаления файла ibdata1 таблицы типа InnoDB в системных базах станут "битыми". Скорее всего, ничего смертельного, т. к. вся важная информация (тот же список пользователей) хранится в MyISAM, а в InnoDB вспомогательная, которая *возможно* обновиться после рестарта базы.
Однако, еще раз бегло просмотрел кучу статей и обсуждений - нигде на этом не акцентируется внимание, "дропаем все базы кроме системных, удаляем файлик ibdata1, восстанавливаем базы из бэкапа". И вроде как никаких проблем (в том числе и у меня, во всяком случае видимых).
Возможно, имеет смысл в том числе забэкапить и системные базы, или только InnoDB таблицы из системных баз, а потом импортнуть за компанию. Но утверждать не буду, просто мысли вслух, т. к. судя по гуглу, большинство обходится и без этого.
Но в целом да, получается, что "белое пятно" все-таки остается, что не хорошо. "Копать" дальше и тестить сейчас уже видимо не буду :(
Хотя еще чуток погулил:
- information_schema по ходу дела обновляется при каждом рестарте MySQL, так что можно не переживать.
- performance_schema содержит временные данные, и тоже так и так постоянно обновляется, можно удалять, можно не удалять.
- что с mysql - кто-то делает бекап и перезаписывает, кто-то нет. Тут главное - эту базу не удалять, иначе и в БД не зайдешь, т. к. и все доступы с паролями потрутся. И еще видимо от версии MySQL зависит. На продакшене у меня MySQL 5 - в системной базе mysql не нашел ни одной InnoDB таблицы, соответственно и никаких проблем. На локальном сервере MySQL 7 - тут уже аж 19 таких таблиц насчитал. В MySQL 6 их вроде штук пять. Т. е. выходит, если в базе все-таки присутствуют InnoDB таблицы, то их имеет смысл все-таки забэкапить и потом восстановить, потаблично или сразу дампом целой базы mysql.
Зайдя в панель управления Webmin, я заметил, что практически все мое дисковое пространство заполнено. Я искал десять самых больших файлов / каталогов в моей системе и обнаружил, что файл с именем ibdata1 занимает около 94 ГБ пространства. Он находится в моем / var / lib / mysql каталоге.
Что делает ibdata1? Я в безопасности, чтобы удалить это? Я предполагаю, что это какая-то свалка, но это просто дикая догадка.
Файл ibdata1 является системным табличным пространством для инфраструктуры InnoDB.
Он содержит несколько классов для информации, жизненно важной для InnoDB
Обратите внимание на место ibdata1 во вселенной InnoDB (справа)
Вы можете отделить страницы данных и индексов ibdata1 , включив innodb_file_per_table . Это приведет к тому, что любая вновь созданная таблица InnoDB будет хранить данные и индексные страницы во внешнем .ibd файле.
-
- это / var / lib / mysql
- CREATE TABLE mydb.mytable (. ) ENGINE=InnoDB; создает /var/lib/mysql/mydb/mytable.frm
- innodb_file_per_table включен, страницы данных / индекса хранятся в /var/lib/mysql/mydb/mytable.ibd
- innodb_file_per_table отключен, страницы данных / индексов хранятся в ibdata1
Независимо от того, где хранится таблица InnoDB, функциональные возможности InnoDB требуют поиска метаданных таблицы, а также сохранения и извлечения информации MVCC для поддержки соответствия ACID и изоляции транзакции .
Вот мои прошлые статьи по отделению табличных данных и индексов от ibdata1
- Oct 29, 2010 : Мой оригинальный пост в StackOverflow
- Nov 26, 2011 : ОШИБКА 1114 (HY000) в строке 6308 в файле & Таблица user_analysis заполнена
- Feb 03, 2012 : Плановая оптимизация таблиц в MySQL InnoDB
- Mar 25, 2012 : Почему InnoDB хранит все базы данных в одном файле?
- Apr 01, 2012 : Желательно ли использовать innodb_file_per_table?
Вы можете продолжать хранить в ibdata1 все, но это делает создание снимков LVM настоящим трудоемким делом (мое личное мнение).
Вам нужно использовать мой пост StackOverflow и окончательно сжать этот файл.
Пожалуйста, запустите этот запрос:
Это скажет, сколько потраченного пространства может быть восстановлено после применения InnoDB Cleanup.
mysqldump будет только логическое представление страниц данных, а не индексов. Вам понадобится другое монтирование диска, возможно, удаленный сервер, чтобы сбросить данные.
Я знаю, что это слишком старо. Но для любого, кто придет сюда с проблемой, вам нужно заменить число 94 на любой размер вашего ibdata1 файла в ГБ, и SpaceToReclaim он даст вам размер в ГБ.
Этот файл ibdata1 не, ibdatal и он содержит все ваши базы данных InnoDB. Если вы удалите его, вы потеряете все свои данные.
Некоторые идеи о том, как с этим бороться, см. В разделе Как сжать / очистить файл ibdata1 в MySQL .
Если вы используете innodb в качестве движка MySQL, по умолчанию все ваши базы данных будут сохранены в ibdata1. Также есть файлы журналов ib_logfile0 и ib_logfile1. Не удаляйте эти файлы.
3. Тормозим mysql
Ubuntu:
CentOS 7
2. Удаляем все базы данных.
КРОМЕ mysql и performance_schema
Важно из справки по DROP DATABASE
Оператор DROP DATABASE удаляет все таблицы в указанной базе данных и саму базу. Если вы выполняете DROP DATABASE на базе данных, символически связанной с другой, то удаляется как ссылка, так и оригинальная база данных. Будьте ОЧЕНЬ внимательны при работе с этой командой!
Читайте также: