Problème rencontré avec MySQL 5.6.4
Bonjour, je vous écris pour un petit retour d'expérience avec MySQL 5.6.4, qui est toujours en beta. J'ai configuré 2 nouveaux serveurs en slaves, comme d'habitude, dans une grappe de MySQL en 5.5.10. Le dump pour créé le slave est créé classiquement avec mysqldump, puis inséré sur les nouveaux serveurs. Dans les faits j'ai fais un dump par table, en parallèle, single-transaction, etc, mais comme on va le voir par la suite OSEF. Le setup se passe bien, puis je lance la réplication, et là ça bloque très vite : ERROR 1034 (HY000): Incorrect key file for table 'message'; try to repair it C'est une grosse table InnoDB de 10GB, 105M de rows, partitionnés par date. Etrangement, je peux quand même en faire un dump en local, puis DROP, puis réinjection du dump : même soucis. Rebelotte avec un dump/restore à base de LOAD DATA INFILE : idem. Là, je vire le partitionnement : ALTER TABLE message REMOVE PARTITIONING et ça passe. Je suis en train de les repartitionner, on va voir si ça passe mais j'ai bon espoir... La requête en question comporte une clause ISNULL() or on peut voir dans les changelogs que beaucoup de travail et de bugs concerne les champs NULL. A suivre, parce que j'ai bien l'intention de mettre ces 2 slaves en prod. -- Greg
Bonjour -- switch sur MariaDB Véro -----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Gregory Duchatelet Envoyé : jeudi 22 mars 2012 14:58 À : French SysAdmin Group Objet : [FRsAG] Problème rencontré avec MySQL 5.6.4 Bonjour, je vous écris pour un petit retour d'expérience avec MySQL 5.6.4, qui est toujours en beta. J'ai configuré 2 nouveaux serveurs en slaves, comme d'habitude, dans une grappe de MySQL en 5.5.10. Le dump pour créé le slave est créé classiquement avec mysqldump, puis inséré sur les nouveaux serveurs. Dans les faits j'ai fais un dump par table, en parallèle, single-transaction, etc, mais comme on va le voir par la suite OSEF. Le setup se passe bien, puis je lance la réplication, et là ça bloque très vite : ERROR 1034 (HY000): Incorrect key file for table 'message'; try to repair it C'est une grosse table InnoDB de 10GB, 105M de rows, partitionnés par date. Etrangement, je peux quand même en faire un dump en local, puis DROP, puis réinjection du dump : même soucis. Rebelotte avec un dump/restore à base de LOAD DATA INFILE : idem. Là, je vire le partitionnement : ALTER TABLE message REMOVE PARTITIONING et ça passe. Je suis en train de les repartitionner, on va voir si ça passe mais j'ai bon espoir... La requête en question comporte une clause ISNULL() or on peut voir dans les changelogs que beaucoup de travail et de bugs concerne les champs NULL. A suivre, parce que j'ai bien l'intention de mettre ces 2 slaves en prod. -- Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 03/22/2012 03:06 PM, Veronique Loquet wrote:
Bonjour -- switch sur MariaDB
Véro
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Gregory Duchatelet Envoyé : jeudi 22 mars 2012 14:58 À : French SysAdmin Group Objet : [FRsAG] Problème rencontré avec MySQL 5.6.4
Bonjour,
je vous écris pour un petit retour d'expérience avec MySQL 5.6.4, qui est toujours en beta. J'ai configuré 2 nouveaux serveurs en slaves, comme d'habitude, dans une grappe de MySQL en 5.5.10.
Le dump pour créé le slave est créé classiquement avec mysqldump, puis inséré sur les nouveaux serveurs. Dans les faits j'ai fais un dump par table, en parallèle, single-transaction, etc, mais comme on va le voir par la suite OSEF.
Le setup se passe bien, puis je lance la réplication, et là ça bloque très vite :
ERROR 1034 (HY000): Incorrect key file for table 'message'; try to repair it
C'est une grosse table InnoDB de 10GB, 105M de rows, partitionnés par date.
Etrangement, je peux quand même en faire un dump en local, puis DROP, puis réinjection du dump : même soucis. Rebelotte avec un dump/restore à
base de LOAD DATA INFILE : idem.
Là, je vire le partitionnement : ALTER TABLE message REMOVE PARTITIONING
et ça passe. Je suis en train de les repartitionner, on va voir si ça passe mais j'ai bon espoir...
La requête en question comporte une clause ISNULL() or on peut voir dans
les changelogs que beaucoup de travail et de bugs concerne les champs NULL.
A suivre, parce que j'ai bien l'intention de mettre ces 2 slaves en prod.
Véronique. Pour quelle raison switcher vers MariaDB ? Ce n'est pas ça qui va résoudre son problème dans l'immédiat. En plus, on n'est pas encore vendredi. Merci. -- Cyril "Davromaniak" Lavier KeyID 59E9A881 http://www.davromaniak.eu
Le 22/03/2012 14:58, Gregory Duchatelet a écrit :
Bonjour,
slurp
La requête en question comporte une clause ISNULL() or on peut voir dans les changelogs que beaucoup de travail et de bugs concerne les champs NULL.
A suivre, parce que j'ai bien l'intention de mettre ces 2 slaves en prod.
Merci pour ce petit retour, j'aime beaucoup aussi mettre des versions beta en prod ;) Je sais qu'à mon niveau pour le passage de 5.1 à 5.5 je m'étais un peu fait avoir pour la gestion des perms où % n'était plus valable pour localhost. Là mes tests de "beta en prod" sont sur PHP 5.4 qui est vraiment vraiment bon niveau perf, on va voir ce que ça va donner à l'usage.
Le jeu. 22 mars 2012 à 15:38 +0100, Boris Pigeot a ecrit :
Là mes tests de "beta en prod" sont sur PHP 5.4 qui est vraiment vraiment bon niveau perf, on va voir ce que ça va donner à l'usage.
Tu peux préciser un peu ? Tu as constaté une amélioration des perfs entre PHP 5.3 et 5.4 ? Sur quel type de code ? Je suppose que c'est du web ; quel serveur ? Quelle SAPI pour PHP ? mod_php standard ? Tu avais un cache code (APC ?) en 5.3 ? et en 5.4 ? Merci par avance, ça m'intéresse beaucoup. -- ° /\ Guillaume Allègre OpenStreetMap France /~~\/\ Allegre.Guillaume@free.fr Cartographie libre et collaborative / /~~\ tél. 04.76.63.26.99 http://www.openstreetmap.fr
Le 22/03/2012 17:33, Guillaume Allegre a écrit :
Le jeu. 22 mars 2012 à 15:38 +0100, Boris Pigeot a ecrit :
Là mes tests de "beta en prod" sont sur PHP 5.4 qui est vraiment vraiment bon niveau perf, on va voir ce que ça va donner à l'usage.
Tu peux préciser un peu ? Tu as constaté une amélioration des perfs entre PHP 5.3 et 5.4 ?
Sur quel type de code ? Je suppose que c'est du web ; quel serveur ? Quelle SAPI pour PHP ? mod_php standard ? Tu avais un cache code (APC ?) en 5.3 ? et en 5.4 ?
Merci par avance, ça m'intéresse beaucoup.
Sur du bench de base (ab) sur un phpmyadmin voilà ce que j'ai : 5.3 sans APC : 47.38 [#/sec] (mean) 5.3 avec APC : 186.14 [#/sec] (mean) 5.4 avec APC : 329.02 [#/sec] (mean) Bench : ab -n 200 -c 10 http://url/phpmyadmin/ Par contre c'est du lighttpd + php-cgi donc. Paquets dotdeb (donc très beta car ya pas tous les mods) mais pour ce serveur c'était ok.
Le Thu, Mar 22, 2012 at 05:47:02PM +0100, Boris Pigeot [ml@admin-serv.net] a écrit:
Sur du bench de base (ab) sur un phpmyadmin voilà ce que j'ai : 5.3 sans APC : 47.38 [#/sec] (mean) 5.3 avec APC : 186.14 [#/sec] (mean) 5.4 avec APC : 329.02 [#/sec] (mean)
Et le 5.4 sans APC, y'a une raison de pas l'avoir mesuré ? -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
Le 22/03/2012 18:05, Dominique Rousseau a écrit :
Le Thu, Mar 22, 2012 at 05:47:02PM +0100, Boris Pigeot [ml@admin-serv.net] a écrit:
Sur du bench de base (ab) sur un phpmyadmin voilà ce que j'ai : 5.3 sans APC : 47.38 [#/sec] (mean) 5.3 avec APC : 186.14 [#/sec] (mean) 5.4 avec APC : 329.02 [#/sec] (mean)
Et le 5.4 sans APC, y'a une raison de pas l'avoir mesuré ?
Non, mais bon, je connais plus personne qui utilise PHP sans APC donc bon, la flaime de le dégager pour bench.
Le Thu, Mar 22, 2012 at 06:19:48PM +0100, Boris Pigeot a écrit:
Sur du bench de base (ab) sur un phpmyadmin voilà ce que j'ai : 5.3 sans APC : 47.38 [#/sec] (mean) 5.3 avec APC : 186.14 [#/sec] (mean) 5.4 avec APC : 329.02 [#/sec] (mean) Et le 5.4 sans APC, y'a une raison de pas l'avoir mesuré ? Non, mais bon, je connais plus personne qui utilise PHP sans APC donc bon, la flemme de le dégager pour bench.
Et tu as testé la différence apc.stat = 0 et apc.stat = 1 ? Arnaud.
On 22/03/2012 17:33, Guillaume Allegre wrote:
Le jeu. 22 mars 2012 à 15:38 +0100, Boris Pigeot a ecrit :
Là mes tests de "beta en prod" sont sur PHP 5.4 qui est vraiment vraiment bon niveau perf, on va voir ce que ça va donner à l'usage.
Tu peux préciser un peu ? Tu as constaté une amélioration des perfs entre PHP 5.3 et 5.4 ?
Sur quel type de code ? Je suppose que c'est du web ; quel serveur ? Quelle SAPI pour PHP ? mod_php standard ? Tu avais un cache code (APC ?) en 5.3 ? et en 5.4 ?
Merci par avance, ça m'intéresse beaucoup.
Accessoirement, sur un de nos traitements en CLI, j'en ai qui donne ça : - PHP 5.3 = 2.2 secondes + 208Mo de mémoire consommée - PHP 5.4 = 0.6 secondes + 145Mo de mémoire consommée Il s'agit ici de traitements de manipulation de données (environ 1'000'000 d'items stockés dans tes tableaux).
Le 22/03/2012 14:58, Gregory Duchatelet a écrit :
La requête en question comporte une clause ISNULL() or on peut voir dans les changelogs que beaucoup de travail et de bugs concerne les champs NULL.
A suivre, parce que j'ai bien l'intention de mettre ces 2 slaves en prod.
J'arrive à reproduire le bug, voici le bug report à suivre si ça vous intéresse : http://bugs.mysql.com/bug.php?id=64742 -- Greg
participants (8)
-
Arnaud Launay -
Boris Pigeot -
Cyril Lavier -
Dominique Rousseau -
Gregory Duchatelet -
Guillaume Allegre -
Olivier Bonvalet -
Veronique Loquet