InnoDB 1.1 incorporates several checks to guard against the possible crashes and data corruptions that might occur if you run an older release of the MySQL server on InnoDB data files using a newer file format. These checks take place when the server is started, and when you first access a table. This section describes these checks, how you can control them, and error and warning conditions that might arise.
Considerations of backward compatibility only apply when using a recent version of InnoDB (the InnoDB Plugin, or MySQL 5.5 and higher with InnoDB 1.1) alongside an older one (MySQL 5.1 or earlier, with the built-in InnoDB rather than the InnoDB Plugin). To minimize the chance of compatibility issues, you can standardize on the InnoDB Plugin for all your MySQL 5.1 and earlier database servers.
In general, a newer version of InnoDB may create a table or index that cannot safely be read or written with a prior version of InnoDB without risk of crashes, hangs, wrong results or corruptions. InnoDB 1.1 includes a mechanism to guard against these conditions, and to help preserve compatibility among database files and versions of InnoDB. This mechanism lets you take advantage of some new features of an InnoDB release (such as performance improvements and bug fixes), and still preserve the option of using your database with a prior version of InnoDB, by preventing accidental use of new features that create downward-incompatible disk files.
If a version of InnoDB supports a particular file format (whether or not that format is the default), you can query and update any table that requires that format or an earlier format. Only the creation of new tables using new features is limited based on the particular file format enabled. Conversely, if a tablespace contains a table or index that uses a file format that is not supported by the currently running software, it cannot be accessed at all, even for read access.
The only way to “downgrade” an InnoDB tablespace to
an earlier file format is to copy the data to a new table, in a
tablespace that uses the earlier format. This can be done with the
ALTER TABLE statement, as described
in Section 4.4, “Downgrading the File Format”.
The easiest way to determine the file format of an existing InnoDB
tablespace is to examine the properties of the table it contains,
SHOW TABLE STATUS command or querying
INFORMATION_SCHEMA.TABLES. If the
Row_format of the table is reported as
the tablespace containing the table uses the Barracuda format.
Otherwise, it uses the prior InnoDB file format, Antelope.
Every InnoDB per-table tablespace (represented by a
*.ibd file) file is labeled with a file format
identifier. The system tablespace (represented by the
ibdata files) is tagged with the
“highest” file format in use in a group of InnoDB
database files, and this tag is checked when the files are opened.
Creating a compressed table, or a table with
ROW_FORMAT=DYNAMIC, updates the file header for
.ibd file and the table type
in the InnoDB data dictionary with the identifier for the
Barracuda file format. From that point forward, the table cannot
be used with a version of InnoDB that does not support this new
file format. To protect against anomalous behavior, InnoDB version
5.0.21 and later performs a compatibility check when the table is
opened. (In many cases, the
TABLE statement recreates a table and thus changes its
properties. The special case of adding or dropping indexes without
rebuilding the table is described in
Chapter 2, Fast Index Creation in the InnoDB Storage Engine.)
To avoid confusion, for the purposes of this discussion we define the term “ib-file set” to mean the set of operating system files that InnoDB manages as a unit. The ib-file set includes the following files:
The system tablespace (one or more
ibdatafiles) that contain internal system information (including internal catalogs and undo information) and may include user data and indexes.
Zero or more single-table tablespaces (also called “file per table” files, named
InnoDB log files; usually two,
ib_logfile1. Used for crash recovery and in backups.
An “ib-file set” does not include the corresponding
.frm files that contain metadata about InnoDB
.frm files are created and managed
by MySQL, and can sometimes get out of sync with the internal
metadata in InnoDB.
Multiple tables, even from more than one database, can be stored in a single “ib-file set”. (In MySQL, a “database” is a logical collection of tables, what other systems refer to as a “schema” or “catalog”.)