table is in the system tablespace 0 which cannot be discarded - mysql

I am trying to run this query:
alter table about_member discard tablespace;
But when I do, my error logs are outputting this:
InnoDB: Error: table `diskise`.`about_member`
InnoDB: is in the system tablespace 0 which cannot be discarded
What can I do so I can discard this tablespace so I can import a backup that I have?

See this manual page:
By default, all InnoDB tables and indexes are stored in the system tablespace. As an alternative, you can store each InnoDB table and its indexes in its own file. This feature is called “multiple tablespaces” because each table that is created when this setting is in effect has its own tablespace.
Advantages of Per-Table Tablespaces
You can reclaim disk space when truncating or dropping a table. For tables created when file-per-table mode is turned off, truncating or dropping them creates free space internally in the ibdata files. That free space can only be used for new InnoDB data.
It sounds like you created your table in the default tablespace, so you cannot discard the tablespace. That said, you should be able to import data without discarding a tablespace first, unless you're just out of disk space.

I just ran into same problem while I was trying to restore one table from .ibd file. I know it's been a long time so I wrote this here for people who still running into the same problem.
Continuing with #Ed Cottrell's answer, you will need to change the mysql global variable innodb_file_per_table to let mysql to store .ibd in your own file instead of using system tablespace.
To achieve this you can do (also see official docs):
change your my.cnf file, adding following line and restart mysql server
[mysqld]
innodb_file_per_table=1
set global variable in mysql command (sometimes not working due to security issue)
SET GLOBAL innodb_file_per_table=1;
You may need to DROP your table before this take effects.
After doing this, you will be able to see .ibd files inside PATH/TO/MYSQL/DB_NAME directory (e.g. /var/lib/mysql/DB_NAME).

Related

MySQL server crashes, InnoDB outside the tablespace bounds

I have a C# application performing some database operations on a MySQL 5.7 server. Once the complete system hunp up and I had to hard-reset it. When it comes to a specific table read/write operation now the database server crashes. The windows log shows
InnoDB: Trying to access page number 286720 in space 29,
space name myInstance/myTable, which is outside the tablespace bounds.
Byte offset 0, len 16384, i/o type read.
I tried to use mysqlcheck --repair but it fails because note : The storage engine for the table doesn't support repair.
I've read some advices that say I should start MySQL in a recovery mode, so I added
[mysqld]
innodb_force_recovery=4
to the my.ini config file whereupon I should be able to use mysqldump to export the affected database table. But unfortunatelly I am not.
mysqldump: Error 2013: Lost connection to MySQL server
during query when dumping table `myTable` at row: 1246
Edit:
I checked the error log again and found lots of entries saying
[ERROR] C:\Program Files\MySQL\MySQL Server 5.7\bin\mysqld.exe:
The table 'myTable' is full
I'm running the server on a Windows 32bit OS with an NTFS formatted partition. The myTable.ibd file size is around 4.5 GB, checking C.10.3 Limits on Table Size states a file size limit of "2TB (possibly larger)" for Win32 w/ NTFS.
While checking the reasons for my error the only possible cause I found was a full InnoDB tablespace. The solution might be "Changing the Number or Size of InnoDB Redo Log Files" although the coherence is a bit vague to me. Nevertheless I increased the size of the Redo Log Files from 48M to 100M. But nothing changed.
If I perform a SQL select * from myTable order by Id desc the server crashes instantly. Error log entry is exactly the same as above.
I checked the chapter 15.7.1 Resizing the InnoDB System Tablespace as well and found out that innodb_data_file_path is not explicitly specified.
Any ideas what I can do now? Thanks a lot!
InnoDB cannot repair corruption in tablespaces. This was never implemented and mysqlcheck won't help in any way.
The corruption is in space id 29 which is table myInstance.myTable. To repair it you need to dump all records from this table with innodb_force_recovery. Try all values from 4 to 6 until MySQL doesn't crash. Then drop the table and reload the dump.
If MySQL crashes even with innodb_force_recovery=6 then restore the table from backup.
If you don't have backup - use script http://bazaar.launchpad.net/~percona-dev/percona-data-recovery-tool-for-innodb/trunk/view/head:/fetch_data.sh . It will fetch as many records as it can.
One possible cause could be that the ib_logfile* files are corrupted.
To fix this, remove these files using rm ib_logfile*.
Where are these files?
These files are in mysql datadir. The location of datadir depends on the OS. Check my.cnf, in osx that should be in /usr/local/etc.

