Showing entries 1 to 10
Displaying posts with tag: storage engine (reset)
Sondage: Storage engine non officiel

Depuis quelques années, beaucoup de storages engines ont vue le jour pour répondre à des besoins que les storages engines fournis avec MySQL ne font pas bien, voir pas du tout. Selon moi, la majorité d’entre eux sont des projets qui risquent mourir dans un proche avenir. Toujours selon moi, pour que les projets gratuits et opensource demeurent longtemps, il faut qu’ils jouissent d’une certaine popularité, ce que la majorité des storages engines ne possèdent pas. De plus, ils doivent être en mesure de prouver qu’ils sont sans faille; on ne peut se permettre de perdre des données à cause d’un engine immature.

Malgré tout, je crois en un storage engine non officiel: Percona-XtraDB. Il est basé sur le populaire engine InnoDB, mais offre de meilleures performances tout en demeurant 100% compatible à ce que InnoDB peut accomplir. On peut donc remplacer …

[Lire plus]
Importation d’un CSV

On m’a soumis un problème il y a quelques semaines (désolé du délai, c’est l’été pour tout le monde hein.. ) à propos d’importation CSV qui était terriblement lente. J’ai reçu très peu d’information, donc voici des tests que j’ai effectués afin qu’il puissent être utilisés comme point de référence pour des comparaisons. Voici la problématique telle qu’on me l’a soumise

Pour un simple fichier CSV d’environ 1000 lignes (quelques Mo), j’ai largement le temps soit de manger, soit de faire une sieste, … pour une base de données MyISAM. Si j’utilise une base de données InnoDB, celle dont j’ai besoin, plus d’une journée. Je me base uniquement sur un seul utilisateur. A terme, j’aurai des To de données à gérer.

La Machine de tests:

Une VM avec 512 Mo de RAM avec un mauvais IO puisque d’autres VM roulent sur le même serveur. Voici un bout de la config que j’ai utilisé …

[Lire plus]
Truc rapide pour faire un csv avec MySQL

Je dois régulièrement créer des rapports pour la comptabilité (et d’autres gens moins à l’aise avec des ordinateurs) au boulot. Le moyen facile est de leur envoyer le tout dans un fichier CSV converti en excel par email.

Il y a plusieurs manières de créer un CSV à partir de MySQL. Voici la manière que je qualifie de “standard”:

  1. SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt'
  2. FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
  3. LINES TERMINATED BY '\n'
  4. FROM test_table;

Une manière un peu plus rapide (trouvé en fouillant sur google):

  1. mysql -umyUser-p dbName -B -e "SELECT a,b,a+b FROM test_table;" | sed 's/\t/","/g;s/^/"/;s/$/"/;s/\n//g' > filename.csv

Et maintenant.. (roulement de tambour).. “MA” manière!

  1. CREATE TABLE test_table_csv SELECT a,b,a+b FROM test_table; ALTER test_table_csv ENGINE = csv; …
[Lire plus]
MyISAM ou InnoDB ?

Un ami me demandait aujourd’hui si une application qu’il utilise à son travail pourrait être plus performante si les tables étaient Innodb plutôt que MyISAM ? Oui. Non. Peut-être. Il n’y a pas de réponse à cette question; il y beaucoup trop de facteurs à considérer.

Peter Zaitsev a publié hier un article sur le sujet. Comme il indique, il faut d’abord s’interroger pour savoir “pourquoi” les tables sont MyISAM à la base. Le sont-ils pour une raison particulière ou parce qu’elles utilisent le storage engine par défaut de MySQL ?

Les 2 storages engines possèdent des avantages différents qui les rendent aussi performant l’un que l’autre, dépendamment de l’utilisation qu’on en fait. Pour répondre adéquatement à mon ami, il aurait fallu que je connaisse quel genre de requêtes son …

[Lire plus]
Ça fait quoi un DBA ?!

Parfois, et surtout durant les fêtes, on me demande ce que je fais dans la vie. Je suis DBA, ou Administrateur de Base de Données. 95% des gens à qui je réponds ne savent pas ce que je fais. Alors, j’explique qu’est-ce qu’une base de données et le type d’application propice à en utiliser, et j’opte pour les exemples:

  • Je m’assure que la BD est performance
  • Je m’assure de l’intégrité des données
  • Je m’assure qu’il n’y aura pas de downtime
  • Je m’assure des backups

Beaucoup de gens ne comprennent toujours pas ce que je fais, mais bon, tant pis je vais pas leur donner un cours.

Tout ça me fait réfléchir sur ce que font concrètement les gens qui ont un emploi comme moi. Les 4 points que je donne en exemple ne sont souvent pas suffisants pour occuper un employé à temps plein, à 40h par semaine.

Pour ma part, mon background de …

