Innodb error could not open single table tablespace file

I have AMPPS installed on my Windows 10.

I was unable to start MySQL. I have searched through this error and tried different things to recover my data.

This was the error log:

2016-02-03 10:19:54 6448 [Warning] You need to use --log-bin to make --binlog-format work.
2016-02-03 10:19:54 6448 [Note] Plugin 'FEDERATED' is disabled.
2016-02-03 10:19:54 6448 [Note] InnoDB: Using atomics to ref count buffer pool pages
2016-02-03 10:19:54 6448 [Note] InnoDB: The InnoDB memory heap is disabled
2016-02-03 10:19:54 6448 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2016-02-03 10:19:54 6448 [Note] InnoDB: Memory barrier is not used
2016-02-03 10:19:54 6448 [Note] InnoDB: Compressed tables use zlib 1.2.3
2016-02-03 10:19:54 6448 [Note] InnoDB: Not using CPU crc32 instructions
2016-02-03 10:19:54 6448 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2016-02-03 10:19:54 6448 [Note] InnoDB: Completed initialization of buffer pool
2016-02-03 10:19:54 6448 [Note] InnoDB: Highest supported file format is Barracuda.
2016-02-03 10:19:54 6448 [Note] InnoDB: The log sequence numbers 0 and 0 in ibdata files do not match the log sequence number 132125643 in the ib_logfiles!
2016-02-03 10:19:54 6448 [Note] InnoDB: Database was not shutdown normally!
2016-02-03 10:19:54 6448 [Note] InnoDB: Starting crash recovery.
2016-02-03 10:19:54 6448 [Note] InnoDB: Reading tablespace information from the .ibd files...
2016-02-03 10:19:54 6448 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace mysql/innodb_table_stats uses space ID: 1 at filepath: .mysqlinnodb_table_stats.ibd. Cannot open tablespace scrapers/openpasts_records which uses space ID: 1 at filepath: .scrapersopenpasts_records.ibd
InnoDB: Error: could not open single-table tablespace file .scrapersopenpasts_records.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.

I have tried setting innodb_force_recovery = 1 in my.cnf

Also I have tried removing ibdata1 file as well.

After removing ibdata1, MySQL started perfectly.

and my table shows in PHPmyADMIN, but when I click on it it says table does not exists even it exists

In my D:Amppsmysqldatascrapers directory, I can see records.ibd file and records.frm file as well. That means table physically exists but is corrupted.

Does someone know how do I recover that table?

Hi, we have an enterprise server where we run MariaDB 10.1.14. We are upgrading the OS on our server and in order to do that, we are taking backup of MariaDB through dump as well taking binary backup.

Once OS installation is done, we restore the database using dump and once database is restarted we get error messages such as

Logs:

[Warning] InnoDB: Cannot open table mysql/gtid_slave_pos from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.

2017-05-23 2:36:19 140199378811648 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1932: Table ‘mysql.gtid_slave_pos’ doesn’t exist in engine

2017-05-23 2:36:19 140199022545664 [Warning] InnoDB: Cannot open table mysql/gtid_slave_pos from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.

2017-05-23 2:36:19 140199022545664 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1932: Table ‘mysql.gtid_slave_pos’ doesn’t exist in engine

2017-05-23 02:36:20 7f82a0efcb00 InnoDB: Error: Table «mysql».»innodb_table_stats» not found.

It generally doesnt seems to cause much problem. But if we do force shutdown of our servers to replicate power failure scenario, after start up MariaDB refuses to come up with below errors

Crash Logs

2017-05-24 2:24:18 140306666678400 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace MyDB/My_backup uses space ID: 3 at filepath: ./MyDB/My_backup.ibd. Cannot open tablespace mysql/gtid_slave_pos which uses space ID: 3 at filepath: ./mysql/gtid_slave_pos.ibd

2017-05-24 02:24:18 7f9bb106e880 InnoDB: Operating system error number 2 in a file operation.

InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: Error: could not open single-table tablespace file ./mysql/gtid_slave_pos.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.

I have following question in this regard

1. Is it really gtid_slave_pos which is causing the crash

2. I can recover if I use innodb_force_recovery, take dump, deleted ib files and restart database. However it will be good if at first place we do not come across this situation at all.

3. Is there a way where in after restore I can make sure these errors do not appear at all?

4. Is it normal for innodb to crash in case of power failure and not recover? I know innodb tries its best to do crash recovery.

Any kind of help in this reagrad will be appreciated.

I use MAMP Pro for some of my local pet projects and development. Normally it works great, but the other day I couldn’t get MySQL started. It kept crashing during startup. This post explains the related errors and how I managed to resolve the issue and get MAMP working again.

The Error

Here are the associated errors and infos recorded in the MAMP log file:

[ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace perishable/accounts uses space ID: 1 at filepath: ./perishable/accounts.ibd. Cannot open tablespace mysql/innodb_table_stats which uses space ID: 1 at filepath: ./mysql/innodb_table_stats.ibd

Operating system error number 2 in a file operation. The error means the system cannot find the path specified. If you are installing InnoDB, remember that you must create directories yourself, InnoDB does not create them.

Error: could not open single-table tablespace file ./mysql/innodb_table_stats.ibd

We do not continue the crash recovery, because the table may become corrupt if we cannot apply the log records in the InnoDB log to it. To fix the problem and start mysqld:

1) If there is a permission problem in the file and mysqld cannot open the file, you should modify the permissions.
2) If the table is not needed, or you can restore it from a backup, then you can remove the .ibd file, and InnoDB will do a normal crash recovery and ignore that table.
3) If the file system or the disk is broken, and you cannot remove the .ibd file, you can set innodb_force_recovery > 0 in my.cnf and force InnoDB to continue crash recovery here.

I tried several times to start the service, restart MAMP, restart the computer, etc., but nothing seemed to work. The MySQL server would not start.

The Solution

To get MySQL started and working again, open MAMP and go to File > Edit Template > MySQL > and select your MySQL version. That will open the MySQL configuration file, where you can locate the following line:

#innodb_force_recovery = 2

Uncomment the line, and change the value to 1, so it looks like this:

innodb_force_recovery = 1

Then restart MySQL and try again. If it works, you can comment out (disable) the line by prepending a pound sign # (hashtag whatever you want to call it). For more information about what innodb_force_recovery is doing, check out the MySQL documentation.

Note: This technique is known to work with MAMP Pro, but it also may work on the free version of MAMP. Good luck!

Код: Выделить всё

# uname -a
FreeBSD server 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Feb 18 02:24:46 UTC 2011     root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

Код: Выделить всё

# pkg_info | grep mysql
mysql-client-5.5.9  Multithreaded SQL database (client)
mysql-server-5.5.9  Multithreaded SQL database (server)

Код: Выделить всё

%cat /etc/my.cnf 
# Этот конфигурационный файл сделан на основе файла для маленьких
# систем - /usr/local/share/mysql/my-small.cnf. Большую часть его
# делал не я, а один знакомый. Имени, к сожалению, не помню...
# Но всё же предупреждаю - копирайт на настройки конфига не мой :))
#
# Вообще, конфигурационный файл можно положить в несколько мест:
# /etc/my.cnf
# /var/db/mysql/my.cnf
# /usr/local/etc/my.cnf
# В любом из них mysqld его найдёт, и достанет из него настройки.
# Самое корректное место, если судить по стартовому скрипту, это
# директория где лежат базы данных - /var/db/mysql/my.cnf.


# Опции для всех клиентов MySQL
[client]
# Пароль для подключения к БД
#password       = your_password
# Порт на котором висит MySQL
port            = 3306
# Сокет MySQL
socket          = /tmp/mysql.sock


# Опции MySQL-сервера
[mysqld]
# Порт
port            = 3306
# Адрес, который будем слушать (если вам не нужно подключаться к
# MySQL с других машин, то оставьте здесь 127.0.0.1)
bind-address    = 127.0.0.1
# Где лежит сокет
socket          = /tmp/mysql.sock
# Не использовать средства системных блокировок.
skip-locking
# Вообще, в новых версиях, (после 3.21) этот пункт правильно называется
# key_buffer_size, но можно использовать и старое имя. Значение этого
# пункта - размер буфера, используемого для блоков индексов. Чтобы
# улучшить обработку индексов (для всех операций чтения и записи нескольких
# элементов), необходимо увеличить это значение настолько, насколько возможно.
# Рекомендуется, 1/4 от объёма оперативки, но не более 1/2 - иначе система
# может начать сохранять временные файлы на диске, что значительно
# снизит производительность.
key_buffer = 16K
# Максимальный размер одного пакета. Изначально размер буфера сообщений
# устанавливается в net_buffer_length байтов, но при необходимости может
# возрасти до max_allowed_packet байтов. Это значение по умолчанию не
# настолько велико, чтобы отсеивать большие (возможно ошибочные) пакеты.
# Если используются большие столбцы BLOB, его необходимо увеличить.
# Значение должно быть не меньше самого большого BLOB, который будет
# использоваться. Ограничение протокола для max_allowed_packet
# составляет 16 Мб в MySQL 3.23 и 1Гб в MySQL 4.0.
max_allowed_packet = 1M
# Количество открытых таблиц для всех потоков. С увеличением этого
# значения увеличивается количество дескрипторов файлов, необходимых
# для mysqld. Чтобы узнать, необходимо ли изменять значение кэша таблиц,
# следует проверить значение переменной Opened_tables.
# Если у этой переменной большое значение, а команда FLUSH TABLES
# (которая закрывает все таблицы, а потом открывает их повторно)
# используется не часто, то необходимо увеличить ее значение.
table_cache = 4
# Каждый поток, которому необходимо произвести сортировку, выделяет
# буфер данного размера. Увеличение данного значения позволит ускорить
# выполнение операторов ORDER BY или GROUP BY.
sort_buffer_size = 64K
# Каждый поток, осуществляющий последовательное сканирование, выделяет
# буфер указанного размера для каждой сканируемой таблицы. Если
# проводится много последовательных сканирований, это значение
# можно увеличить.
read_buffer_size = 256K
# При считывании строк, после проведения сортировки, в отсортированном
# порядке строки считываются через буфер, чтобы избежать операций поиска
# по диску. Это может улучшить выполнение ORDER BY весьма и весьма,
# если параметр установлен в большое значение. Т.к. эта переменная
# имеет отношение к потоку, то не устанавливайте слишком большое
# значение глобально, но просто меняйте его при выполнении некоторых
# больших запросов.
read_rnd_buffer_size = 256K
# В данное значение устанавливается, в промежутках между запросами,
# буфер соединения. Обычно это значение не изменяется, но если у вас
# очень мало памяти, можно установить его по размеру ожидаемого
# запроса (т.е. равным предполагаемой длине операторов SQL, отправляемых
# клиентами; если оператор превысит указанную длину, буфер будет
# автоматически увеличен как максимум до max_allowed_packet байтов).
net_buffer_length = 2K
# Размер стека для каждого потока. От данного значения зависит большое
# количество ограничений, обнаруживаемых при помощи теста crash-me.
# По умолчанию этот размер достаточен для нормальной работы.
thread_stack = 64K

