Le moteur de table FEDERATED

Le moteur de table FEDERATED a été ajouté en MySQL 5.0.3. C'est un moteur de table qui accède à des tables dans une base de données distante, plutôt que dans des fichiers locaux. Pour examiner le code source pour le moteur FEDERATED, reportez-vous dans le dossier sql de la distribution source de MySQL 5.0.3 ou plus récent.

Installation du moteur de table FEDERATED
Pour activer ce moteur de table, utilisez l'option --with-federated-storage-engine avec la commande configure lorsque vous compilez MySQL.

Description du moteur de stockage FEDERATED
Lorsque vous créez une table FEDERATED, le serveur crée un fichier de définition de fichier dans le dossier de données. Le fichier porte le nom de la table et l'extension .frm. Aucun autre fichier n'est créé, car les données résident en fait sur un autre serveur. C'est la différence principale avec un moteur de table local. Pour les tables locales, les fichiers de données sont locaux. Par exemple, si vous créez une table MyISAM du nom de users, le gestionnaire MyISAM crée un fichier de données appelée users.MYD. Un gestionnaire local lit, écrit et efface les données sur un fichier local, et les données sont enregistrées dans un format particulier au gestionnaire. Pour lire les lignes, le gestionnaire doit analyser les colonnes des tables. Pour écrire les lignes, les valeurs des colonnes doivent être converties en un format linéaire. Avec le moteur de table MySQL FEDERATED, il n'y a pas de données locales pour la table :
par exemple, il n'y a pas de fichier .MYD. Au lieu de cela, un serveur de base de données distant se charge de stocker les données de la table. Cela impose l'utilisation du protocole client MySQL pour lire, écrire et effacer les données. La lecture des données est initiée via la commande SQL SELECT * FROM tbl_name. Pour lire le résultat, les lignes sont lues avec la fonction C mysql_fetch_row(), puis converties en colonnes tel que la commande SELECT l'attent, au format demandé par le gestionnaire FEDERATED.
Le processus de base est le suivant :

   1. Les commandes SQL sont re¸ues localement.
   2.Les commandes sont passées au gestionnaire MySQL (au format du gestionnaire)
   3.Les commandes sont passées à l'API client MySQL (les données sont converties en appel SQL)
   4.Les commandes seont recues par la base de données distante, via l'API client.
   5.Les résultats, s'il y en a, sont convertis au format du gestionnaire.
   6.Les résultats sont re¸us localement. 
  

Comment utiliser les tables FEDERATED

La procédure pour utiliser les tables FEDERATED est très simple. Normalement, vous devez avoir 2 serveurs en focntionnement, sur le même hôte ou sur deux hôtes distincts. Il est aussi possible pour une table FEDERATED d'utiliser une autre table gérée par un autre serveur, mais il y a quelques limitations qui s'ajoutent. D'abord vous devez avoir une table sur un serveur distant, à laquelle vous voulez accéder via la table FEDERATED. Supposez que la table distante dans la base federated est définie comme ceci :

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),
    KEY name (name),
    KEY other_key (other)
)
ENGINE=MyISAM
DEFAULT CHARSET=latin1 ;

La table ENGINE peut utiliser n'importe quel moteur de stockage; la table n'est pas obligatoirement une table MyISAM. Ensuite, créez une table FEDERATED pour accéder à la table distante. Le serveur où vous créez la table FEDERATED est le ``client-serveur''. Sur ce serveur, créez une table comme ceci :

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),
    KEY name (name),
    KEY other_key (other)
)
ENGINE=FEDERATED
DEFAULT CHARSET=latin1
COMMENT='mysql://root@remote_host:9306/federated/test_table';

La structure de cette table doit être exactement la même que la table distante, hormis le moteur ENGINE qui doit valoir FEDERATED et l'option de table COMMENT qui contient la chaîne de connexion pour spécifier au moteur FEDERATED comment se connecter au serveur distant. Le moteur FEDERATED ne crée que le fichier test_table.frm dans la base de données federated. Les informations d'hôte distant représente le serveur sur lequel votre serveur se connecte en tant que ``client'', et les informations de tables et de bases qui représentent les ``données''. Dans l'exemple, le serveur distant va fonctionne en tant que remote_host sur le port 9306 : il est recommandé de lancer ce serveur pour qu'il soit en attente sur le port 9306. La forme générale de la chaîne de connexion de l'optin COMMENT est la suivante :

scheme://user_name[:password]@host_name[:port_num]:/db_name/tbl_name
Seul le protocole mysql est supporté comme valeur pour scheme actuellement, et le numéro de port ainsi que le mot de passe sont optionnels. Voici quelques exemples de chaînes de connexion :

COMMENT='mysql://username:password@hostname:port/database/tablename'
COMMENT='mysql://username@hostname/database/tablename'
COMMENT='mysql://username:password@hostname/database/tablename'

L'utilisation de COMMENT pour spécifier la chaîne de connexion n'est pas optimale, et nous allons probablement changer cela en MySQL 5.1. Gardez cela en tête que lorsque vous utilisez les tables FEDERATED, car cela vous obligera à faire des modifications dans un avenir proche. De même, comme le mot de passe est stocké en texte clair dans la chaîne, il peut être vu par un autre utilisateur avec un accès à SHOW CREATE TABLE ou SHOW TABLE STATUS pour la table FEDERATED.

Limitations du moteur de stockage FEDERATED

Ce que le moteur de stockage FEDERATED fait et ne fait pas :
Dans la première version, le serveur distant doit être un serveur MySQL. Le support d'autres serveurs par le moteur FEDERATED est à l'étude actuellement.
La table distante sur laquelle pointe la table FEDERATED doit exister avant que vous essayez d'y accéder via la table FEDERATED.
Il est possible opur une table FEDERATED de pointer sur une autre table, mais vous devez être prudents et ne pas créer de boucle. Vous avez déjà entendu parlé de l'effet Larsen? Vous avez déjà vu ce que ca fait d'avoir deux miroirs face à face? Cela devrait illustrer la situation à éviter.
Il n'y a pas de support pour les transactions.
Il n'y a pas de moyen pour que le moteur FEDERATED sache que la table distante à changé. La raison à cela est que la table doit fonctionner comme un fichier de données qui n'est jamais écrit par autre chose que la base de odnnées. L'intégrité des données dans la table locale pourrait être cassée s'il y a des modifications dans la table distante.
Le moteur de stockage FEDERATED supporte les commandes SELECT, INSERT, UPDATE, DELETE et les index. Il ne supporte pas les commandes ALTER TABLE, DROP TABLE ou les autres commandes de Définition des données (Data Definition Language). Cette première implémentation n'utilise pas les commandes préparées. Nous étudions actuellement la possibilité d'ajouter le support de ces fonctionnalités au client.
L'implémentation utilise SELECT, INSERT, UPDATE, DELETE et non pas HANDLER.
Les tables FEDERATED ne fonctionne pas avec le cache de requêtes. Certaines limitations seront levées dans les futures versions du gestionnaire FEDERATED.