MySQL SELECT query with LIKE case sensitive ?

Today at work I helped an intern with an interesting problem I would like to share.
he was doing this kind of query on a MySQL server :

SELECT description FROM service WHERE description LIKE '%cloud%';

It returned these lines :

cloud customer 1
cloud customer 2

but does not return these two lines he was expecting :

new Cloud infra
Cloud customer 2

LIKE should be case insensitive … What was wrong ?

Continue reading “MySQL SELECT query with LIKE case sensitive ?” »

Lyon de nuit

Bien photographier la Fête des Lumières à Lyon

Vous avez réservé votre billet de train pour Lyon début décembre ? Vous allez déambuler dans les rues de la ville tous les soirs pour photographier les illuminations ? Super, je serai probablement en train de faire la même chose que vous … Mais pour assurer les meilleures photos possible, quelques précieux conseils peuvent transformer des photos floues et sombres en superbes réalisations. Je vais rester simple et concis !

Pied photo

Tout d’abord, sachez qu’un pied photo est absolument obligatoire ! Si vous n’en avez pas, toutes vos photos devront être prises avec un support stable : un banc, une barrière …

Si vous avez ce précieux ustensile, apprenez à vous en servir rapidement, car vous n’aurez pas beaucoup de temps pour le déplier et le replier entre chaque endroit. Pour garder la meilleure stabilité possible, dépliez-le toujours le moins possible (en fonction de la hauteur de prise de vue que vous voulez), en finissant toujours par la collerette qui vibre le plus (donc préférez déplier tous les pieds avant d’y toucher). Pour prendre une photo, utilisez une poire ou un déclencheur à distance : en effet, la simple pression du bouton va faire vibrer le pied … Si vous n’avez ni l’un ni l’autre, ajoutez un retardateur de 2 secondes minimum dans les réglages de l’appareil (testé et approuvé).

Reflex

Un reflex est bien sûr fortement recommandé ! Vous pourrez alors régler des paramètres indispensables comme l’exposition, l’ouverture ou le temps de pose. Voyons ces réglages en détail…

L’exposition

Ou ISO, correspond à la sensibilité du capteur photo (dans le temps, c’était la sensibilité de la pellicule), donc en vulgarisant, la lumière imprime plus ou moins vite en fonction de l’ISO. En général, l’exposition est automatique sur un reflex, mais si vous voulez de belles photos, je vous recommande chaudement de changer la plage d’exposition automatique. En effet, à la sensibilité maximale, vous ne verrez qu’une grosse purée de pois. Il faut donc limiter la plage qu’utilisera votre appareil (sachant que de nuit, il utilisera essentiellement le maximum défini).
l’expo maximale est différente en fonction de l’appareil que vous avez. Mais pour la trouver, c’est très simple : vous allez prendre une photo de la rue en face de chez vous, de nuit. Elle est normalement peu éclairée, et devrait ressembler à ce que vous allez photographier. Réglez votre appareil photo sur l’ouverture maximale (le plus petit chiffre donc, par exemple F/1.4), et une pause à 1/25e de seconde. Forcez l’ISO en commençant par ISO 800 et en incrémentant petit à petit entre deux photos. Allez maintenant regarder les photos en grand sur votre écran d’ordinateur, et déterminez l’ISO maximum avant de voir apparaitre beaucoup de grain dans votre image. Sur un reflex d’entrée de gamme, cela sera aux alentours de ISO 1600. Sur un reflex haut de gamme, ISO 3200. Vous avez choisi ? OK alors maintenant modifiez la plage ISO automatique, et définissez le maximum. Voilà, vous êtes au moins certain d’avoir des photos sans (trop de) bruit. Fixez ce paramètre, car en situation nous n’y toucherons plus.

La focale

Il s’agit vulgairement du zoom. Si vous avez un reflex à objectif interchangeable, choisissez un objectif avec la plus grande focale possible. En effet, vous allez prendre essentiellement des plans larges, donc ne vous encombrez pas d’un téléobjectif. Personnellement, j’utilise un 24-105mm (mais un 24-70 serait encore mieux car normalement plus lumineux) et j’effectue 90% de mes photos entre 24mm et 50mm.

L’ouverture

Elle définit la profondeur de champ, c’est à dire la part d’image qui sera nette, et celle qui sera floue en fonction de la profondeur par rapport à la mise au point (cette partie floue s’appelle le bokeh). Pour un 8 décembre, vous allez surtout photographier des murs éclairés, et avec un très grand angle, donc peu de travail artistique à faire sur la profondeur de champ. Choisissez donc l’ouverture la plus grande possible (donc F/4 ou moins : attention c’est une fraction, donc ouverture la + grande == chiffre F/X le plus petit), qui vous donnera donc le plus de lumière.

