Автору уже вряд ли надо, а на будущее вот рецепт.

saefido71. Можно ли восстановить из временного файла хотя бы ту информацию, которая успела туда записаться?

Восстановить можно, и скорее всего почти все.

Для работы понадобится новый диск, на котором можно работать, не перезеписав данные на оригинальном диске.
Например, если раздел с данными был на /dev/sda - работаем на /dev/sdb. Можно примонтировать удаленный NFS, но будет медленно.

Итак, рабочая директория на другом диске - /dev/sdb

Качаем последнюю ревизию Recovery toolkit:

# bzr branch lp:percona-data-recovery-tool-for-innodb

Компилируем. (Оно потребует ncurses-dev и mysql-devel - ставим предварительно).

# make

Дальше page_parser ищет InnoDB страницы.
Можно просканировать временный файл
# ./page_parser -f "#sql-931_1d.ibd"
а можно и весь раздел.

# ./page_parser -f /dev/sda

В первом случае вы получите страницы с данными, которые успели переписаться во временную таблицу.
Во втором - все возможные InnoDB страницы которые только были на диске .

Дальше процедура будет отличаться для первого и второго случая.

Случай №1.
page_parser сгенерирует директорию pages-XXXXX, где XXXX - время в секундах. Внутри еще две директории: FIL_PAGE_INDEX, FIL_PAGE_TYPE_BLOB . Внутри FIL_PAGE_INDEX/ будет несколько директорий вида 0-XYZ . Например, 0-100, 0-101, 0-102.
Нам нужна директория с минимальным числом - 0-100 - тут хранятся данные.

Утилита constraints_parser может достать эти данные из директории pages-XXXXX/FIL_PAGE_INDEX/0-100 .
Но ей надо знать структруру таблицы. Можно ручками описать структуру в файле include/table_defs.h , но лучше ее сгенерировать с помощью
./create_defs.pl . Эта утилита подключается к живому MySQL серверу, читает структуру нужной таблицы и генерирует table_defs.h в стандартный вывод.

# ./create_defs.pl --db test --table AGGREGATES --host a.b.c.d --user root --password qwerty > include/table_defs.h

Проверяем include/table_defs.h на предмет того, что в нем перечислены все поля и нет ошибок.
Дальше перекомпилируем еще раз

# make

Ну и наконец, достаем данные:

./constraints_parser -5f pages-XXXXX/FIL_PAGE_INDEX/0-100 > dump 2> load.sql

таблица в текстовом дампе будет в файле dump, а LOAD DATA INFILE команда , чтобы загрузить этот файл, будет в load.sql

Случай №2.

Задача усложняется тем, что мы не знаем в какой из директорий 0-xyz хранилась наша таблица. МОжно поискать grep-ом или угадать судя по размеру директории. Можно поискать в InnoDB словаре.
Когда директория найдена, задача сводится к случаю №1.

saefido72. Насколько трудоемок этот процесс?


Как видите, задача тривиальная ;-)

tanglirsaefido7, в порядке бреда:

поднимаете отдельный mysql сервер(чтобы ещё чего-нибудь не потерять)
ставите там режим innodb_file_per_table=1
создаёте таблицу aggregates с такой же структурой, что и у утерянной
тормозите mysql
ищете файл aggregates.ibd
заменяете его вашим куском (только название оставьте aggregates.ibd)
стартуете mysql
скорее всего, ничего не получается, но вдруг?..

Идея может выстрелить. Но space_id в ibd файле будет отличаться. Как лечить, я писал тут - http://www.mysqlperformanceblog.com/2011/05/13/connecting-orphaned-ibd-files/


Chris Calender предложил еще один метод http://www.chriscalender.com/?p=28 .