The code name for the original InnoDB file
format. It supports the
redundant and
compact row formats, but not
the newer dynamic and
compressed row formats
available in the Barracuda file
format.

If your application could benefit from InnoDB table
compression, or uses BLOBs or
large text columns that could benefit from the dynamic row
format, you might switch some tables to Barracuda format. You
select the file format to use by setting the
innodb_file_format option before creating the
table.

B

.bz file

When mysqlbackup performs a compressed backup
for a server that has binary logging enabled, it transforms each
binary log file and relay log file (for a
slave server in a
replication setting) to a
binary-or-relay-log-file-name.bz
file. The .bz files are uncompressed at the
time of restore.

The process of copying some or all table data and metadata from
a MySQL instance, for safekeeping. Can also refer to the set of
copied files. This is a crucial task for DBAs. The reverse of
this process is the restore
operation.

With MySQL, physical backups
are performed by the MySQL Enterprise
Backup product, and logical
backups are performed by the
mysqldump command. These techniques have
different characteristics in terms of size and representation of
the backup data, and speed (especially speed of the restore
operation).

Backups are further classified as
hot,
warm, or
cold depending on how much they
interfere with normal database operation. (Hot backups have the
least interference, cold backups the most.)

The directory under which the backup data and metadata are
stored, permanently or temporarily. It is used in most kinds of
backup and restore operations, including single-file backups and
restores. See the description of the
--backup-dir option on how the
backup directory is used for different purposes and for
different operations.

A small configuration file
generated by MySQL Enterprise
Backup, containing a minimal set of configuration
parameters. This file records the settings that apply to this
backup data. Subsequent operations, such as the
apply process, read options
from this file to determine how the backup data is structured.
This file always has the extension .cnf,
rather than .cnf on Unix-like systems and
.ini on Windows systems.

The code name for an InnoDB file
format that supports compression for table data. This
file format was first introduced in the InnoDB Plugin. It
supports the compressed row
format that enables InnoDB table compression, and the
dynamic row format that
improves the storage layout for BLOB and large text columns. You
can select it through the innodb_file_format
option.

Because the InnoDB system
tablespace is stored in the original
Antelope file format, to use
the Barracuda file format you must also enable the
file-per-table setting, which
puts newly created tables in their own tablespaces separate from
the system tablespace.

The MySQL Enterprise Backup
product version 3.5 and above supports backing up tablespaces
that use the Barracuda file format.

A file containing a record of all statements that attempt to
change table data. These statements can be replayed to bring
slave servers up to date in a
replication scenario, or to
bring a database up to date after restoring table data from a
backup. The binary logging feature can be turned on and off,
although Oracle recommends always enabling it if you use
replication or perform backups.

You can examine the contents of the binary log, or replay those
statements during replication or recovery, by using the
mysqlbinlog command. For full information
about the binary log, see The Binary Log. For
MySQL configuration options related to the binary log, see
Binary Logging Options and Variables.

For the MySQL Enterprise Backup
product, the file name of the binary log and the current
position within the file are important details. To record this
information for the master server when taking a backup in a
replication context, you can specify the
--slave-info option.

Prior to MySQL 5.0, a similar capability was available, known as
the update log. In MySQL 5.0 and higher, the binary log replaces
the update log.

A setting that determines how much
compression to apply to a
compressed backup. This setting ranges from 0 (none), 1 (default
level when compression is enabled) to 9 (maximum). The amount of
compression for a given compression level depends on the nature
of your data values. Higher compression levels do impose
additional CPU overhead, so ideally you use the lowest value
that produces a good balance of compression with low CPU
overhead.

The file that holds the startup options of the MySQL server and
related products and components. Often referred to by its
default file name, my.cnf on
Linux, Unix, and OS X systems, and
my.ini on Windows systems. The
MySQL Enterprise Backup stores
its default configuration settings in this file, under a
[mysqlbackup] section. For convenience, MySQL
Enterprise Backup can also read settings from the
[client] section, for configuration options
that are common between MySQL Enterprise Backup and other
programs that connect to the MySQL server.

The mechanism used by certain backup operations to communicate
with a running MySQL server.
For example, the mysqlbackup command can log
into the server being backed up to insert and update data in the
progress table and the
history table. A
hot backup typically uses a
database connection for convenience, but can proceed anyway if
the connection is not available. A warm
backup always uses a database connection, because it
must put the server into a read-only state. A
cold backup is taken while the
MySQL server is shut down, and so cannot use any features that
require a connection.

The cleanup activities for InnoDB tables that occur when MySQL
is started again after a crash. Changes that were committed
before the crash, but not yet written to the tablespace files,
are reconstructed from the doublewrite
buffer. When the database is shut down normally, this
type of activity is performed during shutdown by the
purge operation.

