Archives par mot-clé : serveur

Configuration MySQL – quelques astuces

Paramètre Max Packet Size pour les grosses requêtes

Il faut augmenter la valeur du paramètre max_allowed_packet dans le fichier de configuration de MySQL pour permettre de gérer les grosses requêtes : principalement pour les tables qui contiennent des BLOB et CLOB qui peuvent être volumineux.

Méthodes

Éditer le fichier my.ini

Ajouter ce qui suit dans la section [mysqld] du fichier de configuration

#Max packetlength to send/receive from to server.
max_allowed_packet=8M

Utiliser l’interface graphique MySQL Administrator

Modifier le paramètre dans l’interface graphique comme dans la capture d’écran suivant :

MySQL : modification du paramètre "max_packet_size"
MySQL : modification du paramètre "max_packet_size"

Importer une base de Windows à Linux

La gestion des noms de tables est configurée différemment par défaut sous Windows ou Linux :

  • Sous Windows il ne tient pas compte de la casse,
  • Sous Linux il en tient compte.

Le passage du contenu d’une base de données d’un OS à un autre peut donc être problématique, principalement dans le sens Windows -> Linux. En effet, faire le dump depuis Windows va minimiser tous les noms de tables. Et si jamais le code source de votre application référence les tables avec des majuscules, cela peut posser des soucis. Surtout qu’il n’est pas toujours possible de re-écrire le code pour n’utiliser que des noms de tables en minuscules. Voici les solutions que j’utilise dans ces cas-là.

Choix 1 : Modifier la configuration du MySQL sous Linux

Pour importer une base MySQL depuis une machine Windows vers une machine Linux, il est possible de configurer le serveur MySQL sous Linux avec le paramètre lower_case_table_names à 1. Pour cela, éditer le fichier my.ini et placer dans la section [mysqld] la ligne suivante :

set-variable = lower_case_table_names=1

Voir la documentation MySQL pour plus de détails sur ce sujet.

Choix 2 : Transformer le fichier de dump

Si il n’est pas possible de modifier la configuration du serveur MySQL sous linux, il reste la solution – beaucoup plus sport – qui consiste à modifier le fichier de dump. En fait, il va falloir diviser le dump en deux fichiers :

Le premier fichier qui ne contient que la structure de la base :  dump.struct.sql Il peut être créé avec la commande suivante :

 mysqldump -hHOSTNAME -uUSER -p -d DBNAME > dump.struct.sql

Le deuxième fichier qui ne contient que les données de la base : dump.data.sql Il peut être créé avec la commande suivante (–hex-blob pour exporter les binaires en hexadécimal et –extended-insert=false pour avoir une commande INSERT par enregistrement) :

 mysqldump -hHOSTNAME -uUSER -p --hex-blob --extended-insert=false -t DBNAME > dump.data.sql

Il va ensuite falloir transformer ces fichiers pour que les noms des tables soient en majuscules :

Pour le fichier dump.struct.sql

C’est l’opération la plus simple. Utilisez la commande ‘tr‘ comme suit :

$ cat dump.struct.sql | tr '[:lower:]' '[:upper:]' > dump.struct.upper.sql

Et importer le fichier dump.struct.upper.sql résultant dans la base.

Pour le fichier dump.data.sql

Là c’est un peu plus compliqué, car on ne veut pas tout mettre en majuscules, car ce fichier contient aussi les données des différentes tables de notre base.

Note : il est à rapeller que le fichier dump.data.sql ne contient qu’une ligne de données – ie un INSERT – par enregistrement de chaque table.

Utiliser la commande ‘awk‘ pour modifier les commandes ‘INSERT INTO‘ et ‘LOCK TABLE‘ comme suit – chaque commande awk doit être sur une seule ligne :

$ awk '$1 == "LOCK" || $1 == "INSERT" { $3 = toupper($3) ; print $0 };
 $1 != "INSERT" && $1 != "LOCK" {print $0}; ' dump.data.sql > dump.data.upper.sql

En fonction de la structure du fichier d’import des données, il se peut que le nom des tables soit utilisé dans d’autres commandes, comme par exemple des commandes pour ignorer les intégrités référentielles : ALTER TABLE `une_table` DISABLE KEYS. Il faut dans ce cas se baser sur les scripts ci-dessus pour créer un nouveau qui corrigera ce problème.

Il n’y a plus qu’à importer le fichier dump.data.upper.sql dans la base MySQL.

Applications Java serveur nécessitant un serveur X

Comment se passer d’un serveur X pour une application java qui en veut un alors qu’elle tourne sur un serveur qui n’est pas sensé en avoir : vous me suivez ?

Des applications java peuvent avoir besoin d’un serveur X pour faire du rendu de dessin. C’est le cas par exemple en cas d’utilisation de la bibliothèque de rendu de graphiques JChart ou avec JasperReport. On aura par exemple une stacktrace du genre :

java.lang.InternalError

Can't connect to X11 window server using ':0.0' as the value of the DISPLAY variable.sun.awt.X11GraphicsEnvironment::initDisplay (native)

sun.awt.X11GraphicsEnvironment::<clinit> ( X11GraphicsEnvironment.java: 134 )

java.lang.Class::forName0 (native)

java.lang.Class::forName ( Class.java: 141 )

java.awt.GraphicsEnvironment::getLocalGraphicsEnvironment ( GraphicsEnvironment.java: 62 )

net.sf.jasperreports.engine.util.JRGraphEnvInitializer::initializeGraphEnv ( JRGraphEnvInitializer.java: 58 )

...

Cependant, sous les serveurs de production, on lance rarement un serveur X. Il faut donc utiliser soit :
– un serveur virtuel xvfb
– l’option -Djava.awt.headless=true [1] si on utilise Java 1.4 ou supérieur

PS : Cette astuce a été trouvée dans la doc de jCharts

[1] ou dans le code avec System.setProperty(“java.awt.headless”,”true”) ;