7.6.1.2 Utiliser les liens symboliques avec les tables sous Unix

Avant MySQL 4.0, vous ne devez pas utiliser les liens symboliques avec les tables, si vous n'êtes pas très prudents avec. Le problème est que si vous exécutez ALTER TABLE , REPAIR TABLE ou OPTIMIZE TABLE sur une table symbolique, le lien sera supprimé et remplacé par le fichier original. Cela arrive car les commandes ci-dessus fonctionnent en créant un fichier temporaire dans le dossier de base, et lorsque l'opération est faite, l'original est remplacé par la copie.

En MySQL 4.0, les liens symboliques sont complètement supportés par les tables MyISAM . Les autres types de tables vous donneront des résultats étranges lorsque vous les utilisez comme indiqué ci-dessus.

Dans le dossier de données, vous allez toujours trouver le fichier de définition de table, le fichier de structure et le fichier d'index.

• Dans le dossier de données, vous devez toujours avoir le fichier de définition de table, le fichier de données et le fichier d'index. Les fichiers de données et d'index peuvent être déplacés ailleurs, et remplacés dans le dossier de données par des liens symboliques. Mais le fichier de définition ne le peut pas.
• Vous pouvez utiliser un lien symbolique avec le fichier d'index et celui de données, pour placer ces fichiers dans d'autres dossiers.
• Le lien symbolique peut être fait via le système d'exploitation (si mysqld ne fonctionne pas) ou avec la commande INDEX/DATA DIRECTORY="path-to-dir" dans CREATE TABLE . Syntaxe de CREATE TABLE .
• myisamchk ne va pas remplacer un lien symbolique avec les données ou le fichier d'index, mais il va travailler directement sur le fichier vers lequel le lien pointe. Tous les fichiers temporaires seront créé dans le même dossier que le dossier qui contient les données ou le fichier d'index.
• Lorsque vous détruisez une table qui utilise un lien symbolique, le fichier et le lien symbolique sont détruits. C'est une bonne raison pour ne pas exécuter mysqld en tant que root ou donner des droits d'écriture à d'autres personnes dans les dossiers de données de MySQL.
• Si vous renommez une table avec ALTER TABLE RENAME vous n'avez pas à déplacer la table dans une autre base, le lien symbolique du dossier de base sera renommé avec le nouveau nom.
• Si vous utilisez la commande ALTER TABLE RENAME pour déplacer la table dans une autre base, la table sera déplacée dans l'autre base, et l'ancien lien symbolique et le fichier vers lequel il pointait seront détruits (en d'autres termes, la nouvelle table ne sera pas un lien symbolique).
• Si vous n'utilisez pas de lien symbolique, vous devriez utiliser l'option --skip-symlink de mysqld pour vous assurer que personne n'efface ou ne renomme un fichier en dehors du dossier de données de MySQL.

Ce qui n'est pas encore supporté :

• ALTER TABLE ignore toutes les options INDEX/DATA DIRECTORY="path" .
• BACKUP TABLE et RESTORE TABLE ne respectent pas les liens symboliques.
• Le fichier .frm ne doit jamais être un lien symbolique (Comme indiqué précédemment, seul les fichiers d'index et de données peuvent être des liens symboliques. Si jamais vous le faites malgré tout, vous générerez des erreurs de cohérence. Supposez que vous une base db1 dans le dossier de données MySQL , et une table tbl1 dans cette base, et dans le dossier db1 , vous faites un lien symbolique tbl2 qui pointe sur tbl1 :

  shell> cd /path/to/datadir/db1 shell> ln -s tbl1.frm tbl2.frm shell> ln -s tbl1.MYD tbl2.MYD shell> ln -s tbl1.MYI tbl2.MYI

  Il va y avoir des problèmes si un thread lit db1.tbl1 et qu'un autre modifie db1.tbl2 :
  • Le cache de requête sera induit en erreur (il va croire que tbl1 a été mis à jour, et retournera des résultats incohérents).
  • La commande ALTER de la table tbl2 va aussi échouer.