«ОШИБКА 1114 (HY000) таблица… заполнена» с innodb_file_per_table, установленной на автоматическое расширение
У меня есть база данных MySQL, которая содержит большой объем данных (100-200 ГБ — куча научных измерений). Подавляющее большинство данных хранится в одной таблице Sample . Сейчас я создаю подчиненную копию базы данных, и я хотел воспользоваться преимуществами innodb_file_per_table этого процесса. Поэтому я установил innodb_file_per_table в своей ведомой конфигурации и импортировал дамп базы данных. К моему удивлению, это не удалось с
ОШИБКА 1114 (HY000) в строке 5602: таблица «Образец» заполнена
В Sample.ibd настоящее время размер файла составляет около 93 ГБ, а в разделе доступно более 600 ГБ свободного места, поэтому проблема не связана с объемом свободного места на диске. Ни один из них, похоже, не достигает какого-либо ограничения файловой системы (я использую ext4).
Буду признателен за любые идеи, что может быть причиной, или что расследовать.
Обновление: я использую mysql Ver 14.14 Distrib 5.1.66, for debian-linux-gnu (x86_64) .
ФАКТЫ
Вы сказали, что используете ext4 . Ограничение размера файла составляет 16 ТБ. Таким образом, Sample.ibd не должно быть полным.
Вы сказали, что innodb_data_file_path это так ibdata1:10M:autoextend . Таким образом, сам файл ibdata1 не имеет ограничения на его размер, кроме как из ОС.
Почему это сообщение появляется вообще? Обратите внимание, что сообщение «Таблица . заполнена», а не «Диск . заполнен». Это полное условие таблицы с логической точки зрения . Подумайте о InnoDB. Какие взаимодействия происходят?
Я предполагаю, что InnoDB пытается загрузить 93 ГБ данных в виде одной транзакции. Откуда Table is Full исходит сообщение? Я бы посмотрел на ibdata1 не с точки зрения его физического размера (который вы уже исключили), а с точки зрения того, какие пределы транзакций достигаются.
Что находится внутри ibdata1, когда включена innodb_file_per_table и вы загружаете новые данные в MySQL?
- Словарь с данными
- Двойной буфер записи
- Сеть безопасности для предотвращения повреждения данных
- Помогает обойти ОС для кеширования
Мои подозрения говорят мне, что виноваты журналы отмены и / или журналы повторов.
Глава 10: «Двигатели хранения» Стр. 203 В пунктах 3,4 говорится следующее:
Движок InnoDB хранит два типа журналов: журнал отмены и журнал восстановления. Цель журнала отмен — откат транзакций, а также отображение более старых версий данных для запросов, выполняющихся на уровне изоляции транзакций, который требует этого. Код, который обрабатывает журнал отмены, можно найти в хранилище / innobase / buf / log / log0log.c .
Цель журнала повторов — сохранить информацию, которая будет использоваться для восстановления после сбоя. Это позволяет процессу восстановления повторно выполнять транзакции, которые могли или не могли быть завершены до сбоя. После повторного выполнения этих транзакций база данных переводится в согласованное состояние. Код, связанный с журналом повторов, можно найти в хранилище / innobase / log / log0recv.c .
АНАЛИЗ
Внутри ibdata1 находится 1023 журналов отмены (см. Сегменты отката и Пробел отмены) . Поскольку в журналах отмены сохраняются копии данных, которые были представлены до перезагрузки, все журналы отмены 1023 достигли своего предела. С другой стороны, все журналы отмены 1023 могут быть выделены для одной транзакции, которая загружает Sample таблицу.
НО ЖДАТЬ.
Вы, вероятно, говорите: «Я загружаю пустую Sample таблицу». Как задействованы Undo Logs? До Sample загрузки таблицы с 93 ГБ данных она была пустой. Представление каждой несуществующей строки должно занимать некоторое пространство для очистки в журналах отмены. Заполнение 1023 Undo Logs кажется тривиальным, учитывая объем данных ibdata1 . Я не первый человек, который подозревает это:
Из документации MySQL 4.1 обратите внимание Posted by Chris Calender on September 4 2009 4:25pm :
Обратите внимание, что в 5.0 (до 5.0.85) и в 5.1 (до 5.1.38) вы могли получить сообщение об ошибке «таблица заполнена» для таблицы InnoDB, если в InnoDB заканчиваются интервалы отмены (ошибка № 18828).
SUGGESTIONS
Когда вы создаете mysqldump Sample таблицы, пожалуйста, используйте —no-autocommit
Это будет ставить явное COMMIT; после каждого INSERT . Затем перезагрузите стол.
Если это не работает ( вам это не понравится ), сделайте это
Это заставит каждую вставку иметь только одну строку. Mysqldump будет намного больше (в 10 раз больше) и может потребовать от 10 до 100 раз больше времени для перезагрузки.
В любом случае это избавит журналы отмены от затопления.
ОБНОВЛЕНИЕ 2013-06-03 13:05 ПО ВОСТОЧНОМУ ВРЕМЕНИ
ДОПОЛНИТЕЛЬНОЕ ПРЕДЛОЖЕНИЕ
Если системная таблица InnoDB (также известная как ibdata1) выходит за пределы размера файла и Журналы отмены не могут быть использованы, вы можете просто добавить другое системное табличное пространство (ibdata2).
Я только столкнулся с этой ситуацией всего два дня назад. Я обновил свой старый пост тем, что сделал: см. Дизайн базы данных — Создание нескольких баз данных, чтобы избежать головной боли при ограничении размера таблицы.
По сути, вы должны изменить innodb_data_file_path, чтобы разместить новый системный файл табличного пространства. Позвольте мне объяснить, как:
СЦЕНАРИЙ
На диске (ext3) сервер моего клиента имел следующее:
Обратите внимание, что ibdata2 вырос до 2196875759616, что 2145386484M .
Мне пришлось вставить размер файла ibdata2 в innodb_data_file_path и добавить ibdata3
Исправляем ошибку nf_conntrack: table full, dropping packet
В данной статье речь пойдет об ошибке «nf_conntrack: table full, dropping packet», которая может появляться в логах сервера, работающего на ОС Linux и том, как эту ошибку исправить.
Описание
В случае большого количества сетевых соединений, в логах сервера, работающего под ОС Linux, может появляться следующая ошибка:
kernel: nf_conntrack: nf_conntrack: table full, dropping packet
Как видно из её текста, эта ошибка связана с тем, что переполнена таблица, в которой модуль nf_conntrack хранит всю информацию.
Для того, чтобы посмотреть текущее максимальное количество соединений, информацию о которых может хранить и обрабатывать модуль nf_conntrack, вводим следующую команду:
В нашем примере, видно, что максимальное количество соединений — 65536. Т.к. мы получаем ошибку, то увеличим число соединений в 4 раза, для этого воспользуемся следующей командой:
Т.е. мы добавляем в самый конец конфига /etc/sysctl.conf , строку net.netfilter.nf_conntrack_max = 262144
Далее, нам необходимо применить измененные настройки, для этого вводим следующую команду:И проверяем, что теперь количество одновременных соединений, которое может обслуживать модуль nf_conntrack, увеличилось в 4 раза:
Orion table is full как исправить
И на последок зачем меня ити события ? Ты что на работы решил забить ? А что удобно написал скрипт он и будет писать я пришел я ушел, хреново что в живую тебя не кто не увидеть . Но это все лирика
Зачем-зачем? Опоздал на пару минут, а кадровикам всё равно.
А развет там не паролируется содержимое базы?Кстати, в каталоге база находится
C:\Program Files\Orion752\DEMO74Там есть большие файлы:
pMaps.MB
pLogData.db0
pLogData.XG<ЦИФРА>А сами DB-файлы маленькие (меньше 100 Кб), т.е. в них точно не хранятся события.
Но однако они все связаны конкретно в LOgdata ты себя не найдешь там будеть только id сотрудника сылка на таблицу pList там хранять списки людей
Структура pLogdata