When you create a table using one of the standard storage engines
(such as MyISAM, CSV or
InnoDB, the table consists of the table
definition and the associated data. When you create a
FEDERATED table the table definition is the
same, but the physical storage of the data is handled on a remote
server.
A FEDERATED table consists of two elements:
A remote server with a database table,
which in turn consists of the table definition (stored in the
.frm file) and the associated table. The
table type of the remote table may be any type supported by
the remote mysqld server, including
MyISAM or InnoDB.
A local server with a database table,
where the table definition matches that of the corresponding
table on the remote server. The table definition is stored
within the .frm file. However, there is
no data file on the local server. Instead, the table
definition includes a connection string that points to the
remote table.
When executing queries and statements on a
FEDERATED table on the local server, the
operations that would normally insert, update or delete
information from a local data file are instead sent to the remote
server for execution, where they update the data file on the
remote server or return matching rows from the remote server.
The basic structure of a FEDERATED table set up
is shown in Figure 14.2, “FEDERATED table structure”.
The flow of information between the local server (where the SQL statement is executed) and the remote server (where the data is physically stored) is as follows:
SQL calls issued locally
MySQL handler API (data in handler format)
MySQL client API (data converted to SQL calls)
Remote database -> MySQL client API
Convert result sets (if any) to handler format
Handler API -> Result rows or rows-affected count to local

User Comments
Add your own comment.