Mysql – What happens when InnoDB hits its tablespace autoextend max

innodbMySQL

The latest version of High Performance MySQL (3rd ed.) recommends that one:

…place an upper limit on the tablespace's size to keep it from growing
very large, because once it grows, it doesn't shrink.

They give the example of:

...ibdata3:1G:autoextend:max:2G

But it isn't clear to me what happens if your dataset keeps growing and hits this maximum. Unfortunately the MySQL docs aren't much help either.

Can someone shed some light on this? It seems like this advice is kind of dangerous on the face of it.

Thanks!

Best Answer

To answer the question what will happen, an error 1114 (ER_RECORD_FILE_FULL) will be generated when you try to insert new record. I've learned this by accident, while converting large MyISAM table to InnoDB, and there was a max setting left.

Related Solutions

Mysql – Best way to determine if a MySQL InnoDB table is in its own file, not in system tablespace

Unfortunately, Yes you have to do every database. I have a step-by-step process I wrote up back on Oct 29, 2010 in StackOverflow as well as thorough explanation why there is nothing else you can do.

You also asked

Is it even possible to mysqldump half the databases to reclaim space, or do you really have to do every database ?

You cannot reclaim half. It is an all-or-nothing decision. It is good to keep in mind what lives in ibdata1 when innodb_file_per_table is disabled :

Table Data
Table Indexes
MVCC (Multiversioning Concurrency Control) Data
- Rollback Segments
- Undo Space
Table Metadata (Data Dictionary)
Double Write Buffer (background writing to prevent reliance on OS caching)
Insert Buffer (managing changes to non-unique secondary indexes)
See the Pictorial Representation of ibdata1

Still, if you want to know which InnoDB tables are in ibdata1 and which are in their own tablespace file (.ibd), here is what you do:

STEP 01 : Run this query in the MySQL client

SELECT COUNT(1) InnoDBTableCount
FROM information_schema.tables
WHERE engine='InnoDB';

STEP 02 : Collect the number of .ibd files in the OS

ls -lR | grep -c ".ibd$"

STEP 03 : Subtract those values in the OS

Here is the shell script to compute these things

cd /var/lib/mysql
SQLSTMT="SELECT COUNT(1) FROM information_schema.tables WHERE engine='InnoDB'"
IB_TOT=`mysql -uroot -p... -ANe"${SQLSTMT}"`
IB_IBD=`ls -lR | grep -c ".ibd$"`
(( IB_SYS = IB_TOT - IB_IBD ))
echo ${IB_SYS}

If you have partitioned tables, then do this:

cd /var/lib/mysql
SQLSTMT="SELECT COUNT(1) FROM information_schema.partitions WHERE engine='InnoDB'"
IB_TOT=`mysql -uroot -p... -ANe"${SQLSTMT}"`
IB_IBD=`ls -lR | grep -c ".ibd$"`
(( IB_SYS = IB_TOT - IB_IBD ))
echo ${IB_SYS}

Here is what you get:

IB_TOT : Number of InnoDB Tables in the MySQL Instance
IB_IBD : Number of InnoDB Tables Residing Outside ibdata1 as .ibd Files
IB_SYS : Number of InnoDB Tables Residing Inside ibdata1

Mysql – InnoDB tablespace critical

I wouldn't think this is why your site is very slow. You can change the alert levels by editing the following file:

vi /etc/munin/plugin-conf.d/mysql_innodb

In this file you should see:

[mysql_innodb]
env.warning 2147483648
env.critical 1073741824

If the tablespace falls below either of these levels a warning or critical is raised. Change these limits to whatever values (in bytes) you need. If you wish to completely disable this monitoring set the values to 0:

[mysql_innodb]
env.warning 0
env.critical 0

Restart munin:

/etc/init.d/munin-node restart
su munin -c /usr/bin/munin-cron

Best Answer

Related Solutions

Mysql – Best way to determine if a MySQL InnoDB table is in its own file, not in system tablespace

Mysql – InnoDB tablespace critical

Related Question