Le temps de pause

Plus il est court, moins votre image sera lumineuse. Donc il s’agira de trouver le temps le plus long possible, tout en gardant une image nette. Comme vous avez un pied, pas de limite ! Cela va donc dépendre de votre sujet :

  • Pour une scène fixe, n’hésitez pas à faire des temps de pause supérieurs à 15 secondes. Cela aura un autre avantage : les (nombreux) passants seront flous.
  • Pour les projections, deux réglages pour avoir des images nettes :
    • Si c’est un éclairage au laser (très lumineux, utilisé aux Terreaux notamment), un temps de pause de 1/3 de seconde suffit (car le laser produit moins d’images par seconde)
    • Si c’est du vidéo projecteur (classique, mais un peu moins lumineux), il faudra prendre à 1/25e de seconde.

Voilà, j’espère qu’avec tous ces conseils, vous allez prendre de magnifiques photos !

Using auditd to troubleshoot file reads

Today I will talk about auditd, a very powerfull tool to debug anything you need in a linux platform. In this very case, I had a problem with a mail server using all IO available. ‘iostat’ command told me it was reads ops that saturate it. A mail server has many process, so using “strace” is not helpful here. I choose to use auditd.

Continue reading “Using auditd to troubleshoot file reads” »

Test de plusieurs services après-vente

Après un emmenagement, j’ai pu – malgré moi – tester plusieurs services après-vente de grands prestataires. Même si une expérience n’est pas représentatif du traitement général, c’est toujours un indicateur …

SAV Darty

Le frigo INDESIT a été reçu avec un plateau cassé, non signalé à la livraison car il était emballé / scotché. J’ai appelé le jour même le SAV pour leur signaler le problème, et ils m’ont dit qu’ils me rappelleraient dans la journée pour me confirmer le renvoi de la pièce. Malheureusement, ils n’ont pas rappelé. Trois jours plus tard, je rappelle le SAV qui m’indique que la pièce a bien été commandé et qu’ils attendent un retour du fabricant. Deux semaines plus tard, je reçois de Chronopost le nouveau plateau bien emballé, même sans avoir été tenu au courant par téléphone ou email. Ils n’ont pas demandé de photo du produit cassé, ou de le renvoyer.

Suivi : moyen
Réception du produit de remplacement : en 11 jours ouvrés à compter de la déclaration au SAV.

 

SAV Boulanger

Commande d’un ampli home Cinema de marque Denon. Malheureusement, la sortie vidéo ne fonctionne pas (le son est OK). Appel du SAV un samedi matin, qui m’indique qu’un expert va me rappeler dans la journée pour tester l’appareil à distance. Je reçois bien l’appel à 18h le soir même. Quelques vérifications plus tard, le technicien me dit qu’il faut retourner le produit, et pour cela rappeler le SAV Boulanger.fr (car achat sur Internet) pour organiser ça (il laisse une note dans mon dossier pour bien dire que les tests ont été effectués). Malheureusement, ce service est fermé le samedi. Je rappelle donc le lundi matin, et on me communique un bon de retour Collissimo, à coller sur l’emballage d’origine. C’est parti pour porter les 15kg de l’ampli jusqu’au bureau de poste le plus proche. Envoi le mardi matin, réception le jeudi (dixit suivi de colis). Enregistrement du retour le lundi qui suit. Après appel du SAV, on m’indique que le produit doit retourner chez Denon afin de revenir. J’insiste un peu en disant que le produit ne marchait pas à la livraison, et on me propose de me rappeler le lendemain pour voir ce qu’on peut faire. Je relance alors une fois toutes les deux semaines, mais personne ne sait vraiment où en est mon dossier … On me propose de me rappeler le lendemain, ce qui n’est jamais arrivé. Puis le 15 décembre, miracle, on me rappelle pour me dire que le produit est revenu du SAV et va m’être envoyé.

Suivi : moyen
Réception du produit de remplacement : 24/12 (signalement le 16/11, renvoi du produit cassé le 18/11)

SAV Ubaldi

