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
.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.