MySQL InnoDB data file directly on a disk slice (fixed-size)?

Question

It seems that ibdata1 is like a disk slice. In Solaris (UNIX) UFS filesystems (the common one before ZFS), one would separate their disk c0t0d0 into slices, say a 10GB drive would be cut into three sections, 4GB, 1GB and 5GB. These would be fixed-size filesystems. The 4GB for, say, OS. 1GB for swap, and 5GB for software and data.

swap can be stored on a file on a filesystem, but for performance it usually stored on its own section of the disk.

Can ibdata1 be linked to its own slice for performance boost? Of course one would have to think carefully before deciding what fixed size is ideal and they would also have to know how to check usage levels.

A symbolic link can be placed from .../mysql/data/ibdata1 to /dev/rdsk/c0t0d0s3. MySQL would then see it as a file, but might perform better because it does not have to go through the file-system layer, it would write directly to a designated section of the disk.

• Has anyone tried this?
• Does anyone think this is a bad idea? (Keep in mind, this idea is for InnoDB-only database-only servers. Not multi-use servers.)
• Would it work (Does innodb need to check the file length? If not, it should work.)
• Can the usage be checked?

Answer 1

First of all, what are the entry types that reside in ibdata1 ? Four(4) entry types:

• Table MetaData
• Table Data Pages
• Index Data Pages
• MVCC Data

Whenever an InnoDB table experiences DDL, DML, or being used in a Transaction, all four of these types of entries are either read or written. Meanwhile, if innodb_file_per_table is disabled, all these entry types live in ibdata1. If it is enabled, only the Table MetaData and the MVCC Data would reside in ibdata1 while the Table Data Pages and Index Data Pages would reside in the database subfolder as a .ibd file.

That being considered, what would happen if ibdata1 were placed in another volume and symlinked ?

For starters, how does MySQL represent a table regardless of the storage engine ? As a .frm file. Where do .frm files live ? In the datadir. What's wrong with that ?

Here is an example:

Using the default datadir of /var/lib/mysql, let's use an InnoDB table called mydb.mytable.

With innodb_file_per_table disabled, everything would sit in ibdata1 (which you are proposing to symlink and send off to another data volume). For the table mydb.mytable, this is what you would have:

• /var/lib/mysql/mydb/mytable.frm
• Everything else about the table lives in ibdata1

Picture this now: You access the table, MySQL would first hit /var/lib/mysql/mydb/mytable.frm and then hit the data and index pages in ibdata1 for mydb.mytable. This would constantly be happening with every access of mydb.mytable. This cascading back-and-forth would somehow make things a little slower and you may not get the performance you were expecting by moving ibdata1 to some other data volume. In fact, the cascading effect would now be a factor of the number of InnoDB tables multiplied by two(2).

Imagine having innodb_file_per_table enabled. Now you would have a slightly different setup:

• /var/lib/mysql/mydb/mytable.frm
• /var/lib/mysql/mydb/mytable.ibd
• MVCC data and Table MetaData would reside in ibdata1

This cascading would be a little worse because the cascading for table access would now occur among three files instead of two.

Here is one more scenario some have thought of: Instead of moving the ibdata1 to a different volume, how about enabling innodb_file_per_table and moving the .ibd files to one or more different data volumes ? The cascading effect would now be a factor of the number of InnoDB tables multiplied by three(3). Percona has expressed very good reasons for not doing this that you will find helpful.