D

data dictionary

A set of tables, controlled by the InnoDB storage engine, that
keeps track of InnoDB-related objects such as tables, indexes,
and table columns. These tables are part of the InnoDB
system tablespace.

Because the MySQL Enterprise
Backup product always backs up the system tablespace,
all backups include the contents of the data dictionary.

A set of tables and related objects owned by a MySQL user.
Equivalent to “schema” in Oracle Database
terminology. MySQL Enterprise
Backup can perform a partial
backup that includes some databases and not others.
The full set of databases controlled by a MySQL server is known
as an instance.

A period when the database is unresponsive. The database might
be entirely shut down, or in a read-only state when applications
are attempting to insert, update, or delete data. The goal for
your backup strategy is to minimize downtime, using techniques
such as hot backup for
InnoDB tables,
cold backup using
slave servers in a
replication configuration, and
minimizing the duration of the
suspend stage where you run
customized backup logic while the MySQL server is
locked.

E

The operation that retrieves some content from an
image file produced by a
single-file backup. It can
apply to a single file (unpacked to an arbitrary location) or to
the entire backup (reproducing the original directory structure
of the backup data). These two kinds of extraction are performed
by the mysqlbackup options
extract and
image-to-backup-dir, respectively.

F

A file containing the metadata, such as the table definition, of
a MySQL table.

For backups, you must always keep the full set of
.frm files along with the backup data to be
able to restore tables that are altered or dropped after the
backup.

Although each InnoDB table has a .frm file,
InnoDB maintains its own table metadata in the system
tablespace; the .frm files are not needed
for InnoDB to operate on InnoDB tables.

These files are backed up by the MySQL
Enterprise Backup product. These files must not be
modified by an ALTER TABLE operation while
the backup is taking place, which is why backups that include
non-InnoDB tables perform a FLUSH TABLES WITH READ
LOCK operation to freeze such activity while backing
up the .frm files. Restoring a backup can
result in .frm files being created,
changed, or removed to match the state of the database at the
time of the backup.

file format

The format used by InnoDB for its data files named
ibdata1, ibdata2, and so
on. Each file format supports one or more row formats.

A backup that includes all the
tables in each MySQL database,
and all the databases in a MySQL instance. Contrast with
partial backup and
incremental backup. Full
backups take the longest, but also require the least amount of
followup work and administration complexity. Thus, even when you
primarily do partial or incremental backups, you might
periodically do a full backup.

A backup taken while the MySQL
instance and is running and
applications are reading and writing to it. Contrast with
warm backup and
cold backup.

A hot backup involves more than simply copying data files: it
must include any data that was inserted or updated while the
backup was in process; it must exclude any data that was deleted
while the backup was in process; and it must ignore any changes
started by transactions but not
committed.

The Oracle product that performs hot backups, of
InnoDB tables especially but
also tables from MyISAM and other storage engines, is
MySQL Enterprise Backup.

The hot backup process consists of two stages. The initial
copying of the InnoDB data files produces a
raw backup. The
apply step incorporates any
changes to the database that happened while the backup was
running. Applying the changes produces a
prepared backup; these files
are ready to be restored whenever necessary.

A full backup consists of a hot
backup phase that copies the InnoDB data, followed by a
warm backup phase that copies
any non-InnoDB data such as MyISAM tables and
.frm files.

I

.ibd file

Each InnoDB tablespace created
using the file-per-table
setting has a filename with a .ibd extension.
This extension does not apply to the
system tablespace, which is
made up of files named ibdata1,
ibdata2, and so on.

When the MySQL Enterprise
Backup product performs a
compressed backup, it
transforms each tablespace file
that is created using the
file-per-table setting from a
.ibd
extension to a
.ibz
extension.

The compression applied during backup is distinct from the
compressed row format that
keeps table data compressed during normal operation. An InnoDB
tablespace that is already in compressed row format is not
compressed a second time, but is, nevertheless, still saved as
an .ibz file in the compressed backup.

A set of files with names such as ibdata1,
ibdata2, and so on, that make up the InnoDB
system tablespace. These files
contain metadata about InnoDB tables, and can contain some or
all of the table and index data also (depending on whether the
file-per-table option is in
effect when each table is created). For backward compatibility
these files always use the
Antelope file format.

The file produced as part of a single-file
backup operation. It can be a real file that you
store locally, or standard output (specified as
-) when the backup data is
streamed directly to another
command or remote server. This term is referenced in several
mysqlbackup options such as
backup-dir-to-image and
image-to-backup-dir.

