ФАКТИ
Ви сказали, що використовуєте 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 зберігає два типи журналів: журнал скасування та журнал повторень. Мета журналу скасування - це відкат транзакцій, а також відображення старих версій даних для запитів, що виконуються на рівні ізоляції транзакцій, який цього вимагає. Код, який обробляє журнал скасування, можна знайти у сховищі / inabase / buf / log / log0log.c .
Мета журналу повторень - збереження інформації, яка буде використовуватися при відновленні аварійних ситуацій. Це дозволяє процесу відновлення повторно виконувати транзакції, які можуть бути, а можуть і не завершитися до збоїв. Після повторного здійснення цих транзакцій база даних приводиться в стійкий стан. Код, що стосується журналу повтору, можна знайти у сховищі / inabase / log / log0recv.c .
АНАЛІЗ
Всередині ibdata1 є 1023 журнали скасування (Дивіться сегменти відкоту та Скасувати пробіл) . Оскільки журнали скасування зберігають копії даних, як вони з'явилися перед перезавантаженням, всі 1023 скасування журналів досягли своєї межі. З іншого боку, всі 1023 скасування журналів можуть бути присвячені одній транзакції, що завантажує Sampleтаблицю.
АЛЕ ЗАЧЕКАЙТЕ ...
Ви, напевно, говорите "Я завантажую порожню Sampleтаблицю". Як беруть участь Скасувати журнали? Перед тим, як Sampleтаблиця була завантажена 93 Гб даних, вона була порожньою. Представляючи кожен ряд, який не існував, потрібно зайняти деякий простір для прибирання в журналах скасувати. Заповнення 1023 скасування журналів здається тривіальним, враховуючи кількість даних, що заливаються ibdata1. Я не перша людина, яка підозрює це:
З Документації MySQL 4.1 зверніть увагу Posted by Chris Calender on September 4 2009 4:25pm:
Зауважте, що в 5.0 (pre-5.0.85) та 5.1 (pre-5.1.38) ви можете отримати помилку "таблиця повна" для таблиці InnoDB, якщо InnoDB закінчиться відмінити слоти (помилка №18828).
Ось звіт про помилки для MySQL 5.0: http://bugs.mysql.com/bug.php?id=18828
ПРОПОЗИЦІЇ
Створюючи mysqldump Sampleтаблиці, використовуйте --no-autocommit
mysqldump --no-autocommit ... mydb Sample > Sample.sql
Це ставитиме явне COMMIT;після кожного INSERT. Потім перезавантажте таблицю.
Якщо це не працює ( вам це не подобається ), зробіть це
mysqldump --no-autocommit --skip-extended-insert ... mydb Sample > Sample.sql
Це зробить кожен ВСТУП мати лише один ряд. Mysqldump буде набагато більшим (у 10+ разів більшим) та може зайняти від 10 до 100 разів більше часу для перезавантаження.
У будь-якому випадку це позбавить журналів відміни від затоплення.
Спробувати !!!
ОНОВЛЕННЯ 2013-06-03 13:05 EDT
ДОДАТКОВІ ПРОПОЗИЦІЇ
Якщо системна таблиця InnoDB (aka ibdata1) вражає обмеження розміру файлів, а журнали скасування скасувати неможливо, ви можете просто додати інший системний простір таблиць (ibdata2).
Я просто зіткнувся з цією ситуацією лише два дні тому. Я оновив стару публікацію тим, що робив: Див. Дизайн баз даних - Створення декількох баз даних, щоб уникнути головного болю обмеження розміру таблиці
По суті, вам потрібно змінити innodb_data_file_path, щоб вмістити новий файл системного простору таблиць. Дозвольте мені пояснити, як:
СЦЕНАРІО
На диску (ext3) сервер мого клієнта мав таке:
[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql 362807296 Jun 2 00:15 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun 2 00:15 ibdata2
Налаштування було
innodb_data_file_path=ibdata1:346M;ibdata2:500M:autoextend:max:10240000M
Зауважимо, що ibdata2виріс до 2196875759616, що є 2145386484M.
Мені довелося вставити розмір файлів ibdata2в innodb_data_file_path та додатиibdata3
innodb_data_file_path=ibdata1:346M;ibdata2:2196875759616;ibdata3:10M:autoextend
Коли я перезапустив mysqld, він працював:
[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql 362807296 Jun 3 17:02 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun 3 17:02 ibdata2
-rw-rw---- 1 s-em7-mysql s-em7-mysql 32315015168 Jun 3 17:02 ibdata3
За 40 годин ibdata3виріс до 31G. MySQL знову працював.