new terms Flashcards
(748 cards)
.ARM FILE
Metadata for ARCHIVE tables. Contrast with .ARZ file. Files with this extension are always included in backups produced by the mysqlbackup command of the MySQL Enterprise Backup product.
.ARZ file
Data for ARCHIVE tables. Contrast with .ARM file. Files with this extension are always included in backups produced by the mysqlbackup command of the MySQL Enterprise Backup product.
.cfg file
A metadata file used with the InnoDB transportable tablespace feature. It is produced by the command FLUSH TABLES … FOR EXPORT, puts one or more tables in a consistent state that can be copied to another server. The .cfg file is copied along with the corresponding .ibd file, and used to adjust the internal values of the .ibd file, such as the space ID, during the ALTER TABLE … IMPORT TABLESPACE step.
.frm file
REMOVED IN MYSQL 8.0
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.
.ibd file
Each InnoDB table created using the file-per-table mode goes into its own tablespace file, with a .ibd extension, inside the database directory. This file contains the table data and any indexes for the table. File-per-table mode, controlled by the innodb_file_per_table option, affects many aspects of InnoDB storage usage and performance, and is enabled by default in MySQL 5.6.7 and higher.
This extension does not apply to the system tablespace, which consists of the ibdata files.
When a .ibd file is included in a compressed backup by the MySQL Enterprise Backup product, the compressed equivalent is a .ibz file.
If a table is create with the DATA DIRECTORY = clause in MySQL 5.6 and higher, the .ibd file is located outside the normal database directory, and is pointed to by a .isl file.
.ibz file
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. A compressed backup operation skips the compression step for a tablespace that is already in compressed row format, as compressing a second time would slow down the backup but produce little or no space savings.
.isl file
This metadata file has been removed in 8.0
A file that specifies the location of a .ibd file for an InnoDB table created with the DATA DIRECTORY = clause in MySQL 5.6 and higher. It functions like a symbolic link, without the platform restrictions of the actual symbolic link mechanism. You can store InnoDB tablespaces outside the database directory, for example, on an especially large or fast storage device depending on the usage of the table. For details, seeSection 14.5.4, “Specifying the Location of a Tablespace”.
.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.
.MYD file
A file that MySQL uses to store data for a MyISAM table.
.MYI file
A file that MySQL uses to store indexes for a MyISAM table.
.OPT file
A file containing database configuration information. Files with this extension are always included in backups produced by the mysqlbackupcommand of the MySQL Enterprise Backup product.
.PAR file
This metadata file has been removed in 8.0
A file containing partition definitions. Files with this extension are included in backups produced by the mysqlbackup command of the MySQL Enterprise Backup product.
With the introduction of native partitioning support for InnoDB tables in MySQL 5.7.6, .par files are no longer created for partitioned InnoDB tables. Partitioned MyISAM tables continue to use .par files in MySQL 5.7. In MySQL 8.0, partitioning support is only provided by the InnoDB storage engine. As such, .par files are no longer used as of MySQL 8.0.
.TRG file
This metadata file has been removed in 8.0
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.
.TRN file
This metadata file has been removed in 8.0
A file containing trigger namespace information. Files with this extension are always included in backups produced by the mysqlbackupcommand of the MySQL Enterprise Backup product.
ACID
An acronym standing for atomicity, consistency, isolation, and durability. These properties are all desirable in a database system, and are all closely tied to the notion of a transaction. The transactional features of InnoDB adhere to the ACID principles.
Transactions are atomic units of work that can be committed or rolled back. When a transaction makes multiple changes to the database, either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back.
The database remains in a consistent state at all times – after each commit or rollback, and while transactions are in progress. If related data is being updated across multiple tables, queries see either all old values or all new values, not a mix of old and new values.
Transactions are protected (isolated) from each other while they are in progress; they cannot interfere with each other or see each other’s uncommitted data. This isolation is achieved through the locking mechanism. Experienced users can adjust the isolation level, trading off less protection in favor of increased performance and concurrency, when they can be sure that the transactions really do not interfere with each other.
The results of transactions are durable: once a commit operation succeeds, the changes made by that transaction are safe from power failures, system crashes, race conditions, or other potential dangers that many non-database applications are vulnerable to. Durability typically involves writing to disk storage, with a certain amount of redundancy to protect against power failures or software crashes during write operations. (In InnoDB, the doublewrite buffer assists with durability.)
adaptive flushing
An algorithm for InnoDB tables that smooths out the I/O overhead introduced by checkpoints. Instead of flushing all modified pages from the buffer pool to the data files at once, MySQL periodically flushes small sets of modified pages. The adaptive flushing algorithm extends this process by estimating the optimal rate to perform these periodic flushes, based on the rate of flushing and how fast redo information is generated. First introduced in MySQL 5.1, in the InnoDB Plugin.
adaptive hash index
An optimization for InnoDB tables that can speed up lookups using = and IN operators, by constructing a hash index in memory. MySQL monitors index searches for InnoDB tables, and if queries could benefit from a hash index, it builds one automatically for index pages that are frequently accessed. In a sense, the adaptive hash index configures MySQL at runtime to take advantage of ample main memory, coming closer to the architecture of main-memory databases. This feature is controlled by the innodb_adaptive_hash_index configuration option. Because this feature benefits some workloads and not others, and the memory used for the hash index is reserved in the buffer pool, typically you should benchmark with this feature both enabled and disabled.
The hash index is always built based on an existing InnoDB secondary index, which is organized as a B-tree structure. MySQL can build a hash index on a prefix of any length of the key defined for the B-tree, depending on the pattern of searches against the index. A hash index can be partial; the whole B-tree index does not need to be cached in the buffer pool.
In MySQL 5.6 and higher, another way to take advantage of fast single-value lookups with InnoDB tables is to use the memcached interface to InnoDB. See Section 14.18, “InnoDB Integration with memcached” for details
AHI
Acronym for adaptive hash index.
AIO
Acronym for asynchronous I/O. You might see this acronym in InnoDB messages or keywords.
Antelope
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.
application programming interface (API)
A set of functions or procedures. An API provides a stable set of names and types for functions, procedures, parameters, and return values.
apply
When a backup produced by the MySQL Enterprise Backup product does not include the most recent changes that occurred while the backup was underway, the process of updating the backup files to include those changes is known as the apply step. It is specified by the apply-log option of the mysqlbackup command.
Before the changes are applied, we refer to the files as a raw backup. After the changes are applied, we refer to the files as a prepared backup. The changes are recorded in the ibbackup_logfile file; once the apply step is finished, this file is no longer necessary.
asynchronous I/O
A type of I/O operation that allows other processing to proceed before the I/O is completed. Also known as non-blocking I/O and abbreviated as AIO. InnoDB uses this type of I/O for certain operations that can run in parallel without affecting the reliability of the database, such as reading pages into the buffer pool that have not actually been requested, but might be needed soon.
Historically, InnoDB has used asynchronous I/O on Windows systems only. Starting with the InnoDB Plugin 1.1 and MySQL 5.5, InnoDB uses asynchronous I/O on Linux systems. This change introduces a dependency on libaio. Asynchronous I/O on Linux systems is configured using the innodb_use_native_aio option, which is enabled by default. On other Unix-like systems, InnoDB uses synchronous I/O only.
atomic ddl
An atomic DDL statement is one that combines the data dictionary updates, storage engine operations, and binary log writes associated with a DDL operation into a single, atomic transaction. The transaction is either fully committed or rolled back, even if the server halts during the operation. Atomic DDL support was added in MySQL 8.0. For more information, see Section 13.1.1, “Atomic Data Definition Statement Support”.