The type of MySQL table that
works best with MySQL Enterprise
Backup. These tables can be backed up using the
hot backup technique that
avoids interruptions in database processing. For this reason,
and because of the higher reliability and concurrency possible
with InnoDB tables, most deployments should use InnoDB for the
bulk of their data and their most important data. In MySQL 5.5
and higher, the CREATE TABLE
statement creates InnoDB tables by default.

A backup that reproduces table
structure and data, without copying the actual data files. For
example, the mysqldump command produces a
logical backup, because its output contains statements such as
CREATE TABLE and INSERT
that can re-create the data. Contrast with
physical backup.

Acronym for log sequence
number. This arbitrary, ever-increasing value
represents a point in time corresponding to operations recorded
in the redo log. (This point in
time is regardless of transaction boundaries; it can fall in the
middle of one or more transactions.) It is used internally by
InnoDB during crash recovery
and for managing the buffer pool.

In the MySQL Enterprise Backup
product, you can specify an LSN to represent the point in time
from which to take an incremental
backup. The relevant LSN is displayed by the output
of the mysqlbackup command. Once you have the
LSN corresponding to the time of a full backup, you can specify
that value to take a subsequent incremental backup, whose output
contains another LSN for the next incremental backup.

M

.MRG file

A file containing references to other tables, used by the
MERGE storage engine. Files with this
extension are always included in backups produced by the
mysqlbackup command of the
MySQL Enterprise Backup
product.

The record of the environment (for example, command-line
arguments) and data files involved in a backup, stored in the
files meta/backup_create.xml and
meta/backup_content.xml, respectively. This
data can be used by management tools during diagnosis and
troubleshooting procedures.

master

In a replication configuration,
a database server that sends updates to a set of
slave servers. It typically
dedicates most of its resources to write operations, leaving
user queries to the slaves. With MySQL
Enterprise Backup, typically you perform backups on
the slave servers rather than the master, to minimize any
slowdown of the overall system.

A MySQL storage engine, formerly the default for new tables. In
MySQL 5.5 and higher, InnoDB
becomes the default storage engine. MySQL Enterprise Backup can
back up both types of tables, and tables from other storage
engines also. The backup process for InnoDB tables
(hot backup) is less disruptive
to database operations than for MyISAM tables
(warm backup).

A licensed products that performs hot
backups of MySQL databases. It offers the most
efficiency and flexibility when backing up
InnoDB tables; it can also back
up MyISAM and other kinds of tables. It is included as part of
the MySQL Enterprise Edition subscription.

A MySQL command that performs logical
backups, producing a set of SQL commands to recreate
tables and data. Suitable for smaller backups or less critical
data, because the restore
operation takes longer than with a
physical backup produced by
MySQL Enterprise Backup.

N

O

.opt file

A file containing database configuration information. Files with
this extension are always included in backups produced by the
backup operations of the MySQL Enterprise
Backup product.

offline

A type of operation performed while the database server is
stopped. With the MySQL Enterprise
Backup product, the main offline operation is the
restore step. You can
optionally perform a cold
backup, which is another offline operation. Contrast
with online.

A type of operation performed while the database server is
running. A hot backup is the
ideal example, because the database continues to run and no read
or write operations are blocked. For that reason, sometimes
“hot backup” and “online backup” are
used as synonyms. A cold backup
is the opposite of an online operation; by definition, the
database server is shut down while the backup happens. A
warm backup is also a kind of
online operation, because the database server continues to run,
although some write operations could be blocked while a warm
backup is in progress. Contrast with
offline.

Optimistic backup is a feature introduced in MySQL Enterprise
Backup 3.11 for improving performance for backing up and
restoring huge databases in which only a small number of tables
are modified frequently. An optimistic backup consists of two
phases: (1) the optimistic phase in which tables that are
unlikely to be modified during the backup process (identified by
the user with the optimistic-time
option or, by exclusion, with the
optimistic-busy-tables option) are
backed up without locking the MySQL instance; (2) a normal
phase, in which tables that are not backed up in the first phase
are being backed up in a manner similar to how they are
processed in an ordinary backup: the InnoDB files are copied
first, and then other relevant files and copied or processed
with the MySQL instance locked. The redo logs, undo logs, and
the system tablespace are also backed up in this phase. See
Section 4.3.6, “Making an Optimistic Backup” for details.

Oracle Secure Backup

An Oracle product for managing
backup media, and so classified
as media management software
(MMS). Abbreviated
OSB. For
MySQL Enterprise Backup, OSB is
typically used to manage tape backups.

A restore operation that
applies to one or more tables
or databases, but not the
entire contents of a MySQL server. The data being restored could
come from either a partial
backup or a full
backup. Related mysqlbackup
options are --include-tables,
--exclude-tables, and
--rename