[Lire plus]
MySQL Performance Tuning à Montréal

Je vous parlais récemment du cours MySQL Performance Tuning, et contrairement à ce que je disais, j’ai pu y  assister. J’aurais aimé que le cours parle de la configuration du serveur sur lequel se trouve MySQL, car un OS bien optimisé va évidemment offrir beaucoup de performance à MySQL. Mais étant donné que plus d’une 20aine de plateformes sont supportés, nous pourrions en discuter pendant plusieurs semaines. En fait, le cours focus principalement sur la configuration et l’utilisation qu’on en fait.

Il n’y a pas d’option magique à activer pour que MySQL performe bien. Il n’y a pas non plus d’outil statistique comme ceux d’Oracle qui permet automagiquement de comprendre la charge de travail et s’ajuster en conséquence (Notez cependant que c’est un feature prévu avec Falcon). Le Tuning avec MySQL est une question de feeling. Lorsqu’on connaît comment le serveur est fait, qu’on connaît tous les …

[Lire plus]
MySQL 5.0.67 publié

MySQL 5.0.67 était une version community qui a été releasé le 4 Août et remplace la version GA 5.0.51b. Beaucoup de bugs ont été corrigés, mais dans les plus importants à mon avis, on y retrouve :

  • L’engine FEDERATED est disablé par defaut. (Bug #37069)
  • Correction majeure à CHECK TABLE et REPAIR TABLE qui pouvait causer des pertes de données dans certaines conditions. (Bug #36055)
  • La variable connect_timeout est passée de 5 à 10 secondes par défaut. (Bug #28359)
  • Fixe de sécurité avec le ALTER VIEW qui permettait à un USER d’obtenir les droits sur la view (Bug #29908)
  • Beaucoup de corrections liées à la réplication.
  • Les …
[Lire plus]
Trouver les indexes inutiles

Arjen Lentz a écrit un article très intéressant pour trouver les indexes inutilisés. En gros, il explique la règle du 30% pour les indexes. Pour ceux qui ne la connaissent pas, les indexes ne sont pas utilisés si environs 30% des valeurs indexées sont les mêmes. Arjen propose donc une requête qui permet de trouver quel indexes sont inférieurs à 30% grâce à la cardinalité.

Mais attention! Sa technique est un peu controversée. Premièrement, il faut savoir que les 30% sont une approximation. Les indexes peuvent être utilisés si 25% ou 40% des valeurs sont pareil.

J’ai fait mes propres tests sur la base de données avec laquelle je travail au boulot et les résultats m’ont assez étonné. EXPLAIN indiquait qu’un index avec une cardinalité de 4 (la table possédait 3422 000 rows) était utilisé. C’est beaucoup plus que 30%. J’ai …

[Lire plus]
Modifier le innodb_log_file_size

Je me suis déjà fait avoir 2 fois par cette option. Si vous avez des tables InnoDB avec un gros load d’écriture (insert, update), il est généralement recommandé d’avoir un innodb_log_file_size assez élevé. Mais soyez vigilant: plus la grosseur du log file est élévée, plus le temps de recovery est long dans le cas d’un crash.

Mais peu importe. Là ou je veux en venir, c’est sur la manière de modifier cette option. InnoDB est un engine capricieux et innodb_log_file_size est l’un de ses caprices. Les logs jouent un rôle très important dans plusieurs concepts d’InnoDB. Il y stock un tas d’information comme le schema de certains .frm et d’autres metadata. Le problème est qu’on ne peut pas simplement modifier la grosseur du log dans le my.cnf et repartir le serveur. En fait oui, c’est possible et le serveur ne fera pas d’erreur. Mais aucune table InnoDB ne sera utilisable.

La manière …

[Lire plus]
ERROR 1030: Got error -1 from storage engine

J’ai été pris avec un problème qui m’a pris un petit temps (30 minutes) à trouver aujourd’hui. Le message retourné par le serveur n’aidait vraiment pas: ERROR 1030: Got error -1 from storage engine

Pour faire une histoire courte, c’étais un vieu serveur sur lequel j’avais eu des problèmes de corruption. Pour bien faire, j’avais ajouté l’option innodb_force_recovery=4 dans le my.cnf dans l’espoire que ca corrige le tout, chose qui ne s’est pas produite.

J’ai donc décidé de tout supprimer (tables, databases, fichiers temporaires, etc) et de remettre à neuf avec un dump.sql créé avec mysqldump. Le recovery allait bien jusqu’à ce que le dump tente d’insérer dans une table InnoDB: ERROR 1030: Got error -1 from storage engine.

Pas évident au premier coup d’oeil. J’ai donc googlé jusqu’à temps que je trouve un post d’un gars qui avait eu le même problème. Il …

[Lire plus]
Showing entries 1 to 10