L’architecture d’InnoDB requiert l’utilisation de quatre types de base de pages d’informations.
- Pages de données de table
- Pages d'index de table
- Table MetaData
- Données MVCC (pour prendre en charge l'isolation de transaction et la conformité ACID )
- Segments de restauration
- Annuler l'espace
- Double Write Buffer (écriture en arrière-plan pour éviter de dépendre de la mise en cache du système d'exploitation)
- Insert Buffer (gestion des modifications apportées aux index secondaires non uniques)
Voir la représentation imagée de ibdata1
Par défaut, innodb_file_per_table est désactivé. Cela force les quatre types de page d’informations à atterrir dans un seul fichier appelé ibdata1. De nombreuses personnes tentent de répartir les données en créant plusieurs fichiers ibdata. Cela pourrait entraîner une fragmentation des pages de données et d'index.
C'est pourquoi je recommande souvent de nettoyer l'infrastructure InnoDB en utilisant le fichier par défaut ibdata1 et rien de plus .
La copie est très dangereuse en raison de l'infrastructure sous laquelle InnoDB fonctionne. Il y a deux infrastructures de base
- innodb_file_per_table désactivé
- innodb_file_per_table activé
Lorsque innodb_file_per_table est désactivé, tous ces types d’informations InnoDB résident dans ibdata1. La seule manifestation d'une table InnoDB en dehors de ibdata1 est le fichier .frm de la table InnoDB. La copie simultanée de toutes les données InnoDB nécessite la copie de tout le répertoire / var / lib / mysql.
Copier une table InnoDB individuelle est totalement impossible. Vous devez dump MySQL pour extraire un dump de la table en tant que représentation logique des données et des définitions d’index correspondantes. Vous devez ensuite charger cette sauvegarde dans une autre base de données sur le même serveur ou sur un autre serveur.
Lorsque innodb_file_per_table est activé, les données de table et leurs index résident dans le dossier de base de données situé à côté du fichier .frm. Par exemple, pour la table db1.mytable, la manifestation de cette table InnoDB en dehors de ibdata1 serait:
/var/lib/mysql/db1/mytable.frm/var/lib/mysql/db1/mytable.ibd
Tablespace système ibdata1
Toutes les métadonnées de db1.mytable résident toujours dans ibdata1 et il n’ya absolument aucune solution . Les fichiers de journalisation et les données MVCC sont également toujours actifs avec ibdata1.
En ce qui concerne la fragmentation des tables, voici ce qui arrive à ibdata1:
- innodb_file_per_table activé : vous pouvez réduire db1.mytables avec
ALTER TABLE db1.mytable ENGINE=InnoDB;ouOPTIMIZE TABLE db1.mytable;. Ceci a pour résultat que /var/lib/mysql/db1/mytable.ibd est physiquement plus petit sans fragmentation.
- innodb_file_per_table disabled : vous ne pouvez pas réduire db1.mytables avec
ALTER TABLE db1.mytable ENGINE=InnoDB;ouOPTIMIZE TABLE db1.mytable;car il réside avec ibdata1. En exécutant l'une ou l'autre de ces commandes, la table est contiguë et plus rapide en lecture et en écriture. Malheureusement, cela se produit à la fin de ibdata1. Cela fait que ibdata1 se développe rapidement. Ceci est entièrement traité dans mon message de nettoyage InnoDB .
Si vous envisagez de copier simplement les fichiers .frm et .ibd, vous êtes en ligne de mire pour le monde des blessures. La copie des fichiers .frm et .ibd d’une table InnoDB n’est valable que si et seulement si vous pouvez garantir que l’id de tablespace du fichier .ibd correspond exactement à l’entrée entrée dans les métadonnées du fichier ibdata1 .
J'ai écrit deux articles dans DBA StackExchange sur ce concept d'id de tablespace
Voici un excellent lien sur la façon de rattacher un fichier .ibd à ibdata1 en cas d'identificateurs de tablespace incompatibles: http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file . Après avoir lu ceci, vous devriez immédiatement réaliser que copier des fichiers .ibd est tout simplement fou.
Pour InnoDB, il vous suffit de quelque chose qui bouge
CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
faire une copie d'une table InnoDB.
Si vous le migrez vers un autre serveur de base de données, utilisez mysqldump.
En ce qui concerne le mélange de toutes les tables InnoDB de toutes les bases de données, je vois vraiment la sagesse de le faire. Chez mon employeur, fournisseur de base de données / hébergement Web, j'ai un client MySQL qui a une table dans une base de données dont les contraintes sont mappées vers une autre table dans une autre base de données au sein de la même instance MySQL. Avec un référentiel de métadonnées commun, il rend possible la prise en charge transactionnelle et l'opérabilité de MVCC sur plusieurs bases de données.
Vous pouvez basculer InnoDB pour stocker des tables par fichier en ajoutant innodb-file-per-table à votre fichier cnf.
Innodb se préoccupe vraiment des pages de données de base. En fait, vous pouvez configurer InnoDB pour qu’il utilise uniquement un périphérique de bloc brut sans système de fichiers! http://dev.mysql.com/doc/refman/5.5/en/innodb-raw-devices.html
Il est pratique de stocker des tables pour des fichiers, par exemple de pouvoir plus facilement récupérer l'espace utilisé via optimisation.
Même avec des fichiers par table, vous ne pouvez pas simplement copier les fichiers ibd aussi facilement, car InnoDB est transactionnel et stocke des informations sur son état dans les fichiers ibdata / log partagés.
Cela ne veut pas dire que cela ne peut pas être fait. Si la table est hors ligne, vous pouvez ignorer / importer les espaces de table et copier le fichier .idbs dans http://dev.mysql.com/doc/refman/5.5/fr/innodb-multiple-tablespaces.html.
la source
C'est le comportement par défaut mais pas obligatoire. À partir de la documentation MySQL, utilisation de tablespaces par table :
La raison en est probablement due aux architectures différentes des deux moteurs (MyISAM et InnoDB). Par exemple, dans InnoDB, vous ne pouvez pas simplement copier le fichier .ibd dans une autre base de données ou installation. Explication (de la même page):
la source