A backup that copies the actual
data files. For example, the MySQL
Enterprise Backup command produces a physical backup,
because its output contains data files that can be used directly
by the mysqld server. Contrast with
logical backup.

The time corresponding to the end of a
backup operation. A
prepared backup includes all
the changes that occurred while the backup operation was
running. Restoring the backup
brings the data back to the state at the moment when the backup
operation completed.

R

raw backup

The initial set of backup data, not yet ready to be restored
because it does not incorporate changes that occurred while the
backup was running. The apply
operation transforms the backup files into a
prepared backup that is ready
to be restored.

A set of files, typically named ib_logfile0
and ib_logfile1, that record statements that
attempt to change data in InnoDB tables. These statements are
replayed automatically to correct data written by incomplete
transactions, on startup following a crash. The passage of data
through the redo logs is represented by the ever-increasing
LSN value. The 4GB limit on
maximum size for the redo log is raised in MySQL 5.6.

Some MySQL Enterprise Backup features use POSIX-style regular
expressions, for example to specify tables, databases, or both
to include or
exclude from a
partial backup. Regular
expressions require escaping for dots in filenames, because the
dot is the single-character wildcard; no escaping is needed for
forward slashes in path names. When specifying regular
expressions on the command line, surround them with quotation
marks as appropriate for the shell environment, to prevent
expansion of characters such as asterisks by the shell wildcard
mechanism.

A record on a slave server for
the events read from the binary
log of the master and written by the slave I/O
thread. The relay log, like the binary
log, consists of a set of numbered files containing
events that describe database changes, and an index file that
contains the names of all used relay log files. For more
information on relay log, see
The Slave Relay Log. The relay log on a server
is backed up by default.

A common configuration for MySQL deployments, with data and DML
operations from a master server
synchronized with a set of
slave servers. With MySQL
Enterprise Backup, you might
take a backup on one server, and restore on a different system
to create a new slave server with the data already in place. You
might also back up data from a slave server rather than the
master, to minimize any slowdown of the overall system.

The disk storage format for a row from an InnoDB table. As
InnoDB gains new capabilities such as compression, new row
formats are introduced to support the resulting improvements in
storage efficiency and performance.

Each table has its own row format, specified through the
ROW_FORMAT option. To see the row format for
each InnoDB table, issue the command SHOW TABLE
STATUS. Because all the tables in the system
tablespace share the same row format, to take advantage of other
row formats typically requires setting the
innodb_file_per_table option, so that each
table is stored in a separate tablespace.

A MySQL instance controlled by
a mysqld daemon. A physical machine can host
multiple MySQL servers, each requiring its own
backup operations and schedule.
Some backup operations communicate with the server through a
connection.

In a replication configuration,
a database server that receives updates from a
master server. Typically used
to service user queries, to minimize the query load on the
master. With MySQL Enterprise
Backup, you might take a backup on one server, and
restore on a different system to create a new slave server with
the data already in place. You might also back up data from a
slave server rather than the master, to minimize any slowdown of
the overall system.

A backup technique that transfers the data immediately to
another server, rather than saving a local copy. Uses mechanisms
such as Unix pipes. Requires a single-file
backup, with the destination file specified as
- (standard output).

An optional stage within the backup where the MySQL Enterprise
Backup processing stops, to allow for user-specific operations
to be run. The mysqlbackup command has
options that let you specify commands to be run while the backup
is suspended. Most often used in conjunction with backups of
InnoDB tables only, where you
might do your own scripting for handling
.frm files.

By default, this single data file stores all the table data for
a database, as well as all the metadata for InnoDB-related
objects (the data dictionary).

Turning on the
innodb_file_per_table option
causes each newly created table to be stored in its own
tablespace, reducing the size
of, and dependencies on, the system tablespace.

Keeping all table data in the system tablespace has implications
for the MySQL Enterprise Backup
product (backing up one large file rather than several smaller
files), and prevents you from using certain InnoDB features that
require the newer Barracuda
file format. on the

T

.TRG file

A file containing trigger
parameters. Files with this extension are always included in
backups produced by the mysqlbackup command
of the MySQL Enterprise Backup
product.

table

Although a table is a distinct, addressable object in the
context of SQL, for backup
purposes we are often concerned with whether the table is part
of the system tablespace, or
was created under the
file-per-table setting and so
resides in its own tablespace.

For InnoDB tables, the file
that holds the data and indexes for a table. Can be either the
system tablespace containing
multiple tables, or a table created with the
file-per-table setting that
resides in its own tablespace file.

W

warm backup

A backup taken while the
database is running, but that restricts some database operations
during the backup process. For example, tables might become
read-only. For busy applications and web sites, you might prefer
a hot backup.