Pourquoi InnoDB stocke-t-il toutes les bases de données dans un seul fichier?


51

Il était pratique que MyISAM stocke chaque table dans un fichier correspondant. InnoDB a progressé à de nombreux égards, mais je me demande pourquoi InnoDB stocke toutes les bases de données dans un seul fichier ( ibdata1par défaut).

Je comprends que InnoDB mappera l’emplacement des données dans le fichier par fichiers d’index individuels pour les tables, mais je ne comprends pas pourquoi il mélange toutes les données dans un seul fichier. Et plus important encore, pourquoi mélanger les données de toutes les bases de données sur le serveur?

Une fonctionnalité intéressante de MyISAM est qu’il est possible de copier / coller un dossier de base de données sur une autre machine, puis d’utiliser la base de données (sans vidage).

Réponses:


67

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é

InnoDB ( innodb_file_per_table désactivé)

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.

InnoDB ( innodb_file_per_table activé)

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 avecALTER 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 avecALTER 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 .

AVERTISSEMENT (ou DANGER comme dirait le robot dans Lost in Space )

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.


Est-ce que cela signifie que lorsque j'utilise un fichier innodb par table activée et que je dois importer mes données d'un serveur à un autre, je ne devrai utiliser que mysqldump et pas d'autres outils tels que Percona xtrabackup?
tesla747

14

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.


Il ne fait aucun doute qu'InnoDB est un moteur flexible, mais je ne comprends pas en quoi le stockage de toutes les données dans un fichier est bénéfique (car cette nouvelle structure a été mise en œuvre dans InnoDB en comparaison avec MyISAM).
Googlebot

Je pense que c’est plutôt l’un de ces problèmes avec le recul qui est 20/20. L'option fichier par table a été ajoutée après le premier lancement par innodb des tablettes. En plus de lui donner son propre bloc pour éviter les frais généraux du système de fichiers, je ne peux pas expliquer pourquoi il est préférable de les vider tous ensemble (et tout le problème du périphérique est son propre débat). Toutes les configurations innodb ont un fichier par table activé.
Atxdba

C'est l'intérêt de ne pas compter sur un système de fichiers, mais il n'est pas actif par défaut. Ainsi, quelques utilisateurs l'utiliseront.
Googlebot

1
Une option fichier par table peut être préjudiciable si vous avez plusieurs tables et pas beaucoup de RAM (un magasin Magento, par exemple, peut avoir environ 1 000 tables). Et le réglage des fichiers ouverts doit également être optimisé (en tenant compte des limitations du système d'exploitation). Alors, utilisez avec prudence.
Ypercubeᵀᴹ

Cela peut certainement freiner les efforts de rétablissement. Oui, vous devriez avoir une sauvegarde, mais si vous n'en avez pas, InnoDB rend les choses plus difficiles à cause de cette structure.
Mikato

10

C'est le comportement par défaut mais pas obligatoire. À partir de la documentation MySQL, utilisation de tablespaces par table :

Par défaut, toutes les tables et tous les index InnoDB sont stockés dans l'espace de table système. Vous pouvez également stocker chaque table InnoDB et ses index dans son propre fichier . Cette fonctionnalité est appelée "plusieurs espaces de table" car chaque table créée lorsque ce paramètre est activé possède son propre espace de 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):

Considérations de portabilité pour les fichiers .ibd

Vous ne pouvez pas déplacer librement des fichiers .ibd entre des répertoires de base de données, contrairement aux fichiers de table MyISAM. La définition de table stockée dans l'espace de table partagé InnoDB inclut le nom de la base de données. Les ID de transaction et les numéros de séquence de journal stockés dans les fichiers d'espace de table diffèrent également d'une base de données à l'autre.


Réponse très informative et clarification du problème, mais je suis toujours curieux de savoir comment un gros fichier contenant toutes les bases de données peut améliorer les performances (le cas échéant).
Googlebot

Les performances ne sont pas meilleures car il n’ya qu’un seul fichier pour tous. Diverses caractéristiques, telles que le verrouillage au niveau de la ligne, au lieu du niveau de la table, contribuent aux performances. Bien entendu, l’avantage principal réside dans les transactions et les contraintes FK (et donc l’intégrité de la base de données).
Ypercubeᵀᴹ

1
Vous avez parfaitement raison en matière d'intégrité! Je comprends pourquoi il est préférable de mettre toutes les tables d’une base de données dans un seul fichier; mais je ne comprends pas pourquoi mettre toutes les bases de données (qui sont complètement indépendantes) sur le même fichier. InnoDB utilise par défaut un seul fichier pour stocker les données.
Googlebot
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.