Karlesnine.com

Aller au contenu Aller au menu Aller à la recherche

Tag - MySQL

Fil des billets - Fil des commentaires

mardi, février 16 2010

MySQL Innodb nouvelle notes de configuration et d'optimisation

Par Charles-Christian Croix le mardi, février 16 2010, 10:23 - Technologic

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

12 commentaires

mercredi, décembre 16 2009

MySQL Innodb notes de configuration et d'optimisation

Par Charles-Christian Croix le mercredi, décembre 16 2009, 14:07 - Technologic

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

#
# Moteur par defaut de stokage, ici InnoDB parce que  Ez publish
#
default-storage-engine  = InnoDB

UTF8

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

#
# Encodage UTF8
#
default-character-set=utf8
default-collation=utf8
collation_server=utf8_general_ci
character_set_server=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.

#
# Instead of skip-networking you can listen only on
# localhost which is more compatible and is not less secure.
bind-address            =
#skip-networking

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.

#skip-innodb
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.

#log_bin                        = /var/log/mysql/mysql-bin.log

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

10 commentaires

dimanche, septembre 13 2009

Les surprises d'une migration d'un site en Ez publish 3.6

Par Charles-Christian Croix le dimanche, septembre 13 2009, 11:31 - Technologic

Y'a des joies ineffable dans le métier d'admin sys et tomber sur une couche archéologique numérique datant de plus de 5 ans en fait partie. Dans le car présent le poisson est sympa un eZ 3.6 (php 4.3.10 et Mysql 4.1) sur une Debian sarge (kernel 2.4.31), le tout sans mise à jour depuis septembre 2005. Bref du faisandé à travaillé du bout des doigts.

Las bases de données sont en jachère. Moteur calé sur du Latin1 et par de support UTF8. Le contenue en latin et en....copier coller word 97 c'est sur mais impossible d'avoir un charset de référence. J'ai donc du luté pour obtenir un dump valide et exploitable. Voici la commande salvatrice pour Mysql 4.1 et quelque explication.

mysqldump -a -Q -q -c -u <USER> -p<MOT-DE-PASSE> --add-drop-table --add-locks -v

-a : ajoute les options de création spécifiques à MySQL
-Q : protège les noms de table et de colonne par des quotes
-q : n’utilise pas de tampon
-c : utilise des instructions INSERT complètes
-u : nom d’utilisateur pour la connexion à la base
-p : demande un mot de passe
—add-drop-table : ajoute une commande « DROP TABLE table » avant chaque CREATE
—add-locks : ajoute des locks autour des commandes INSERT
-v : affiche des informations pendant le dump

3 commentaires

- page 1 de 3