fichier de données MySQL InnoDB directement sur une tranche de disque (de taille fixe)?

Question

Il semble que ibdata1 est comme une tranche de disque. Dans Solaris (UNIX) (systèmes de fichiers UFS l'un de commun avant ZFS), on pourrait séparer leur c0t0d0 disque en tranches, disons un lecteur 10GB serait coupé en trois sections, 4 Go, 1 Go et 5 Go. Ceux-ci seraient les systèmes de fichiers de taille fixe. Les 4 Go pour, par exemple, OS. 1 Go pour le swap et 5GB pour les logiciels et les données.

swap peut être stocké sur un fichier sur un système de fichiers, mais pour des performances il est habituellement stocké sur sa propre section du disque.

peut ibdata1 être lié à sa propre tranche pour stimuler la performance? Bien sûr, on devrait réfléchir soigneusement avant de décider quelle taille fixe est idéal et ils doivent également savoir comment vérifier les niveaux d'utilisation.

Un lien symbolique peut être placé de .../mysql/data/ibdata1 à /dev/rdsk/c0t0d0s3. MySQL serait alors voir comme un fichier, mais peut mieux faire, car il ne doit pas passer par la couche système de fichiers, il écrirait directement à une section désignée du disque.

• Quelqu'un at-il essayé?
• Quelqu'un pense que c'est une mauvaise idée? (Gardez à l'esprit, cette idée est pour les serveurs de base de données uniquement InnoDB uniquement. Non serveurs multi-usage.)
• Ne serait-il travailler (Est-ce InnoDB besoin de vérifier la longueur du fichier? Sinon, il devrait fonctionner.)
• Peut-on vérifier l'utilisation?

Answer 1

D'abord, quels sont les types d'entrée qui résident dans ibdata1? Quatre (4) types d'entrée:

• Tableau MetaData
• Tableau de données Pages
• Index pages de données
• MVCC données

Chaque fois une table InnoDB expériences DDL, DML, ou d'être utilisé dans une transaction, les quatre de ces types d'entrées sont lues soit ou écrites. Pendant ce temps, si innodb_file_per_table est désactivé, tous ces types d'entrée vivent dans ibdata1. Si elle est activée, seul le tableau et les données MetaData MVCC résideraient dans ibdata1 tandis que les pages de données Table et Index Pages données résiderait dans le sous-dossier de base de données sous forme de fichier .ibd.

Cela étant considéré, ce qui se passerait si ibdata1 ont été placés dans un autre volume et un lien symbolique?

Pour commencer, comment MySQL représente une table quel que soit le moteur de stockage? En tant que fichier .frm. Où allons-.frm en direct? Dans le datadir. Quel est le problème avec ça?

Voici un exemple:

Utilisation du datadir par défaut / var / lib / mysql, nous allons utiliser une table InnoDB appelée mydb.mytable.

handicapés, innodb_file_per_table tout s'asseyait dans ibdata1 (que vous proposez à envoyer un lien symbolique et à un autre volume de données). Pour la table mydb.mytable, c'est ce que vous auriez:

• /var/lib/mysql/mydb/mytable.frm
• Tout le reste de la vie de table dans ibdata1

Imaginez maintenant: Vous accédez à la table, MySQL serait d'abord frappé /var/lib/mysql/mydb/mytable.frm et puis appuyez sur les données et les pages d'index dans ibdata1 pour mydb.mytable. Cela se passe en permanence avec tous les accès des mydb.mytable. Cette cascade va-et-vient serait en quelque sorte rendre les choses un peu plus lent et vous ne pouvez pas obtenir les performances que vous attendiez en déplaçant ibdata1 à un autre volume de données. En fait, l'effet en cascade serait désormais un facteur du nombre de tables InnoDB multiplié par deux (2).

Imaginez avoir innodb_file_per_table activé. Maintenant, vous auriez une configuration légèrement différente:

• /var/lib/mysql/mydb/mytable.frm
• /var/lib/mysql/mydb/mytable.ibd
• données MVCC et le tableau MetaData résiderait dans ibdata1

Cette cascade serait un peu moins parce que la mise en cascade pour l'accès de table se produirait maintenant parmi les trois fichiers au lieu de deux.

Voici un scénario plus certains ont pensé: au lieu de déplacer le ibdata1 à un volume différent, que diriez-vous permettant innodb_file_per_table et déplacer les fichiers .ibd à un ou plusieurs différents volumes de données? L'effet en cascade serait désormais un facteur du nombre de tables InnoDB multiplié par trois (3). Percona a exprimé de très bonnes raisons pour ne pas faire ce que vous trouverez utile .