InnoDB et la réplication MySQL
<<<		 Espaces de tables multiples : chaque table InnoDB a son fichier @filename{.ibd} Tables InnoDB
>>>
16.7 Créer des tables InnoDB
16 Tables InnoDB
 Manuel de Référence MySQL 4.1 : Version Française
. Comment utiliser les transactions de InnoDB avec différentes API
. Convertir des tables MyISAM vers InnoDB
. Comment les colonnes AUTO_INCREMENT fonctionnent avec InnoDB
. Contraintes de clés étrangères FOREIGN KEY
. InnoDB et la réplication MySQL
->Espaces de tables multiples : chaque table InnoDB a son fichier @filename{.ibd}

16.7.6 Espaces de tables multiples : chaque table InnoDB a son fichier @filename{.ibd}

Depuis MySQL 4.1.1, vous pouvez stocker chaque table InnoDB et ses index dans son propre fichier. Cette fonctionnalité est appelée ``espaces de tables multiples'', car chaque table dispose de son propre espace de table.

Note importante : si vous passez en version InnoDB 4.1.1 ou plus récent, il devient très difficile de retourner en versions 4.0 ou 4.1.0! Ceci est dû au fait que les versions antérieures de InnoDB ne sont pas compatibles avec les espaces de tables multiples.

Si vous devez revenir à une vieille version 4.0, vous devez faire des exports des tables, et recréer tout votre espace de tables InnoDB . Si vous n'avez pas créé de nouvelles tables sous InnoDB >= 4.1.1, et que vous devez revenir rapidement en arrière, vous pouvez passer directement en versions 4.0.18, ou plus récent. Avant de faire un retour en arrière direct en versions 4.0, vous devez terminer toutes les connexions, et laisser mysqld vider les buffers d'insertion, jusqu'à ce que SHOW INNODB STATUS indique que le thread principal soit dans un état de waiting for server activity . Alors, vous pouvez éteindre le serveur mysqld et démarrer votre version 4.0.18 ou plus récent. Un retour en arrière direct n'est pas recommandé, car il n'a pas été totalement testé.

Depuis MySQL version 4.1.1, vous pouvez stocker chaque table InnoDB et ses index dans son propre fichier. Cette fonctionnalité est appelé espaces de tables multiples, car chaque table a son propre espace de table.

Vous pouvez activer cette fonctionnalité en ajoutant une ligne dans le groupe [mysqld] du fichier my.cnf : 


[mysqld]
innodb_file_per_table
Après redémarrage du serveur, InnoDB va stocker chaque table dans son propre fichier tablename.ibd du dossier de données, où les tables sont stockées. C'est la même méthode que MyISAM , mais si MySQL divise les tables en un fichier de données et un fichier d'index, tablename.MYD et tablename.MYI , InnoDB place les données et les index dans le même fichier .ibd . Le fichier tbl_name.frm est toujours créé, comme d'habitude.

Si vous supprimez la ligne innodb_file_per_table du fichier my.cnf , alors InnoDB créera les tables dans le fichier de données.

innodb_file_per_table affecte seulement la création de tables. Si vous démarrez le serveur avec cette option, les nouvelles tables sont créées avec le fichier .ibd , mais vous pouvez toujours accéder aux tables qui existent dans l'espace de table partagées ibdata . Si vous supprimez cette option, les nouvelles tables seront crées dans l'espace de tables, mais vous pouvez toujours aux tables qui ont été créées indépendamment.

InnoDB a toujours besoin du système d'espace de tables, les fichiers .ibd ne sont pas suffisants. Le système d'espaces de table est constitué des fichiers classiques ibdata . InnoDB y place son dictionnaire de données interne, et ses historiques d'annulation.

Vous ne pouvez pas déplacer les fichiers .ibd librement , comme vous pouvez le faire avec les tables MyISAM . Ceci est dû au fait que les définitions de tables sont stockées dans le système d'espace de tables InnoDB , et aussi, parce que InnoDB doit préserver la cohérence des identifiants de transactions et les numéros de séquence des logs.

Vous pouvez déplacer le fichier .ibd et la table associée d'une base à l'autre (dans la même installation MySQL/ InnoDB ) avec la classique commande RENAME : 


RENAME TABLE old_db_name.tbl_name TO new_db_name.tbl_name;
Si vous avez une sauvegarde ``propre'' du fichier .ibd , vous pouvez restaurer l'installation MySQL comme ceci :
  • Utilisez cette commande ALTER TABLE : 
    
ALTER TABLE tbl_name DISCARD TABLESPACE;
    Attention : cette commande efface le fichier .ibd .
  • Placez le fichier de sauvegarde .ibd dans le bon dossier de base de données.
  • Utilisez cette commande ALTER TABLE : 
    
ALTER TABLE tbl_name IMPORT TABLESPACE;
Dans ce contexte, un fichier .ibd ``propre'' signifie :
  • Il n'y a pas de modifications non validées par des transactions dans le fichier .ibd file.
  • Il n'y a pas de buffer d'insertion non intégrés dans le fichier .ibd .
  • La purge a supprimé toutes les lignes marquées pour l'effacement dans le fichier .ibd .
  • mysqld a envoyé toute les pages modifiées au fichier .ibd depuis le buffer de fichier.
Vous pouvez faire une sauvegarde propre du fichier .ibd en suivant la méthode :
  • Cessez toute activité sur le serveur mysqld et validez toutes les transactions.
  • Attendez que SHOW INNODB STATUS\G indique qu'il n'y a plus de transaction active dans la base, et que le thread principal de InnoDB est dans l'état Waiting for server activity . Vous pouvez alors faire une copie du fichier .ibd .
Une autre méthode (non libre) de faire une sauvegarde propre du fichier .ibd est de :
  • Utilisez InnoDB Hot Backup pour faire une sauvegarde de votre installation InnoDB .
  • Lancez un second serveur mysqld sur la sauvegarde, et laissez le nettoyer les fichiers .ibd de la sauvegarde.

La liste de tâche inclut la possibilité de déplacer les fichiers .ibd vers une autre installation MySQL/ InnoDB . Cela impose la remise à zéro des numéros de transactions et des séquences de fichiers de log du fichier .ibd .

<< Espaces de tables multiples : chaque table InnoDB a son fichier @filename{.ibd} >>
InnoDB et la réplication MySQL Créer des tables InnoDB Tables InnoDB