Manuel de référence MySQL 5.0

Les options suivantes de mysqld permettent de modifier le comportement des tables MyISAM :

• --myisam-recover=mode

  Active le mode de restauration automatique des tables MyISAM corrompues ;

• --delay-key-write=ALL

  N'écrit pas les buffers de clés entre deux écritures dans une table MyISAM.

  Note : si vous faites cela, vous ne devez pas utiliser les tables MyISAM avec d'autres programmes (comme depuis un autre serveur MySQL ou avec myisamchk) lorsque la table est utilisée. Sinon, vous allez obtenir une corruption d'index.

  Utiliser --external-locking n'aidera pas les tables qui utilisent --delay-key-write.

Voir Section 5.2.1, « Options de ligne de commande de mysqld »5.2.1. Options de ligne de commande de mysqld.

Les variables systèmes suivantes affectent le comportement des tables MyISAM :

• bulk_insert_buffer_size

  La taille du cache d'index lors des insertions de masse. Note : c'est une limite par thread !

• myisam_max_extra_sort_file_size

  Utilisée pour aider MySQL à décider quand utiliser le cache de clé lent mais sûr. Note : ce paramètre était donné en mégaoctets avant MySQL 4.0.3 et en octets depuis 4.0.3 ;

• myisam_max_sort_file_size

  N'utilise pas la méthode de tri rapide pour créer un index, dans le cas où un fichier temporaire dépasserait cette taille. Note : ce paramètre était donné en mégaoctets avant MySQL 4.0.3 et en octets depuis 4.0.3 ;

• myisam_sort_buffer_size

  La taille du buffer lors de la restauration de table.

Voir Section 5.2.3, « Variables serveur système »5.2.3. Variables serveur système.

La restauration automatique est activée si vous lancez mysqld avec l'option --myisam-recover. Dans ce cas, lorsque le serveur ouvre la table MyISAM, il vérifie si la table a été marquée comme crashée ou si le compteur de tables ouvertes n'est pas zéro ou si le serveur utilise --skip-external-locking. Si une des conditions précédente est vraie, il arrive ceci :

• la table est analysée pour rechercher des erreurs ;

• si le serveur trouve une erreur, il essaie de faire une réparation rapide (avec le tri, sans recréer de données) ;

• si la réparation échoue à cause d'une erreur dans le fichier de données (par exemple une erreur de clé), le serveur essaie à nouveau, en recréant le fichier de données ;

• si la réparation échoue encore, le serveur essaie encore avec une ancienne méthode de réparation (écrire les lignes les unes après les autres, sans tri). Cette méthode devrait être capable de réparer tout les types d'erreurs et elle occupe peu de place sur le disque.

Si la restauration n'est toujours pas capable de retrouver toutes les lignes et que vous n'avez pas spécifié l'option FORCE dans la valeur de l'option --myisam-recover, la réparation automatique s'annule, avec le message d'erreur suivant :

Error: Couldn't repair table: test.g00pages

Si vous spécifiez la valeur FORCE, une alerte comme celle-ci sera écrite dans les logs :

Warning: Found 344 of 354 rows when repairing ./test/g00pages

Notez que si la valeur de restauration automatique inclut BACKUP, le processus de restauration créera des fichiers avec des noms de la forme tbl_name-datetime.BAK. Vous devriez avoir une tâche régulière avec cron pour supprimer automatiquement ces fichiers dans les bases de données pour nettoyer le volume.

MySQL supporte plusieurs types d'index, mais le type normal est ISAM ou MyISAM. Ils utilisent un index B-tree et vous pouvez avoir une approximation de la taille du fichier d'index en faisant la somme de (longueur_clé+4)/0.67 pour toutes les clés. Cela est le pire des cas où les clés sont insérées dans l'ordre et qu'aucune n'est compressée.