# Вообще не слушать порты TCP/IP. Это может применяться для большей
# безопасности, если все процессы, соединяющиеся с MySQL висят на томже
# хосте, что и mysqld. Все взаимодействия с mysqld будут осуществляться
# через Unix-сокеты, или именованые каналы.
# Заметтьте, что использование этой опции под форточками, без включчения
# именованных каналов (используйте опцию "enable-named-pipe") сделает
# работу MySQL бесполезной - ибо с mysqld никто не сможет соединиться :)
skip-networking
# Если Вы используете InnoDB, то закомментируйте эту опцию
skip-innodb
# С этой опцией MySQL не будет инициализировать библиотеку Berkeley DB,
# что позволит сэкономить большое количество памяти.
skip-bdb
# Hекоторое уникальное число между 2 и 2^32-1. Значения server-id должны
# быть различными на каждом сервере, участвующем в репликации. Если
# значение server-id не определено, оно будет установлено в 1, если
# также не определено значение master-host, оно будет установлено в 2.
# Обратите внимание, что если значение server-id опущено, то головной
# сервер будет отказывать в соединении всем подчиненным серверам, а
# подчиненный сервер - отказывать в соединении головному серверу.
# Таким образом, опускать установку значения server-id можно лишь в
# случае резервного копирования с использованием двоичного журнала.
server-id       = 1
# Раскомментируйте эту опцию, для включения логгирования всех запросов
# Заметтьте - тока на время отладки! Потом надо закомментить и
# рестартануть MySQL!
# Файл должен существовать, с соответствующими правами на него:
# touch /var/log/mysql.log
# chown mysql:wheel /var/log/mysql.log
# chmod 640 /var/log/mysql.log
log            = /var/log/mysql.log

# Указывает местоположение двоичного журнала обновлений,
# в котором будут вестись записи.
#log-bin=mysql-bin

[mysqldump]
# Если задан этот параметр, то обработчик таблицы при выполнении
# удаления не будет объединять индексы - в некоторых случаях это
# может ускорить данную операцию
quick
# Максимальная величина пакета, посылаемого/принимаемого с сервера
max_allowed_packet = 16M

[mysql]
# Отключает автоматическое рехеширование. rehash следует использовать
# для получения хеша таблиц и полей. Это обеспечивает более
# быстрый старт mysql.
no-auto-rehash
# Опция, которую рекомендуется раскомментить начинающим :)
# Разрешает выполнять только операции UPDATE и DELETE, используя ключи.
#safe-updates

[isamchk]
key_buffer = 8M
sort_buffer_size = 8M

[myisamchk]
key_buffer = 8M
sort_buffer_size = 8M

[mysqlhotcopy]
# Допускать простой длительностью interactive_timeout секунд (вместо
# wait_timeout секунд) перед закрытием данного соединения.
interactive-timeout

# P.S. Большинство текста - это из мануала по MySQL 4.0, за который
# мы не так давно воевали на www.mysql.com (его убирали на некоторое
# время, типа он по старой версии, потому не актуален...
# но - отвоевали, вернули :))))

Код: Выделить всё

%/usr/local/etc/rc.d/mysql-server start
/usr/local/etc/rc.d/mysql-server: WARNING: failed precmd routine for mysql

Код: Выделить всё

# /usr/local/etc/rc.d/mysql-server start
Starting mysql.