Les différents moteurs de stockage de MySQL

Le moteur FEDERATED permet de déporter les données sur un serveur distant.

Il est possible par exemple, d'avoir une base dont les données sont réparties sur plusieurs serveurs distants géographiquement. Dans une base utilisant le moteur FEDERATED, on ne trouve qu'un fichier *.frm qui est la définition de table. Les données sont stockées sur un ou plusieurs serveurs distants. Par le mot "distant", il faut comprendre que le serveur possédant une table FEDERATED devient client d'un autre serveur MySQL. Cela oblige cet autre serveur à se trouver à l'extérieur ou dans un réseau local. En aucun cas il ne peut être le "localhost".

Cela peut être presque comparable à une vue pour base de données MySQL.

Sur le serveur "visible", se trouve une base de données contenant deux tables utilisant le moteur FEDERATED et pointant vers deux serveurs distants. Les serveurs A et B contiennent chacun une table de type quelconque (par exemple MyISAM). Dans ce type de structure, les moteurs utilisés par les serveurs distants n'ont aucune importance.

scheme://user_name[:password]@host_name[:port_num]:/db_name/tbl_name

CREATE TABLE t_user (
    id      int(20) NOT NULL auto_increment,
    idgroup int(10) NOT NULL,
    name    varchar(32) NOT NULL default '',    
    PRIMARY KEY  (id)
    KEY idgroup
)
ENGINE=Federated
CONNECTION='mysql://root@serverB:9306/t_user';


CREATE TABLE t_group (
    idgroup int(10) NOT NULL auto_increment,
    name    varchar(32) NOT NULL default '',    
    PRIMARY KEY  (id)    
)
ENGINE=Federated
CONNECTION='mysql://root@serverC:9306/t_group';

CREATE TABLE t_user (
    id      int(20) NOT NULL auto_increment,
    idgroup int(10) NOT NULL,
    name    varchar(32) NOT NULL default '',    
    PRIMARY KEY  (id)
    KEY idgroup
) ENGINE=MyISAM;

CREATE TABLE t_group (
    idgroup int(10) NOT NULL auto_increment,
    name    varchar(32) NOT NULL default '',    
    PRIMARY KEY  (id)    
) ENGINE=MyISAM;

Dans les versions antérieures à MySQL 5.1x, la propriété contenant le paramétrage de connexion distante est COMMENT (mais elle ne servait pas pour autant à stocker des commentaires).

• Il est important d'avoir exactement la même structure entre la table de type FEDERATED et la table distante.
• Il est nécessaire de vérifier que le serveur distant est déjà activé avant d'y faire la moindre requête.
• Il est possible de pointer vers une table distante qui elle aussi utilise le moteur FEDERATED. Il faut être sûr de la cartographie du serveur distant et donc de faire très attention à ne pas tomber dans une boucle infinie.
• Si la structure de la table distante est différente de celle de la table FEDERATED attachée, le lien sera cassé.

• Permet de répartir la charge.
• Pointer sur plusieurs bases de données distantes si elles acceptent les accès distants.
• Supporte les index.

• Ne supporte que les commandes SQL simples (SELECT, DELETE, INSERT, UPDATE). Il n'est pas possible de faire ALTER TABLE, bien qu'il aurait été utile de pointer vers un autre serveur à la volée afin d'émuler un Load Balancing par exemple
• Ne gère pas les transactions.
• Les performances sont liées au réseau et à son débit.
• Le mot de passe apparaît en clair dans la propriété COMMENT.
• Pas de possibilité de savoir si des modifications ont eu lieu sur le serveur distant.
• Faible disponibilité chez les hébergeurs.

Ce moteur offre de grandes opportunités d'administration d'une base de données.

Avec ce moteur, il est possible de faire une base de données métier à partir de plusieurs bases réparties géographiquement sur des machines distinctes.

Il est à noter que, lors de l'écriture de cet article, les tests tentés sur ce moteur sont restés vains.