Les index de chaînes de caractères sont compressés par rapport aux espaces. Si la première partie de l'index est une chaîne, son préfixe sera aussi compressé. La compression des espaces rend le fichier d'index plus petit que ce que nous avions calculé précédemment si la colonne chaîne possède beaucoup d'espaces invisibles en début et fin de chaîne ou est une colonne VARCHAR qui n'est pas toujours pleinement utilisée. La compression des préfixes est utilisée sur les clés qui commencent par une chaîne de caractères, s'il y a plusieurs chaînes avec des préfixes identiques.

Dans les tables MyISAM, vous pouvez aussi compresser les nombres en spécifiant PACK_KEYS=1 lors de la création de la table. Cela vous aidera lorsque vous aurez plusieurs clés de types entier qui auront un préfixe identique et que les nombres seront classés par ordre décroissant des grands octets.

MyISAM supporte 3 différents types de tables. Deux des trois sont choisis automatiquement selon le type de colonne que vous utilisez. Le troisième, tables compressées, ne peut être crée qu'avec l'outil myisampack.

Quand vous créez une table avec CREATE ou en modifiez la structure avec ALTER vous pouvez, pour les tables n'ayant pas de champ BLOB, forcer le type de table en DYNAMIC ou FIXED avec l'option ROW_FORMAT=# des tables. Bientôt, vous pourrez compresser/décompresser les tables en spécifiant ROW_FORMAT=compressed | default à ALTER TABLE. Voir Section 13.2.5, « Syntaxe de CREATE TABLE »13.2.5. Syntaxe de CREATE TABLE.

14-1-3-1. Caractéristiques des tables statiques (taille fixée)▲

14-1-3-2. Caractéristiques des tables à format de ligne dynamique▲

14-1-3-3. Caractéristiques des tables compressées▲

Le format de fichier que MySQL utilise pour stocker les données a été testé à l'extrême, mais il y a toujours des circonstances qui peuvent corrompre les tables d'une base de données.

14-1-4-1. Tables MyISAM corrompues▲

14-1-4-2. Des clients utilisent la table, ou bien elle n'a pas été fermée correctement▲

# clients is using or hasn't closed the table properly

Voici ci-dessous une liste des problèmes connus avec les tables de type MERGE.

• Si vous utilisez la commande ALTER TABLE pour modifier une table de type MERGE en un autre type de table, la liste des tables sous-jacentes sera perdue. Au lieu de cela, les lignes des tables seront copiées dans la nouvelle table, puis on lui assignera le nouveau type.

• Avant MySQL 4.1.1, toutes les tables sous-jacentes et la table MERGE devaient être dans la même base de données.

• REPLACE ne fonctionne pas.

• Vous ne pouvez pas utiliser DROP TABLE, ALTER TABLE, DELETE FROM sans clause WHERE, REPAIR TABLE, TRUNCATE TABLE, OPTIMIZE TABLE, ou ANALYZE TABLE sur l'une des tables qui est dans une table MERGE « ouverte ». Si vous faites cela, la table MERGE va utiliser la table originale et vous obtiendrez des résultats étranges. Le plus simple est d'utiliser la commande FLUSH TABLES pour s'assurer qu'aucune table MERGE ne reste « ouverte. »

