Я пытаюсь добавить строку в таблицу InnoDB с помощью простого запроса:
INSERT INTO zip_codes (zip_code, city) VALUES ('90210', 'Beverly Hills');
Но когда я пытаюсь выполнить этот запрос, я получаю следующее:
ERROR 1114 (HY000): The table `zip_codes` is full
Выполнение "SELECT COUNT (*) FROM zip_codes" дает мне 188 955 строк, что не кажется слишком большим, учитывая, что у меня есть другая таблица с 810 635 строками в этой же базе данных.
Я довольно неопытен с движком InnoDB и никогда не испытывал этой проблемы с MyISAM. Каковы некоторые из потенциальных проблем здесь?
EDIT: Это происходит только при добавлении строки в таблицу zip_codes.
РЕДАКТИРОВАТЬ: Сначала проверьте, не закончилось ли пространство диска, прежде чем разрешать разрешение, связанное с конфигурацией.
У вас, кажется, слишком низкий максимальный размер для innodb_data_file_path в my.cnf, в этом примере
innodb_data_file_path = ibdata1:10M:autoextend:max:512M
вы не можете размещать более 512 МБ данных во всех таблицах innodb вместе.
Возможно, вам нужно переключиться на схему innodb-per-table с помощью innodb_file_per_table.
Другая возможная причина заключается в том, что раздел является полным - это то, что случилось со мной сейчас.
Вы также получите ту же ошибку ERROR 1114 (HY000): Таблица '# sql-310a_8867d7f' заполнена
если вы попытаетесь добавить индекс в таблицу, в которой используется механизм хранения MEMORY.
Вам нужно изменить ограничение ограничения, установленное в my.cnf для таблиц INNO_DB. Этот лимит памяти не установлен для отдельных таблиц, он установлен для всех таблиц, объединенных.
Если вы хотите, чтобы память автоматически расширялась до 512 МБ
innodb_data_file_path = ibdata1:10M:autoextend:max:512M
Если вы не знаете предела или не хотите устанавливать ограничение, вы можете его изменить следующим образом
innodb_data_file_path = ibdata1:10M:autoextend
Эта ошибка также появляется, если раздел, в котором находится tmpdir, заполняется (из-за таблицы изменений или другой
В моем случае это произошло потому, что раздел, на котором размещен файл ibdata1, был заполнен.
У вас может быть нехватка места в разделе, где хранятся таблицы mysql (обычно/var/lib/mysql) или где хранятся временные таблицы (обычно/tmp).
Вы можете: - контролировать свое свободное пространство во время создания индекса. - укажите переменную MySQL tmpdir в другое место. Для этого требуется перезагрузка сервера.
Если вы используете NDBCLUSTER в качестве механизма хранения, вы должны увеличить DataMemory и IndexMemory.
Я тоже столкнулся с этой ошибкой при импорте файла базы данных sql 8GB. Проверил мой установочный диск mysql. Там не было места в диске. Так что получили немного места, удалив ненужные элементы, и снова запустили мою команду импорта базы данных. На этот раз это было успешно.
Если вы не включили опцию innodb_file_per_table, InnoDB хранит все данные в одном файле, обычно называемые ibdata1.
Проверьте размер этого файла и убедитесь, что на диске, на котором он находится, достаточно места на диске.
у нас было: SQLSTATE [HY000]: Общая ошибка: 1114 Таблица 'catalog_product_index_price_bundle_sel_tmp' заполнена
решена:
изменить конфигурацию db:
nano/etc/my.cnf
tmp_table_size = 256M max_heap_table_size = 256M
Чтобы процитировать документы MySQL.
Механизм хранения InnoDB поддерживает таблицы InnoDB в табличном пространстве, которое может быть создано из нескольких файлов. Это позволяет таблице превышать максимальный размер отдельного файла. В табличное пространство могут входить необработанные разделы диска, что позволяет использовать чрезвычайно большие таблицы. Максимальный размер табличного пространства - 64 ТБ.
Если вы используете таблицы InnoDB и выходите из комнаты в табличном пространстве InnoDB. В этом случае решение заключается в расширении табличного пространства InnoDB. См. Раздел 13.2.5, [ "Добавление, удаление или изменение размера данных и файлов журнала InnoDB".]
в моем случае это просто потому, что сервер mysql работает вместе с приложением, которое записывает слишком много журналов о том, что диск заполнен.
Вы можете проверить, достаточно ли места на диске
df -h
если процент использования диска составляет 100%, вы можете использовать эту команду, чтобы найти, какой каталог слишком велик
du -h -d 1 /
В моем случае память сервера была заполнена, поэтому БД не смогла записать временные данные. Чтобы решить эту проблему, вам просто нужно место на вашем диске.
Я столкнулся с такой же проблемой из-за низкого дискового пространства. И раздел, в котором размещен файл ibdata1, являющийся системным табличным пространством для инфраструктуры InnoDB, был заполнен.
Я столкнулся с этой проблемой... в моем случае у меня закончилось хранение на выделенном сервере. Убедитесь, что если все остальное не удается и рассмотрит увеличение дискового пространства или удаление нежелательных данных или файлов.
В CentOS 7 просто остановка и запуск службы MySQL исправили это для меня.
sudo service mysql stop
sudo service mysql start
Я исправил эту проблему, увеличив объем памяти, доступной для бродячей виртуальной машины, на которой находилась база данных.
В моем случае я пытался выполнить команду изменения таблицы, и доступное дисковое пространство было меньше размера таблицы. Однажды я увеличил дисковое пространство, проблема ушла.
ПОЛЬЗОВАТЕЛИ DOCKER: Это также происходит, когда вы достигли около 90% предела размера изображения Docker (кажется, что для кэширования требуется около 10%). Формулировка вводит в заблуждение, поскольку это просто означает количество дискового пространства, которое Docker может использовать практически для всего.
Чтобы исправить это, перейдите в настройки рабочего стола Docker> Диск> переместите ползунок немного вправо> Применить.
Это также может быть предел InnoDB для количества открытых транзакций:
http://bugs.mysql.com/bug.php?id=26590
в 1024 транзакции, которые отменяют записи (как в, отредактированные любые данные), InnoDB не сможет работать