Mysql:The Federated Storage Engine:联合(联盟)存储引擎:【远程连接】服务器引擎
重点:目前该引擎仅仅支持Mysqld服务器;如果能支持其他rdbms系统就完美了!
The FEDERATED storage engine lets you access data from a remote MySQL database without using replication or cluster technology. Querying a local FEDERATED table automatically pulls the data from the remote (federated) tables. No data is stored on the local tables.
To include the FEDERATED storage engine if you build MySQL from source, invoke CMake with the -DWITH_FEDERATED_STORAGE_ENGINE option.
The FEDERATED storage engine is not enabled by default in the running server; to enable FEDERATED, you must start the MySQL server binary using the --federated option.
To examine the source for the FEDERATED engine, look in the storage/federated directory of a MySQL source distribution.
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 MySQL data dictionary) and the associated table. The table type of the remote table may be any type supported by the remote
mysqldserver, includingMyISAMorInnoDB. -
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 in the data dictionary. 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 setup is shown in Figure 16.2, “FEDERATED Table Structure”.
When a client issues an SQL statement that refers to a FEDERATED table, 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:
-
The storage engine looks through each column that the
FEDERATEDtable has and constructs an appropriate SQL statement that refers to the remote table. -
The statement is sent to the remote server using the MySQL client API.
-
The remote server processes the statement and the local server retrieves any result that the statement produces (an affected-rows count or a result set).
-
If the statement produces a result set, each column is converted to internal storage engine format that the
FEDERATEDengine expects and can use to display the result to the client that issued the original statement.
The local server communicates with the remote server using MySQL client C API
functions. It invokes mysql_real_query() to send the statement. To read a
result set, it uses mysql_store_result() and fetches rows one at a time
using mysql_fetch_row().
To create a FEDERATED table you should follow
these steps:
-
Create the table on the remote server. Alternatively, make a note of the table definition of an existing table, perhaps using the
SHOW CREATE TABLEstatement. -
Create the table on the local server with an identical table definition, but adding the connection information that links the local table to the remote table.
For example, you could create the following table on the remote server:
CREATE TABLE test_table (
id INT(20) NOT NULL AUTO_INCREMENT,
name VARCHAR(32) NOT NULL DEFAULT '',
other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id),
INDEX name (name),
INDEX other_key (other)
)
ENGINE=MyISAM
DEFAULT CHARSET=utf8mb4;
To create the local table that will be federated to the remote table, there are two options available. You can either create the local table and specify the connection string (containing the server name, login, password) to be used to connect to the remote table using the CONNECTION, or you can use an existing connection that you have previously created using the CREATE SERVER statement.
When you create the local table it must have an identical field definition to the remote table.
You can improve the performance of a FEDERATED table by adding indexes to the table on the host. The optimization will occur because the query sent to the remote server will include the contents of the WHERE clause and will be sent to the remote server and subsequently executed locally. This reduces the network traffic that would otherwise request the entire table from the server for local processing.
To use the first method, you must specify the CONNECTION string after the engine type in a CREATE TABLE statement. For example:
CREATE TABLE federated_table (
id INT(20) NOT NULL AUTO_INCREMENT,
name VARCHAR(32) NOT NULL DEFAULT '',
other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id),
INDEX name (name),
INDEX other_key (other)
)
ENGINE=FEDERATED
DEFAULT CHARSET=utf8mb4
CONNECTION='mysql://fed_user@remote_host:9306/federated/test_table';
CONNECTION replaces the COMMENT used in some previous versions of MySQL.
The CONNECTION string contains the information required to connect to the remote server containing the table that will be used to physically store the data. The connection string specifies the server name, login credentials, port number and database/table information. In the example, the remote table is on the server remote_host, using port 9306. The name and port number should match the host name (or IP address) and port number of the remote MySQL server instance you want to use as your remote table.
The format of the connection string is as follows:
scheme://user_name[:password]@host_name[:port_num]/db_name/tbl_name
Where:
-
scheme: A recognized connection protocol. Onlymysqlis supported as theschemevalue at this point. -
user_name: The user name for the connection. This user must have been created on the remote server, and must have suitable privileges to perform the required actions (SELECT,INSERT,UPDATE, and so forth) on the remote table. -
password: (Optional) The corresponding password foruser_name. -
host_name: The host name or IP address of the remote server. -
port_num: (Optional) The port number for the remote server. The default is 3306. -
db_name: The name of the database holding the remote table. -
tbl_name: The name of the remote table. The name of the local and the remote table do not have to match.
Sample connection strings:
CONNECTION='mysql://username:password@hostname:port/database/tablename' CONNECTION='mysql://username@hostname/database/tablename' CONNECTION='mysql://username:password@hostname/database/tablename'
If you are creating a number of FEDERATED tables on the same server, or if you want to simplify the process of creating FEDERATED tables, you can use the CREATE SERVER statement to define the server connection parameters, just as you would with the CONNECTION string.
The format of the CREATE SERVER statement is:
CREATE SERVERserver_nameFOREIGN DATA WRAPPERwrapper_nameOPTIONS (option[,option] ...)
The server_name is used in the connection string when creating a new FEDERATED table.
For example, to create a server connection identical to the CONNECTION string:
CONNECTION='mysql://fed_user@remote_host:9306/federated/test_table';
You would use the following statement:
CREATE SERVER fedlink FOREIGN DATA WRAPPER mysql OPTIONS (USER 'fed_user', HOST 'remote_host', PORT 9306, DATABASE 'federated');
To create a FEDERATED table that uses this connection, you still use the CONNECTION keyword, but specify the name you used in the CREATE SERVER statement.
CREATE TABLE test_table (
id INT(20) NOT NULL AUTO_INCREMENT,
name VARCHAR(32) NOT NULL DEFAULT '',
other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id),
INDEX name (name),
INDEX other_key (other)
)
ENGINE=FEDERATED
DEFAULT CHARSET=utf8mb4
CONNECTION='fedlink/test_table';
The connection name in this example contains the name of the connection (fedlink) and the name of the table (test_table) to link to, separated by a slash. If you specify only the connection name without a table name, the table name of the local table is used instead.
For more information on CREATE SERVER, see Section 13.1.18, “CREATE SERVER Statement”.
The CREATE SERVER statement accepts the same arguments as the CONNECTION string. The CREATE SERVER statement updates the rows in the mysql.servers table. See the following table for information on the correspondence between parameters in a connection string, options in the CREATE SERVER statement, and the columns in the mysql.servers table. For reference, the format of the CONNECTION string is as follows:
scheme://user_name[:password]@host_name[:port_num]/db_name/tbl_name
| Description | CONNECTION string | CREATE SERVER option | mysql.servers column |
|---|---|---|---|
| Connection scheme | scheme |
wrapper_name |
Wrapper |
| Remote user | user_name |
USER |
Username |
| Remote password | password |
PASSWORD |
Password |
| Remote host | host_name |
HOST |
Host |
| Remote port | port_num |
PORT |
Port |
| Remote database | db_name |
DATABASE |
Db |
You should be aware of the following points when using the FEDERATED storage engine:
-
FEDERATEDtables may be replicated to other slaves, but you must ensure that the slave servers are able to use the user/password combination that is defined in theCONNECTIONstring (or the row in themysql.serverstable) to connect to the remote server.
The following items indicate features that the FEDERATED storage engine does and does not support:
-
The remote server must be a MySQL server.
-
The remote table that a
FEDERATEDtable points to must exist before you try to access the table through theFEDERATEDtable. -
It is possible for one
FEDERATEDtable to point to another, but you must be careful not to create a loop. -
A
FEDERATEDtable does not support indexes in the usual sense; because access to the table data is handled remotely, it is actually the remote table that makes use of indexes. This means that, for a query that cannot use any indexes and so requires a full table scan, the server fetches all rows from the remote table and filters them locally. This occurs regardless of anyWHEREorLIMITused with thisSELECTstatement; these clauses are applied locally to the returned rows.Queries that fail to use indexes can thus cause poor performance and network overload. In addition, since returned rows must be stored in memory, such a query can also lead to the local server swapping, or even hanging.
-
Care should be taken when creating a
FEDERATEDtable since the index definition from an equivalentMyISAMor other table may not be supported. For example, creating aFEDERATEDtable with an index prefix onVARCHAR,TEXTorBLOBcolumns will fail. The following definition inMyISAMis valid:CREATE TABLE `T1`(`A` VARCHAR(100),UNIQUE KEY(`A`(30))) ENGINE=MYISAM;
The key prefix in this example is incompatible with the
FEDERATEDengine, and the equivalent statement will fail:CREATE TABLE `T1`(`A` VARCHAR(100),UNIQUE KEY(`A`(30))) ENGINE=FEDERATED CONNECTION='MYSQL://127.0.0.1:3306/TEST/T1';
If possible, you should try to separate the column and index definition when creating tables on both the remote server and the local server to avoid these index issues.
-
Internally, the implementation uses
SELECT,INSERT,UPDATE, andDELETE, but notHANDLER. -
The
FEDERATEDstorage engine supportsSELECT,INSERT,UPDATE,DELETE,TRUNCATE TABLE, and indexes. It does not supportALTER TABLE, or any Data Definition Language statements that directly affect the structure of the table, other thanDROP TABLE. The current implementation does not use prepared statements. -
FEDERATEDacceptsINSERT ... ON DUPLICATE KEY UPDATEstatements, but if a duplicate-key violation occurs, the statement fails with an error. -
Transactions are not supported.
-
FEDERATEDperforms bulk-insert handling such that multiple rows are sent to the remote table in a batch, which improves performance. Also, if the remote table is transactional, it enables the remote storage engine to perform statement rollback properly should an error occur. This capability has the following limitations:-
The size of the insert cannot exceed the maximum packet size between servers. If the insert exceeds this size, it is broken into multiple packets and the rollback problem can occur.
-
Bulk-insert handling does not occur for
INSERT ... ON DUPLICATE KEY UPDATE.
-
-
There is no way for the
FEDERATEDengine to know if the remote table has changed. The reason for this is that this table must work like a data file that would never be written to by anything other than the database system. The integrity of the data in the local table could be breached if there was any change to the remote database. -
When using a
CONNECTIONstring, you cannot use an '@' character in the password. You can get round this limitation by using theCREATE SERVERstatement to create a server connection. -
The
insert_idandtimestampoptions are not propagated to the data provider. -
Any
DROP TABLEstatement issued against aFEDERATEDtable drops only the local table, not the remote table. -
FEDERATEDtables do not work with the query cache. -
User-defined partitioning is not supported for
FEDERATEDtables.
The following additional resources are available for the FEDERATED storage engine:
-
A forum dedicated to the
FEDERATEDstorage engine is available at https://forums.mysql.com/list.php?105.

浙公网安备 33010602011771号