Как сжать / очистить файл ibdata1 в MySQL
Код, который не работает:
from django.contrib.auth.models import User
from django.test import Client
user = User.objects.create(username='testuser', password='12345')
c = Client()
logged_in = c.login(username='testuser', password='12345')
Почему это не работает?
В приведенном выше фрагменте, когда создан User, фактический пароль хэш установлен в 12345. Когда клиент вызывает метод login, значение аргумента password, 12345 передается через хэш-функцию, что приводит к чему-то вроде
hash('12345') = 'adkfh5lkad438....'
. Затем это сравнивается с хэш, хранящийся в базе данных, и клиенту отказано в доступе, потому что 'adkfh5lkad438....' != '12345'
Решение
Правильная вещь - вызвать функцию set_password, которая передает данную строку через хеш-функцию и сохраняет результат в User.password.
Кроме того, после вызова set_password мы должны сохранить обновленный объект User в базе данных:
user = User.objects.create(username='testuser')
user.set_password('12345')
user.save()
c = Client()
logged_in = c.login(username='testuser', password='12345')
2 ответа
То, что ibdata1 не сжимается, является особенно неприятной особенностью MySQL. Файл ibdata1 не может быть сжат, если вы не удалите все базы данных, файлы и перезагрузите дамп.
Но вы можете настроить MySQL так, чтобы каждая таблица, включая ее индексы, хранилась как отдельный файл. В этом случае размер ibdata1 не будет таким большим. Согласно комментарию Билла Карвина это включено по умолчанию, начиная с версии MySQL 5.6.6.
Это было некоторое время назад. Однако, чтобы настроить сервер на использование отдельных файлов для каждой таблицы, вам необходимо изменить my.cnf , чтобы включить это:
[mysqld]
innodb_file_per_table=1
http://dev.mysql.com/doc/refman/5.5 /en/innodb-multiple-tablespaces.html
Поскольку вы хотите освободить место из ibdata1 , вам на самом деле нужно удалить файл:
- Сделайте
mysqldumpиз всех базы данных, процедуры, триггеры и т. д. за исключениемmysqlиperformance_schemaбаз данных - Удалите все базы данных , кроме двух вышеупомянутых баз данных
- Остановить mysql
- Удалить Файлы
ibdata1иib_log - Запуск mysql
- Восстановление из дампа
При запуске MySQL на шаге 5 ibdata1 и ib_log файлы будут созданы заново.
Теперь ты готов к работе. Когда вы создаете новую базу данных для анализа, таблицы будут расположены в отдельных файлах ibd * , а не в ibdata1 . Поскольку вы обычно удаляете базу данных вскоре после этого, файлы ibd * будут удалены.
http://dev.mysql.com/doc/refman/5.1/en/drop-database.html
Вы, наверное, видели это:
http://bugs.mysql.com/bug. php? id = 1341
Используя команду ALTER TABLE или OPTIMIZE TABLE , можно извлекать данные и индексировать страницы из ibdata1 в отдельные файлы . Однако ibdata1 не сжимается, если вы не выполните описанные выше действия.
Что касается information_schema , то это не обязательно и невозможно отбрасывать. На самом деле это просто набор представлений только для чтения, а не таблиц. И с ними не связаны никакие файлы, даже каталог базы данных. informations_schema использует память db-engine и удаляется и восстанавливается при остановке / перезапуске mysqld. См. https://dev.mysql.com/doc/refman/5.7/en/information-schema.html .
Когда вы удаляете таблицы innodb, MySQL не освобождает пространство внутри файла ibdata, поэтому он продолжает расти. Эти файлы почти никогда не сжимаются.
Как сжать существующий файл ibdata:
http://dev.mysql.com/doc/refman/5.5/en/innodb-resize-system-tablespace.html
Вы можете создать сценарий и запланировать сценарий запускается через фиксированный период времени, но для описанной выше настройки кажется, что несколько табличных пространств являются более простым решением.
Если вы используете опцию конфигурации innodb_file_per_table , вы создаете несколько табличных пространств. То есть MySQL создает отдельные файлы для каждой таблицы вместо одного общего файла. Эти отдельные файлы хранятся в каталоге базы данных, и они удаляются при удалении этой базы данных. Это должно устранить необходимость сжимать / очищать файлы ibdata в вашем случае.
Дополнительная информация о нескольких табличных пространствах:
http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html