MySQL varaible innodb_file_per_table in production activate

I have a MySQL-Server 5.5 with around 5.000.000 records in each table.
Now i want to activate the variable "innodb_file_per_table = 1".
Is this possible?
Is there any risk to do that?
The Reason is for activating the option, is to optimize performance.
Thanks and Regards
Chris
innodb_file_per_table is a dynamic variable -- changing it can safely be done without even restarting the server... but the big caveat is that you can never reclaim the disk space consumed by the ibdata file.
Tables that are rebuilt with the setting enabled will have their own tablespace files, but ibdata1 cannot be shrunk without a dump, followed by removal of ibdata1 and reinitialization of the server, and then a reload of all the data.
"Performance" is not necessarily a valid reason to change the setting on a working server.
It is possible. All advantages and possible disadvantages are mentioned in official docs
Also you should be aware that only new tables will be created in separated tablespace or you can rebuild any existing table to moved from shared tablespace.

How to restore Innodb database?

I physically moved the database and now I am not able to restore Innodb database.
I am getting this error-
140131 13:03:41 [ERROR] Cannot find or open table table_t1/t1#P#p0 from
the internal data dictionary of InnoDB though the .frm file for the
table exists. Maybe you have deleted and recreated InnoDB data
files but have forgotten to delete the corresponding .frm files
of InnoDB tables, or you have moved .frm files to another database?
or, the table contains indexes that this version of the engine
doesn't support.
See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html
how you can resolve the problem.
Help me to restore this db
Put it back and move it through the SQL interface (e.g. RENAME TABLE).

MYSQL5.5 INNODB optimazation

looking to optimize mysql5.5 databases for INNODB. I have tried the link
Note: The databases also contains MYISAM tables.
Howto: Clean a mysql InnoDB storage engine?
As per the instructions I have dropped all databases as well as ibdata* and ib_logfile* and made changes in my.cnf like
[mysqld]
innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
Now on restoring the backup, not only mysql storing INNODB tables in separate files, but it is doing it for MYISAM tables as well.
This is resulting in MYISAM database unusable.
when I am trying to access the website having MYISAM tables I am getting the error - Error displaying the error page: Application Instantiation Error
Can't makeout why mysql is storing MYISAM tables in separate files.
Thanks.
AFAIK MyISAM always stores tables in their own files (3 files per table: .MYI, .MYD and .frm).
It is not allowed to remove the ibdata file. Do you have a backup of that file? To move from single file to file per table you need to do as stated here: http://dev.mysql.com/doc/refman/5.0/en/innodb-multiple-tablespaces.html (see under "Enabling and Disabling Multiple Tablespaces")

copying raw mysql data from on server to another

I'm trying to clone raw data from all databases on a MySQL instance in Live to a test environment. The network guys have told me the data has been synched and copied across but I can't start the MySQL instance in the test environment. I'm using the innodb engine and I can see the ibdata1 file, mysql-bin files and ib_logfiles copied over along with the relevant db folders.
The error I'm getting in the error log looks like the following:
130911 13:53:08 InnoDB: Error: table <table-name>
InnoDB: in InnoDB data dictionary has tablespace id <id>,
InnoDB: but tablespace with that id or name does not exist. Have
InnoDB: you deleted or moved .ibd files?
The cloning process doesn't stop the Live MySQL instance and I'm wondering is this the problem. I don't want to use mysqldump or another backup tool. I just want to copy the raw data across. Thanks for any advice.
You can't hot-copy these files and expect them to magically work.
You can use the innobackupex tool to create a stable snapshot. This will take care of adjusting the files as necessary to be consistent and complete.