Archives pour l'étiquette innodb

Pour connaitre la taille d’une table ou d’une bases MySQL en ligne de commande

Pour connaitre la taille d’une table ou d’une de vos bases MySQL en ligne de commande. J’avais pas

Alors pour la taille de toutes les bases :

SELECT table_schema "Databases", sum( data_length + index_length) / 1024 / 1024 "Size of DB in MB" FROM information_schema. TABLES GROUP BY table_schema;

Pour la taille d’une base :

SELECT table_schema "Database", sum( data_length + index_length) / 1024 / 1024 "Size of DB in MB" FROM information_schema. TABLES WHERE table_schema = "DBNAME" GROUP BY table_schema;

La taille de toutes les tables d’une base :

SELECT table_name AS "Tables", round(((data_length + index_length) / 1024 / 1024), 2) "Size in MB" FROM information_schema. TABLES WHERE table_schema = "$DB_NAME";

et la taille d’une table d’une base :

SELECT table_name AS "Table", round(((data_length + index_length) / 1024 / 1024), 2) "Size in MB" FROM information_schema. TABLES WHERE table_schema = "DBNAMEE" AND table_name = "TABLENAME";

MySQL Innodb nouvelle notes de configuration et d’optimisation

Pour compléter une note précédente sur Innodb et UTF8 et le billet sur les premières notes de configuration et d’optimisation de MySQL Innodb voici quelques notes de configuration de MySQL supplémentaire et complémentaire avec le moteur de base de donnée Innodb. Note toujours valable _ pour toute solution d’hébergement ou architecture MySQL est dédier eZ Publish, Dotclear 2 et autre CMS.

INNODB_BUFFER_POOL_SIZE

  • Espace mémoire de mise en cache des bases de données.
  • Ne pas hésiter à allouer 80 ~ 90% de la mémoire disponible sur le serveur si celui ci est dédier DB
  • Dans la mesure du possible doit être légèrement supérieur en taille à /var/lib/mysql

INNODB_FLUSH_METHOD

  • Instruction de gestion des accès disque
  • CODE_FS par défaut, laisse à l’OS toute possibilité de gérer les accès selon ces principes. L’OS peux donc utilisé son propre cache qui viendrais ce superposer à celui de innodb
  • O_DIRECT informe l’OS d’écrire sans délai sans tenir compte de son cache.
  • A rapprocher de l’instruction gérant le scheduler de l’OS cf: /sys/block/sda/queue/scheduler

QUERY-CACHE

  • Concerne les instructions query_cache_limit, query_cache_size, query_cache_type
  • A utilise seulement en cas de requêtes uniforme et répétitive, inutile si celle ci sont déporter sur un memcache
  • Effacer dans ce cache et y réécrire impose un MUTEX et donc un lock de tout les thread.
  • A utilisé seulement si le gain d’utilisation VS lock mutex est positif, rarement le cas sur une architecture qui utilise du memcache

SINGLE-TRANSACTION

  • mysqldump single-transaction all-databases > dump.sql
  • Instruction –single-transaction determine que le dump est a réaliser dans le contexte de l’instant T (snapshot style)
  • Ne génère pas de lock, lecture, écriture toujours possible
  • Génère une charge en lecture. Charge quasi nul sur tout le contenue de base dumper est en mémoire
  • Génère une charge en écriture. Penser à écrire sur une FileSystem non sollicité.

MySQL Innodb notes de configuration et d’optimisation

Pour compléter une note précédente sur Innodb et UTF8 voici quelques notes de configuration de MySQL avec le moteur de base de donnée Innodb sous forme de checklist pour toute solution d’hébergement ou architecture MySQL est dédier eZ Publish, Dotclear 2 et autre CMS.

Utilisez le moteur Innodb

Forcer le moteur par defaut de stokage en InnoDB pour la création de toute nouvelle table sans spécification du moteur souhaité.

<span style="color: #808080; font-style: italic;">#</span> <span style="color: #808080; font-style: italic;"># Moteur par defaut de stokage, ici InnoDB parce que  Ez publish</span> <span style="color: #808080; font-style: italic;">#</span> default-storage-engine  = InnoDB

UTF8

Prévoir dès le départ l’encodage des base en UFT8

<span style="color: #808080; font-style: italic;">#</span> <span style="color: #808080; font-style: italic;"># Encodage UTF8</span> <span style="color: #808080; font-style: italic;">#</span> default-character-<span style="color: #007800;">set=</span>utf8 default-<span style="color: #007800;">collation=</span>utf8 <span style="color: #007800;">collation_server=</span>utf8_general_ci <span style="color: #007800;">character_set_server=</span>utf8 skip-character-set-client-handshake

Configurer l’écoute sur toute les interfaces réseaux

Ouvrir à un utilisation via le réseau sans limitation d’interface ou d’adresse.

<span style="color: #808080; font-style: italic;">#</span> <span style="color: #808080; font-style: italic;"># Instead of skip-networking you can listen only on</span> <span style="color: #808080; font-style: italic;"># localhost which is more compatible and is not less secure.</span> bind-address            = <span style="color: #808080; font-style: italic;">#skip-networking</span>

Optimisation tablespace

Prévoir le lancement du moteur innodb avec comme configuration un fichier tablespace par table. Cela va créé un fichier tablespace pour chaque table innodb et vous évitera d’avoir dans quelque mois un unique fichier tablespace de plusieurs giga octet impossible à manipuler.

<span style="color: #808080; font-style: italic;">#skip-innodb</span> innodb_file_per_table

Optimisation Log

Bloquer les log binaire qui consomme beaucoup d’espace disque et n’apporte pas de sécurité sur une plate-forme qui n’a pas de réplication Master / Slave MySQL.

<span style="color: #808080; font-style: italic;">#log_bin                        = /var/log/mysql/mysql-bin.log</span>

Optimisation innodb_buffer_pool_size

innodb_buffer_pool_size définie la taille de buffer mémoire que InnoDB utilise pour mettre en cache les données et les index de tables. Plus cette valeur est grand, et moins vous ferez d’accès disques. Sur un serveur dédiés, vous pouvez monter cette valeur jusqu’à 80% de la mémoire physique de la machine. Ne lui donnez pas une valeur trop grande, car cela peut engendrer l’utilisation de mémoire sur le disque par votre serveur (swap).

Oracle, Sun, Innodb, Mysql

ORACLE s’empare de SUN pour 7,4 milliards de dollars

Bon, ok

Mais Sun possède MySQL et Oracle Innodb, le seul moteur transactionnel performant tournant avec le SGBD Mysql. Un tel concentration me laisse dubitatif sur l’avenir du moteur transactionnel FALCOM de MySQL qui devait devenir l’alternative face a Innodb propriété d’Oracle.

MySQL va t’il être phagocyté par Oracle qui n’a pas avantage commercialement à entretenir une concurrence frontal avec lui même ?

A lire pour plus d’information la nouvelle sur linuxfr.org : Oracle achète Sun. Ainsi que la température prise à la MySQL conf 2009 (20 – 23 Avril) donner dans les commentaires