Réception d’une TV plasma Panasonic. Livraison OK, mais après déballage le soir même, je vois que les lunettes 3D sont cassées. Je contacte le SAV Ubaldi par email. Réponse le lendemain me demandant des photos du produit, ce que je fait. Une personne me rappelle le lendemain, me demandant de retourner le produit. Il me dit que Chronopost passera directement chez moi récupérer le produit (pas besoin de le porter à la Poste). Nouveau produit commandé chez le fabricant, en attente. Le SAV m’a rappelé de lui même pour m’indiquer que ce retour prendrait plus de temps que prévu. Ensuite, je recevrais un appel par semaine pour me tenir au courant de l’avancement (qui est toujours le même : aucun stock chez la marque …). Le 2 janvier, après deux mois d’attente, la société me propose un remboursement de 70€ (soit le prix des lunettes dans le commerce).

C’est au final le seul cas où le SAV n’aura pas pu résoudre mon problème, mais c’est la seule marque qui a pris la peine de me rappeler chaque semaine, à chaque fois par la même personne, pour me tenir au courant.

Suivi : très bon
Réception du produit de remplacement : chèque de 70 euros envoyé le 2 janvier (signalement le 7/11, renvoi du produit cassé le 12/11).

 

Story of a MySQL crash (memory issue)

Today we faced an important issue with MySQL 5.5
Server stalled after aborting a TRUNCATE on a big table. Yes, this is bad to abort a TRUNCATE ;) But this is not the issue I want to speak about. Server crashed, that’s a point. mysqld process restarted automatically, and started loading data into memory (massive use of InnoDB tables). This server has 128GB of memory, so buffer pool was set to 100GB (yes, that’s quite huge). Data set is ~ 100GB. After a few minutes, server crashed again, but this time complaining about memory.

Continue reading “Story of a MySQL crash (memory issue)” »

Tests approfondis de G-WAN

Il y a quelques jours, j’ai découvert G-WAN, un nouveau serveur web “révolutionnaire” d’après son auteur. Ce dernier annonce des performances assez hallucinantes, même face à Apache, NginX ou Lighttpd qui sont les serveurs web les plus connus.

Ce qui m’a vraiment étonné, c’est la différence de performance annoncée :

G-WAN benchmarkJ’estime maîtriser assez bien Apache ou NginX, et je m’étonne évidemment de telles différences de performances. J’ai donc décidé d’enquêter ! Continue reading “Tests approfondis de G-WAN” »

Migrating RRDTool from 32bits to 64 bits

I had a very old server on a 32 bits platform. A few days ago, I bought a new one with a 64bits platform.
I was using Smokeping on this server, and I wanted to keep my old data. If you copy .rrd files in place, you’ll get an error :

This RRD was created on another architecture

That’s because RRD file structure changed based on the architecture you have. Yes, that’s silly but this is the way it is.

To convert files, you have to dump data to an XML file, sync it on the new server, and reimport it.
This is how to make it with justa few lines of bash :

cd /path/to/rrd/files;
for i in $(find . -name '*.rrd'); do rrdtool dump $i > $i.xml ; done
rsync -av . my.server.ip:/path/to/new/dir/rrd/

And on the new server :

cd /path/to/new/dir/rrd
for i in `find . -name '*.xml'`; do rrdtool restore --force-overwrite $i `echo $i |sed s/.xml//g`; done

 

Migrating a MySQL database to another server

A customer asked me to copy a whole database from one mysql server to another.
A few years ago, I would go with the classic mysqldump + import solution, but it is very slow, especially the import part (because MySQL insert buffer is monothread). One can also use mysqlimport (LOAD DATA INFILE), but it is still quite slow… When using a standard SQL dump, I measured a speed of 1MB/sec for reimport … Quite long if you have gigabytes of data !

So I tested xtrabackup for this. This tool is already in heavy tests internally but to my mind, is not quite ready for production. But let’s try this for this specific task of migrating a database.

First, you need to install xtrabackup and all other binaries included (especially xbstream). You’ll also need at least version 5.5.25 on remote host (you’ll see why). And last but not least, InnoDB must run with

innodb_file_per_table=1

In this blog post, I’ll name “server A” the source, and “server B” the destination.
My SQL data is stored in /srv/mysql.
On server B, create a destination folder, for example /tmp/test
This is because you need to import data to a temporary directory, where there is .
On server A, launch the following command :

time innobackupex --export --databases 'mydb' --no-lock \
--stream=xbstream --tmpdir=/tmp --use-memory=128MB \
--user=backup --password=XXXXX --parallel=4 /srv/mysql \
| ssh root@10.0.0.224 "xbstream --directory=/tmp/test -x"

A few explanations :

  • –export : add specific data that would be useful for reimport
  • –databases : specify database to copy.
  • –no-lock : by default, a FLUSH TABLES WITH READ LOCK is emitted, to ensure the whole backup is consistant. I chose not to use it, as I do not care about binary log position of the backup (used in replication).
  • –stream=xbstream : use xbstream as streaming software (more powerful than tar)
  • –use-memory : memory that can be used for several tasks
  • –parallel=4 : dump 4 tables in parallel
  • I pipe stream to ssh and execute xbstream on the remote host.
  • I do not use –compress as network is not a limit in my case.