• Une table MERGE ne peut pas supporter de contrainte de type UNIQUE sur toute la table. Lorsque vous faites une insertion, les données vont dans la première ou la dernière table (suivant la méthode d'insertion INSERT_METHOD=xxx) et cette table MyISAM s'assure que les données sont uniques, mais rien n'est fait pour vérifier l'unicité auprès des autres tables MyISAM.

• Avant MySQL 3.23.49, DELETE FROM merge_table utilisé sans clause WHERE va uniquement détruire la table assemblée, mais ne va pas toucher les tables sous-jacentes. En fait, le fichier .MRG est effacé, mais pas les tables.

• RENAME TABLE utilisé sur une table de type MERGE peut corrompre la table. Cela sera corrigé en MySQL 4.1.x.

• La création d'une table de type MERGE ne vérifie pas si les tables sous-jacentes sont compatibles. Si vous utilisez une table MERGE de cette façon, vous devriez rencontrer des problèmes très étranges.

• L'ordre des index dans la table MERGE et ses tables sous-jacentes doit être le même. Si vous utilisez la commande ALTER TABLE pour ajouter un index de type UNIQUE à une table qui est utilisée dans une table assemblée MERGE, puis que vous utilisez ALTER TABLE pour ajouter un index normal dans la table MERGE, l'ordre des clés sera différent suivant les tables, si jamais il y avait une vieille clé non unique. Ceci est dû au fait que ALTER TABLE place les clés UNIQUE avant les clés normales, pour être capable de détecter les doublons le plus tôt possible.

• DROP TABLE sur une table qui est utilisée par une table MERGE ne fonctionne pas sous Windows, car le gestionnaire de MERGE garde les connexions vers les tables cachées sous la couche MySQL. Comme Windows ne vous permet pas d'effacer une table qui est ouverte, vous devez d'abord fermer toutes les tables MERGE (avec la commande FLUSH TABLES) ou effacer la table MERGE avant de pouvoir effacer la table désirée. Nous allons corriger lorsque nous introduirons les vues VIEWs.

Actuellement, nous savons que le gestionnaire BDB fonctionne avec les systèmes d'exploitation suivants.

• Linux 2.x Intel

• Sun Solaris (SPARC et x86)

• FreeBSD 4.x/5.x (x86, sparc64)

• IBM AIX 4.3.x

• SCO OpenServer

• SCO UnixWare 7.1.x

Il ne fonctionne pas sur les systèmes d'exploitation suivants.

• Linux 2.x Alpha

• Linux 2.x AMD64

• Linux 2.x IA64

• Linux 2.x s390

• Max OS X

Note : la liste ci-dessus n'est pas complète ; nous la mettrons à jour au fur et à mesure que nous recevrons des informations à ce propos.

Si, après avoir compilé MySQL avec le support des tables BDB, vous obtenez l'erreur suivante dans le fichier de logs quand vous démarrez mysqld :

bdb: architecture lacks fast mutexes: applications cannot be threaded
Can't init databases

Cela signifie que les tables BDB ne sont pas supportées par votre architecture. Dans ce cas, vous devez recompiler MySQL sans le support des tables BDB.

Si vous avez téléchargé une version binaire de MySQL qui inclut le support de BerkeleyDB, vous n'avez qu'à suivre les instructions classiques (MySQL-Max inclut le support BDB).

Si vous compilez MySQL depuis les sources, vous pouvez activer le support BDB en ajoutant au script configure l'option --with-berkeley-db. Téléchargez la distribution de MySQL 3.23.34 ou plus récent, allez dans la racine des sources et tapez :

shell> ./configure --with-berkeley-db [other-options]

Pour plus d'informations, voyez Section 2.3, « Installer MySQL sur d'autres systèmes type Linux »2.3. Installer MySQL sur d'autres systèmes type Linux, Section 5.1.2, « mysqld-max, la version étendue du serveur mysqld »5.1.2. mysqld-max, la version étendue du serveur mysqld et Section 2.4, « Installation de MySQL avec une distribution source »2.4. Installation de MySQL avec une distribution source.

Les options suivantes de mysqld peuvent être utilisées pour modifier le comportement des tables BDB.

• --bdb-home=répertoire

  Répertoire de base des tables BDB. Cela doit être le même répertoire que vous avez utilisé pour --datadir.

• --bdb-lock-detect=#

  Détection des verrouillages Berkeley (DEFAULT, OLDEST, RANDOM, ou YOUNGEST).

• --bdb-logdir=répertoire

  Répertoire des fichiers de logs de Berkeley DB.

• --bdb-no-recover

  Ne pas démarrer Berkeley DB en mode de restauration.

• --bdb-no-sync

  Ne pas vider les tampons de manière synchrone.

• --bdb-shared-data

  Démarrer Berkeley DB en mode multiprocessus (ne pas utiliser DB_PRIVATE lors de l'initialisation de Berkeley DB)

• --bdb-tmpdir=répertoire

  Répertoire des fichiers temporaires de Berkeley DB.

• --skip-bdb

  Désactive l'utilisation des tables BDB.

Voir Section 5.2.1, « Options de ligne de commande de mysqld »5.2.1. Options de ligne de commande de mysqld.

Les variables systèmes suivantes affectent le comportement des tables BDB.

• bdb_max_lock

  Le nombre maximal de verrous actifs sur une table BDB.

Voir Section 5.2.3, « Variables serveur système »5.2.3. Variables serveur système.

Si vous utilisez --skip-bdb, MySQL n'initialisera pas la bibliothèque Berkeley DB et cela économisera beaucoup de mémoire. Bien sûr, vous ne pouvez pas utiliser les tables BDB si vous utilisez cette option. Si vous essayez de créer une table BDB, MySQL créera une table MyISAM à la place.

Normalement, vous devez démarrer mysqld sans --bdb-no-recover si vous avez l'intention d'utiliser des tables BDB. Cela peut cependant vous poser des problèmes si vous essayez de démarrer mysqld alors que des fichiers de logs BDB sont corrompus. Voir Section 2.5.2.3, « Problèmes de démarrage du serveur MySQL »2.5.2.3. Problèmes de démarrage du serveur MySQL.

Vous pouvez spécifier le nombre maximal de verrous avec bdb_max_lock (10000 par défaut) que vous pouvez activer sur une table BDB. Vous devez l'augmenter si vous obtenez des erreurs du type :

bdb: Lock table is out of available locks
Got error 12 from ...

lorsque vous avez fait de longues transactions ou quand mysqld doit examiner beaucoup de lignes pour calculer la requête.

Vous pouvez aussi changer les options binlog_cache_size et max_binlog_cache_size si vous utilisez de grandes transactions multilignes. Voir Section 5.9.4, « Le log binaire »5.9.4. Le log binaire.

Chaque table BDB est stockée sur le disque en deux fichiers. Les fichiers portent le nom de la table et ont des extensions qui indiquent le type de fichier. Un fichier .frm stocke la définition de la table et le fichier .db contient les données et les index.

Pour spécifier explicitement que vous voulez une table BDB, indiquez l'option de création de table ENGINE ou TYPE :

CREATE TABLE t (i INT) ENGINE = BDB;
CREATE TABLE t (i INT) TYPE = BDB;

BerkeleyDB est un synonyme de BDB pour les options ENGINE et TYPE.

Le moteur de tables BDB fournit un modèle transactionnel. La façon dont vous utilisez ces tables dépend du mode de validation :

• si vous utilisez le mot d'autovalidation (ce qui est le mode par défaut), les modifications dans les tables BDB sont validées immédiatement et ne peuvent pas être annulées ;

• si vous utilisez le mode de validation manuel, les modifications ne seront rendues permanentes que si vous envoyez la commande COMMIT. Au lieu de valider, vous pouvez aussi annuler avec la commande ROLLBACK pour détruire les modifications.

  Vous pouvez démarrer une transaction avec la commande BEGIN WORK pour suspendre le mode d'autovalidation, ou avec SET AUTOCOMMIT=0 pour le désactiver explicitement.

Voir Section 13.4.1, « Syntaxes de START TRANSACTION, COMMIT et ROLLBACK »13.4.1. Syntaxes de START TRANSACTION, COMMIT et ROLLBACK.

Le moteur de tables BDB a les caractéristiques suivantes.

• Les tables BDB peuvent avoir jusqu'à 31 index par table, 16 colonnes par index et une taille maximale de 1024 octets par index (500 octets avant MySQL 4.0).

• MySQL requiert une clé PRIMARY KEY dans chaque table BDB pour être capable de faire référence aux lignes précédemment lues. Si vous n'en créez pas, MySQL va gérer une telle clé de manière cachée. La clé cachée a une taille de 5 octets et est incrémentée à chaque nouvelle insertion.

• La clé PRIMARY KEY sera plus rapide que n'importe quelle autre clé, car la PRIMARY KEY est stockée avec les données. Comme les autres clés sont stockées sous la forme données + PRIMARY KEY, il est important de garder une clé PRIMARY KEY aussi courte que possible pour économiser de l'espace disque et améliorer la vitesse.

  Ce comportement est similaire à celui d'InnoDB, où des clés primaires courtes économisent de l'espace pour la clé primaire et pour les index secondaires aussi.

• Si toutes les colonnes auxquelles vous accédez dans une table BDB font partie du même index dans la clé primaire, alors MySQL peut exécuter la requête sans avoir à lire la ligne elle-même. Dans une table MyISAM, ce qui précède n'est valable que si les colonnes font partie du même index.

• Scanner séquentiellement est plus lent qu'avec MyISAM, car les tables BDB stockent les données dans un fichier B-tree et non pas dans un fichier séparé.

• Les clés ne sont pas compressées avec les clés précédentes, comme pour les tables ISAM et MyISAM. En d'autres termes, les informations de clés prennent un peu plus d'espace pour les tables BDB, comparativement aux tables MyISAM qui n'utilisent pas l'option PACK_KEYS=0.

• Il y a souvent des trous dans les tables BDB pour vous permettre d'insérer de nouvelles lignes au milieu de l'arbre de données. Cela rend les tables BDB un peu plus grandes que les tables MyISAM.

• SELECT COUNT(*) FROM table_name est très lent, car les tables BDB ne maintiennent pas un compte de leurs lignes dans la table.

• L'optimiseur a besoin de connaître une approximation du nombre de lignes dans la table. MySQL résout ce problème en comptant les insertions et en conservant ce compte dans un segment séparé pour chaque table BDB. Si vous ne faites pas souvent de DELETE ou ROLLBACK, ce nombre sera plutôt précis pour l'optimiseur MySQL, mais comme MySQL ne stocke ce nombre qu'à la fermeture de la table, il peut être incorrect si MySQL s'interrompt inopinément. Cela ne doit pas être fatal si ce nombre n'est pas à 100 % correct. Vous pouvez forcer la mise à jour de ce nombre avec la commande ANALYZE TABLE ou OPTIMIZE TABLE. Section 13.5.2.1, « Syntaxe de ANALYZE TABLE »13.5.2.1. Syntaxe de ANALYZE TABLE . Section 13.5.2.5, « Syntaxe de OPTIMIZE TABLE »13.5.2.5. Syntaxe de OPTIMIZE TABLE.

• Le verrouillage interne des tables BDB est fait au niveau page.

• LOCK TABLES fonctionne avec les tables BDB sur les autres tables. Si vous n'utilisez pas le verrou LOCK TABLE, MySQL va poser un verrou interne multiple sur la table, pour s'assurer que la table est bien verrouillée, si un autre thread tente de poser un verrou.

• Pour permettre les annulations de transaction, BDB gère des fichiers de logs. Pour maximiser les performances, vous devriez placer ces fichiers sur un autre disque que celui de votre base, en utilisant l'option --bdb-logdir.

• MySQL fait un point de contrôle à chaque fois qu'un nouveau fichier de logs BDB est démarré et supprime les fichiers de logs anciens qui ne sont pas utiles. Si vous exécutez la commande FLUSH LOGS, vous placerez un nouveau point de contrôle pour les tables Berkeley DB.

  Pour la restauration après crash, vous devez utiliser les sauvegardes et le log binaire de MySQL. Voir Section 5.7.1, « Sauvegardes de base de données »5.7.1. Sauvegardes de base de données.

  Attention : si vous effacez les anciens fichiers de logs qui sont en cours d'utilisation, BDB ne sera pas capable de faire la restauration et vous risquez de perdre des données.

• L'application doit toujours être prête à gérer des cas où une modification sur une table BDB peut être annulée, ou une lecture abandonnée pour cause de blocage de verrous.

• Si vous atteignez la capacité maximale du disque avec la table BDB, vous allez obtenir une erreur (probablement l'erreur 28) et la transaction va s'annuler. C'est un comportement différent des tables MyISAM et ISAM qui vont attendre que mysqld ait trouvé de l'espace disque avant de continuer.

• Il est très lent d'ouvrir de nombreuses tables BDB en même temps. Si vous utilisez des tables BDB, il ne faut pas avoir un cache de table trop grand (par exemple > 256) et vous devriez utiliser l'option --no-auto-rehash avec le client mysql. Nous envisageons de corriger cela en partie en version 4.0.

• SHOW TABLE STATUS ne fournit pas encore beaucoup d'informations pour les tables BDB.

• Optimiser les performances.

• Ne pas utiliser les verrous de pages lorsque l'on scanne les tables.

Voilà les restrictions que vous pouvez rencontrer en travaillant avec les tables BDB.

• Les tables BDB enregistrent dans le fichier .db le chemin vers le fichier tel qu'il était lorsqu'il a été créé. Cela fait que les tables BDB ne peuvent être changées de répertoire !

• Lors de la sauvegarde de tables BDB, vous devez utiliser mysqldump ou effectuer des sauvegardes de tous les fichiers de tables (les fichiers .frm et .db) et les fichiers de logs BDB. Les fichiers de logs de BDB sont les fichiers dans le répertoire de base des données nommés log.XXXXXXXXXX (dix chiffres).

• Si une colonne accepte les valeurs NULL, avec un index unique, seule une valeur NULL est autorisée. Cela diffère du comportement des autres moteurs.

• Si vous obtenez l'erreur suivante dans le fichier hostname.err log lors du démarrage de mysqld :

   

  Sélectionnez

  bdb:  Ignoring log file: .../log.XXXXXXXXXX: unsupported log version #

  cela signifie que la nouvelle version de BDB ne supporte pas l'ancien format de log. Dans ce cas, vous devez effacer tous les logs BDB du dossier des données (les fichiers dont le nom est au format log.XXXXXXXXXX) et redémarrer mysqld. Nous vous recommandons aussi d'exécuter un mysqldump --opt de vos vieilles tables BDB, de les effacer, puis de restaurer les copies.

• Si vous n'êtes pas en mode autocommit et que vous effacez une table qu'un autre thread utilise, vous obtiendrez le message d'erreur suivant dans le fichier d'erreurs de MySQL :

   

  Sélectionnez

  001119 23:43:56  bdb:  Missing log fileid entry
  001119 23:43:56  bdb:  txn_abort: Log undo failed for LSN:
                         1 3644744: Invalid

  Ce n'est pas une erreur très grave mais nous ne vous recommandons pas d'effacer vos tables si vous n'êtes pas en mode autocommit, tant que ce problème n'est pas résolu (la solution n'est pas triviale).

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

Lorsque vous créez une table FEDERATED, le serveur crée un fichier de définition de fichiers 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é 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 telles que la commande SELECT les attend, 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 sont reçues 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.

La procédure pour utiliser les tables FEDERATED est très simple. Normalement, vous devez avoir 2 serveurs en fonctionnement, 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ésentent 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 fonctionner 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'option 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.

Voici ci-dessous 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 n'essayiez d'y accéder via la table FEDERATED.

• Il est possible pour 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 parler de l'effet Larsen ? Vous avez déjà vu ce que ça 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 a changé. La raison est que la table doit fonctionner comme un fichier de données qui n'est jamais écrit par autre chose que la base de donné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 fonctionnent pas avec le cache de requêtes.

Certaines limitations seront levées dans les futures versions du gestionnaire FEDERATED.