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

 

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

 

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

 

Par Pti-seb, lundi 26 mai 2008 à 18:52

Comparer la performance de serveurs MySQL rapidement

Voici une petite astuce qui permet de faire un benchmark très rapide sur un serveur MySQL, afin de vérifier ses performances.

Pour ce faire, ouvrez un shell MySQL et lancez la requête suivante :

mysql> SELECT benchmark(100000000,1+2); +--------------------------+ | benchmark(100000000,1+2) | +--------------------------+ | 0 | +--------------------------+ 1 row in set (2.89 sec)

Le résultat de la requête renverra toujours zéro, mais ce qui nous intéresse est le temps d’exécution de cette dernière, qui nous est donnée en seconde. Voici les résultat de test obtenues sur des machines ayant un processeur et une méthode d’installation de MySQL différente :

  • Intel Xeon Bi-processeurs (3.40GHz) 2.89 sec
  • AMD 64 3200+ : 4.92 sec
  • Intel Pentium 4 Dual Core (3.20 GHz) : 3.76 sec
  • Intel Xeon Bi-processeurs (3.00 GHz) : 3.43 sec

Très pratique pour comparer rapidement les performances entre différentes serveurs ou architectures voir avec différentes configuration.

fév 292008
 

UNICODE UTF8

A toute nouvelle installation d’instance du SGBD MySQL, avant toute utilisation, penser à le configurer en UNICODE pour être tranquille par le suite.

Pour ceci ajouter les lignes suivante dans la section [mysqld] de votre fichier /etc/mysql/my.cnf


[mysqld]
default-character-set=utf8
default-collation=utf8
collation_server=utf8_general_ci
character_set_server=utf8
skip-character-set-client-handshake

UTF8 vs LATIN1

Attention, mysql reste plus rapide en utilisant le jeu de caractère latin1 ou n’importe jeu de caractère localisé. Le nombre de caractère disponible étant plus réduit que en UFT8. La taille des enregistrement sera donc également plus petite en latin1 que en UTF8. Ceci n’a pas beaucoup de sens au vue de nos disques dure de plusieurs centaine de Giga Octet. Mais du coté de la mémoire, de la taille des index ou dans l’embarqué ceci peux avoir son importance.

© 2012 Karlesnine Suffusion theme by Sayontan Sinha