Dump is complete ! I achieved a rate of 11.3 MB/sec with this : far better than mysqldump / mysqlimport ! I’m sure we can be faster by tuning a few things.
Take care of file owner : copy was done with root, but I’m sure your mysql data is owned by someone else (or it should be !).

Then, prepare data for export :

xtrabackup_55 --prepare --export --target-dir=/tmp/test

This will “prepare” data (applying innodb log …), and especially will create .exp files that contains table metadata. This is mandatory for import in the next step !

We can see xtrabackup working :

[...]
xtrabackup: export option is specified.
xtrabackup: export metadata of table 'mydb/performer' to file `./mydb/performer.exp` (1 indexes)
xtrabackup: name=PRIMARY, id.low=443, page=3
[...]

Ok, now we need to create the new database, and import scheme.
On server B, do :

CREATE DATABASE mydb;

We also need a temporary database (you’ll see why later …)

CREATE DATABASE test;

Then, we have two choices :

  1. create all tables, discard all tablespaces, and import all
  2. do the same operation, but for each table

I first thought that there were a bug with method 1 (https://bugs.launchpad.net/percona-server/+bug/1052960) but it appears this bug is also hitting if you do method 2. Nevertheless, I’ve created a script that handle method 2 all by itself.

NOTE THAT YOU NEED Percona Server 5.5.25 v27.1 if you don’t want to hit the bug I was talking about. This bug crashes MySQL, and leaves it in a state where it cannot start again … You’ve been warned.
First, let’s dump all tables schemas. On server A, do :

mysqldump --routines --triggers --single-transaction --no-data \
--host=serverA --user=root --password=xxx \
--result-file=schemas.sql mydb;

And import it ON THE TEMPORARY DATABASE :

cat schemas.sql |mysql -uroot -hSERVER_B -p test

Execute following statement in MySQL (server B) to tell MySQL that we will import data :

SET GLOBAL innodb_import_table_from_xtrabackup = 1;
/** If you have a version < 5.5.10, despite what I just
 * said about minimum version required, query is : **/
SET GLOBAL innodb_expand_import = 1;

Then, let’s use following bash script : http://www.olivierdoucet.info/blog/wp-content/uploads/2012/09/expand_import.sh.txt

A few explanations :

For each table, we do the following :

ALTER TABLE xxx DISCARD TABLESPACE;
mv xxx.ibd xxx.exp /srv/mysql/mydb;
ALTER TABLE xxx IMPORT TABLESPACE;

This bash script is using .my.cnf file in your user dir for credentials (or other default values). Please ensure you have access to the destination database with these credentials.
ALL STEPS ARE REQUIRED. If you miss something (the set global, chown, chmod …) you’ll probably get an error (like ‘got error -1 from storage engine’). At this point, you’d better start the process over (and drop the destination database, which is incomplete).

If import works, you can see lines like this in log :

[...]
InnoDB: Import: The extended import of mydb/mytable is being started.
InnoDB: Import: 2 indexes have been detected.
InnoDB: Progress in %: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 done.
[...]

Note that when importing huge InnoDB tables, there is (was) a lock on the dictionary while scanning the ibd file (the data file), so it may lock the whole server … If operation took too long, server crashed. This is bug https://bugs.launchpad.net/percona-server/+bug/684829
This bug has been fixed since, and as you need at least version 5.5.25, you should not hit this problem.

 

Conclusion

This method is 10 times faster than mysqldump / mysqlimport. But As you can see, there are huge risks and still bugs remaining. The dump part is really safe, so I would recommend you to first test the import on a dev server before doing this in production.

Xtrabackup is really an amazing tool, but it still suffers somme nasty bugs. I’m sure I’ll use it in production in a few months, when it will be perfectly stable for all tasks.

 

XFS – Empty files after a crash

Another major bug in XFS :

After a power failure, server was back but shows some files with size 0 (when I was sure this cannot be possible).
using ‘du -sh’ on this folder shows that total size was > 0 …

The bug was already reported on XFS mailing list here :

http://oss.sgi.com/archives/xfs/2012-02/msg00517.html

If you have many files to recover, procedure is really a pain. That’s why I created a small PHP file that do the trick.

https://github.com/odoucet/xfsrepair

i’m not responsible if you destroy your data ;) But this script worked well for me.