Файл журнала отсутствует, как может я видеть то, что и что произошло с ним
Можно увеличить тайм-аут блокировки с InnoDB:
Отредактируйте/etc/my.cnf или/etc/mysql/my.cnf (предполагающий, что Вашей dev машиной является Linux/Unix),
Некомментарий (или добавляют), строка:
innodb_lock_wait_timeout = 50
И измените настройки к большему числу, скажите 300. Это находится в секундах.
Перезапустите mysql и повторно выполните Ваш запрос.
С другой стороны, можно вывести данные, отбросить таблицу, воссоздать его с индексом и возвратить данные в. Или Вы могли составить новую таблицу с индексом и выбрать данные старой таблицы в новую таблицу. В обоих этих случаях можно повредить импорт/копию данных в мелкие кусочки (чтение: транзакции), который не превысит тайм-аут.
Реклама a). Файл был удален, возможно процессом 2147 самим. Это - обычная практика, если Вы нуждаетесь в рабочем файле (не файл журнала) для создания файла, получаете дескриптор к нему и затем удаляете его. Удаление удалит запись в каталоге, в котором был создан файл, таким образом, для других процессов не возможно получить доступ к нему. Удобная временная память, которую никто не может изучить. Когда процесс закрывает файл и больше нет дескрипторов к нему, файловая система отметит блоки, занятые данными файла временной памяти как неиспользованные. Если это действительно был файл журнала, это, возможно, было удалено (например, случайно), таким образом, процесс все еще пишет в свой журнал, но никто больше не может читать, это (думайте: память только для записи ;)).
Реклама b) Вы не может получить доступ к содержанию файла нормальным способом, т.е. получающий доступ к файловой системе нормальным способом. Необходимо было бы начать получать доступ к данным ниже файловой системы, ища блоки, которые содержат данные временной памяти. Если Вы хотите попробовать это, затем смонтировать файловую систему, содержащую удаленный файл, только для чтения, как только Вы уничтожаете 2147, или Вы рискуете данными, перезаписываемыми однажды 2 147 выходов, и блоки, содержащие его данные, будут отмечены как неиспользованные. Как точно находят блоки данных, в которых Вы нуждаетесь? Извините, наклон помогает Вам там :(.
Если directoty, в котором находится файл журнала, был сверхсмонтирован (что каталог или один из его родителей использовались в качестве точки монтирования), то Вы не можете видеть файл журнала. Это только вероятно, если дескриптор файла журнала был открыт, прежде чем монтирование произошло, И дескриптор файла НЕ был закрыт (т.е. программа не закрывает файл журнала после каждой записи и вновь открыла его для записи последующих записей).
Если это произойдет то будет некоторое доказательство в различиях между выводом mount команда и /proc/2147/mounts. Вы могли бы (я предполагать) смочь получить доступ к сверхсмонтированному файлу (большая сила) по ссылкам дескриптора файла в /proc/2147/fd.
Как упомянуто в Пересоединении удаленного файла, можно использовать /proc/<pid>/fd/N от lsof, чтобы получить копию открытого дескриптора файла и скопировать данные. См. также Возвращают удаленные файлы с lsof. Обратите внимание, что необходимо заставить исходный процесс прекратить писать в дескриптор файла (например, останавливать процесс). Кроме того, мне кажется, что Вы хотели бы к lseek к позиции 0 по дескриптору файла (потребует небольшого кода), но у меня нет статьи, упоминают это, поэтому возможно, я ошибаюсь.
Первая статья также упоминает несколько более опасный метод использования debugfs также.