En revanche, tel ou tel logiciel peut résister plus ou moins bien à un disque qui retourne une erreur de lecture sur un secteur demandé.
Deja, quand ca arrive, c'est que ça pue sévere pour tes données.
A chaque fois que j'ai vu ce genre d'erreur, le disque est mort dans les deux semaines (avec tout ce qu'il y avait dessus).
JKB
Le Mon, 22 Nov 2010 22:57:57 +0100, Stephane CARPENTIER écrivait :
ST wrote:
On 11/22/10 6:38 PM, JKB wrote:
... Par ailleurs, on ne peut pas se permettre d'avoir des disques remplis à moins de 50% pour éviter qu'une table temporaire de MySQL ne viennent remplir l'espace restant.
Vu les prix des disques, si on peut se le permettre.
Tu gères des serveurs toi ?
Si oui, ça fout les jetons. Non, on ne peut pas se permettre d'avoir toujours 50% d'espace disque disponible parce que MySQL est un truc qui a été codé par des pieds. Et comme d'habitude, ST nous montre qu'il ne comprend rien au problème. Doubler la capacité revient grosso-modo à doubler la consommation électrique à fiabilité égale. Et là, la facture à la fin du mois n'est pas du tout la même vu le tarif de l'électricirté en centre d'hébergement. Quant à avoir plusieurs To de disponibles en permanence pour éviter des plantages, c'est, comment dire, complètement con, surtout que tu n'es pas sûr que 50% suffisent. Pourquoi ne pas avoir 80% de disponible au cas où ?
Le problème de base est que MySQL ne doit pas planter en plein milieur d'une requête sans qu'un ROLLBACK soit activé.
Sans savoir quelle est l'infrastructure qui gère les disques durs derrière ?
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 22 Nov 2010 22:57:57 +0100,
Stephane CARPENTIER <stef.carpentier@free.fr> écrivait :
ST wrote:
On 11/22/10 6:38 PM, JKB wrote:
... Par ailleurs, on ne peut pas se permettre d'avoir
des disques remplis à moins de 50% pour éviter qu'une table
temporaire de MySQL ne viennent remplir l'espace restant.
Vu les prix des disques, si on peut se le permettre.
Tu gères des serveurs toi ?
Si oui, ça fout les jetons. Non, on ne peut pas se permettre d'avoir
toujours 50% d'espace disque disponible parce que MySQL est un truc
qui a été codé par des pieds. Et comme d'habitude, ST nous montre
qu'il ne comprend rien au problème. Doubler la capacité revient
grosso-modo à doubler la consommation électrique à fiabilité égale.
Et là, la facture à la fin du mois n'est pas du tout la même vu le
tarif de l'électricirté en centre d'hébergement. Quant à avoir
plusieurs To de disponibles en permanence pour éviter des plantages,
c'est, comment dire, complètement con, surtout que tu n'es pas sûr
que 50% suffisent. Pourquoi ne pas avoir 80% de disponible au cas où ?
Le problème de base est que MySQL ne doit pas planter en plein
milieur d'une requête sans qu'un ROLLBACK soit activé.
Sans savoir quelle est l'infrastructure qui gère
les disques durs derrière ?
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 22 Nov 2010 22:57:57 +0100, Stephane CARPENTIER écrivait :
ST wrote:
On 11/22/10 6:38 PM, JKB wrote:
... Par ailleurs, on ne peut pas se permettre d'avoir des disques remplis à moins de 50% pour éviter qu'une table temporaire de MySQL ne viennent remplir l'espace restant.
Vu les prix des disques, si on peut se le permettre.
Tu gères des serveurs toi ?
Si oui, ça fout les jetons. Non, on ne peut pas se permettre d'avoir toujours 50% d'espace disque disponible parce que MySQL est un truc qui a été codé par des pieds. Et comme d'habitude, ST nous montre qu'il ne comprend rien au problème. Doubler la capacité revient grosso-modo à doubler la consommation électrique à fiabilité égale. Et là, la facture à la fin du mois n'est pas du tout la même vu le tarif de l'électricirté en centre d'hébergement. Quant à avoir plusieurs To de disponibles en permanence pour éviter des plantages, c'est, comment dire, complètement con, surtout que tu n'es pas sûr que 50% suffisent. Pourquoi ne pas avoir 80% de disponible au cas où ?
Le problème de base est que MySQL ne doit pas planter en plein milieur d'une requête sans qu'un ROLLBACK soit activé.
Sans savoir quelle est l'infrastructure qui gère les disques durs derrière ?
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Nicolas George
ST , dans le message , a écrit :
A chaque fois que j'ai vu ce genre d'erreur, le disque est mort dans les deux semaines (avec tout ce qu'il y avait dessus).
En deux semaines, il y a le temps de faire des choses, genre racheter un disque dur. Mais si le serveur de base de données met tout le cluster en vrac parce qu'il a eu un problème de lecture sur juste un secteur, ça complique les choses.
ST , dans le message <kqdrr7-our2.ln1@gulliver.unices.org>, a écrit :
A chaque fois que j'ai vu ce genre d'erreur, le disque est mort dans les
deux semaines (avec tout ce qu'il y avait dessus).
En deux semaines, il y a le temps de faire des choses, genre racheter un
disque dur. Mais si le serveur de base de données met tout le cluster en
vrac parce qu'il a eu un problème de lecture sur juste un secteur, ça
complique les choses.
A chaque fois que j'ai vu ce genre d'erreur, le disque est mort dans les deux semaines (avec tout ce qu'il y avait dessus).
En deux semaines, il y a le temps de faire des choses, genre racheter un disque dur. Mais si le serveur de base de données met tout le cluster en vrac parce qu'il a eu un problème de lecture sur juste un secteur, ça complique les choses.
ST
On 11/23/10 5:43 PM, Nicolas George wrote:
En deux semaines, il y a le temps de faire des choses, genre racheter un disque dur. Mais si le serveur de base de données met tout le cluster en vrac parce qu'il a eu un problème de lecture sur juste un secteur, ça complique les choses.
Je sais pas, mes SGBD sont tous sur des RAID avec des spares disk et un monitoring adequat. Meme si un disque meurt en 1/10 de secondes, un autre reprend immediatement (testé).
Quand on a des donnees serieuses, on prend des solutions serieuses.
On 11/23/10 5:43 PM, Nicolas George wrote:
En deux semaines, il y a le temps de faire des choses, genre racheter un
disque dur. Mais si le serveur de base de données met tout le cluster en
vrac parce qu'il a eu un problème de lecture sur juste un secteur, ça
complique les choses.
Je sais pas, mes SGBD sont tous sur des RAID avec des spares disk et un
monitoring adequat. Meme si un disque meurt en 1/10 de secondes, un
autre reprend immediatement (testé).
Quand on a des donnees serieuses, on prend des solutions serieuses.
En deux semaines, il y a le temps de faire des choses, genre racheter un disque dur. Mais si le serveur de base de données met tout le cluster en vrac parce qu'il a eu un problème de lecture sur juste un secteur, ça complique les choses.
Je sais pas, mes SGBD sont tous sur des RAID avec des spares disk et un monitoring adequat. Meme si un disque meurt en 1/10 de secondes, un autre reprend immediatement (testé).
Quand on a des donnees serieuses, on prend des solutions serieuses.
ST
On 11/23/10 4:45 PM, JKB wrote:
Si oui, ça fout les jetons. Non, on ne peut pas se permettre d'avoir toujours 50% d'espace disque disponible parce que MySQL est un truc qui a été codé par des pieds.
J'ai jamais dit qu'on pouvait se le permettre parce que MySQL etait codé avec les pieds. J'ai dit qu'on pouvait se le permettre parce que l'espace disque ne coute pas cher, ni en achat ni en energie par rapport a la taille d'une base MySQL.
Et comme d'habitude, ST nous montre qu'il ne comprend rien au problème. Doubler la capacité revient grosso-modo à doubler la consommation électrique à fiabilité égale.
Faux. La difference de consommation entre un disque de 146GB et un de 300GB n'est PAS du simple au double (c'est vrai, meme si on monte a 1To).
Et là, la facture à la fin du mois n'est pas du tout la même vu le tarif de l'électricirté en centre d'hébergement. Quant à avoir plusieurs To de disponibles en permanence pour éviter des plantages, c'est, comment dire, complètement con, surtout que tu n'es pas sûr que 50% suffisent. Pourquoi ne pas avoir 80% de disponible au cas où ?
Tu geres tes machines comme tu veux. Moi, en effet, je considere que lorsque mes disques sont a 50% en situation courante, j'ai un probleme a regler et soit je garde trop de logs (ou je les compresse pas comme il faut ou que sais je), soit je n'ai pas assez de capacite.
Le problème de base est que MySQL ne doit pas planter en plein milieur d'une requête sans qu'un ROLLBACK soit activé.
Ca c'est possible. Mais le fait est qu'un admin qui laisse les disques de ses serveurs monter a saturation est une andouille. Le simple fait que tu sous-entendes que ca t'arrive en dit long sur ton professionalisme.
On 11/23/10 4:45 PM, JKB wrote:
Si oui, ça fout les jetons. Non, on ne peut pas se permettre d'avoir
toujours 50% d'espace disque disponible parce que MySQL est un truc
qui a été codé par des pieds.
J'ai jamais dit qu'on pouvait se le permettre parce que MySQL etait codé
avec les pieds. J'ai dit qu'on pouvait se le permettre parce que
l'espace disque ne coute pas cher, ni en achat ni en energie par rapport
a la taille d'une base MySQL.
Et comme d'habitude, ST nous montre
qu'il ne comprend rien au problème. Doubler la capacité revient
grosso-modo à doubler la consommation électrique à fiabilité égale.
Faux. La difference de consommation entre un disque de 146GB et un de
300GB n'est PAS du simple au double (c'est vrai, meme si on monte a 1To).
Et là, la facture à la fin du mois n'est pas du tout la même vu le
tarif de l'électricirté en centre d'hébergement. Quant à avoir
plusieurs To de disponibles en permanence pour éviter des plantages,
c'est, comment dire, complètement con, surtout que tu n'es pas sûr
que 50% suffisent. Pourquoi ne pas avoir 80% de disponible au cas où ?
Tu geres tes machines comme tu veux. Moi, en effet, je considere que
lorsque mes disques sont a 50% en situation courante, j'ai un probleme a
regler et soit je garde trop de logs (ou je les compresse pas comme il
faut ou que sais je), soit je n'ai pas assez de capacite.
Le problème de base est que MySQL ne doit pas planter en plein
milieur d'une requête sans qu'un ROLLBACK soit activé.
Ca c'est possible. Mais le fait est qu'un admin qui laisse les disques
de ses serveurs monter a saturation est une andouille. Le simple fait
que tu sous-entendes que ca t'arrive en dit long sur ton professionalisme.
Si oui, ça fout les jetons. Non, on ne peut pas se permettre d'avoir toujours 50% d'espace disque disponible parce que MySQL est un truc qui a été codé par des pieds.
J'ai jamais dit qu'on pouvait se le permettre parce que MySQL etait codé avec les pieds. J'ai dit qu'on pouvait se le permettre parce que l'espace disque ne coute pas cher, ni en achat ni en energie par rapport a la taille d'une base MySQL.
Et comme d'habitude, ST nous montre qu'il ne comprend rien au problème. Doubler la capacité revient grosso-modo à doubler la consommation électrique à fiabilité égale.
Faux. La difference de consommation entre un disque de 146GB et un de 300GB n'est PAS du simple au double (c'est vrai, meme si on monte a 1To).
Et là, la facture à la fin du mois n'est pas du tout la même vu le tarif de l'électricirté en centre d'hébergement. Quant à avoir plusieurs To de disponibles en permanence pour éviter des plantages, c'est, comment dire, complètement con, surtout que tu n'es pas sûr que 50% suffisent. Pourquoi ne pas avoir 80% de disponible au cas où ?
Tu geres tes machines comme tu veux. Moi, en effet, je considere que lorsque mes disques sont a 50% en situation courante, j'ai un probleme a regler et soit je garde trop de logs (ou je les compresse pas comme il faut ou que sais je), soit je n'ai pas assez de capacite.
Le problème de base est que MySQL ne doit pas planter en plein milieur d'une requête sans qu'un ROLLBACK soit activé.
Ca c'est possible. Mais le fait est qu'un admin qui laisse les disques de ses serveurs monter a saturation est une andouille. Le simple fait que tu sous-entendes que ca t'arrive en dit long sur ton professionalisme.
totof01
On 22 nov, 22:57, Stephane CARPENTIER wrote:
ST wrote: > On 11/22/10 6:38 PM, JKB wrote:
> Vu les prix des disques, si on peut se le permettre.
Tu gères des serveurs toi ? Sans savoir quelle est l'infrastructure qui gère les disques durs derrière ?
:) Je connais des serveurs avec plus de 100 To (je te rassure, ce n'est pas du MySQL). S'il fa&llait près de 300 To de disque juste parce que le SGBD n'est pas capable de gérer un problème de FS plein ....
On 22 nov, 22:57, Stephane CARPENTIER <stef.carpent...@free.fr> wrote:
ST wrote:
> On 11/22/10 6:38 PM, JKB wrote:
> Vu les prix des disques, si on peut se le permettre.
Tu gères des serveurs toi ? Sans savoir quelle est l'infrastructure qui gère
les disques durs derrière ?
:) Je connais des serveurs avec plus de 100 To (je te rassure, ce
n'est pas du MySQL). S'il fa&llait près de 300 To de disque juste
parce que le SGBD n'est pas capable de gérer un problème de FS
plein ....
> Vu les prix des disques, si on peut se le permettre.
Tu gères des serveurs toi ? Sans savoir quelle est l'infrastructure qui gère les disques durs derrière ?
:) Je connais des serveurs avec plus de 100 To (je te rassure, ce n'est pas du MySQL). S'il fa&llait près de 300 To de disque juste parce que le SGBD n'est pas capable de gérer un problème de FS plein ....
ST
On 11/23/10 10:39 PM, totof01 wrote:
:) Je connais des serveurs avec plus de 100 To (je te rassure, ce n'est pas du MySQL). S'il fa&llait près de 300 To de disque juste parce que le SGBD n'est pas capable de gérer un problème de FS plein ....
Faudrait etre le roi des andouilles pour confier une base de donnees de 100 TO a un MySQL.
Bon ceci dit, je n'ai jamais travaille avec des capacites pareilles, il est clair que les problematiques sont tres differentes. Mais on est dans un cas absolument extreme qui necessite des solutions extremes.
On 11/23/10 10:39 PM, totof01 wrote:
:) Je connais des serveurs avec plus de 100 To (je te rassure, ce
n'est pas du MySQL). S'il fa&llait près de 300 To de disque juste
parce que le SGBD n'est pas capable de gérer un problème de FS
plein ....
Faudrait etre le roi des andouilles pour confier une base de donnees de
100 TO a un MySQL.
Bon ceci dit, je n'ai jamais travaille avec des capacites pareilles, il
est clair que les problematiques sont tres differentes. Mais on est dans
un cas absolument extreme qui necessite des solutions extremes.
:) Je connais des serveurs avec plus de 100 To (je te rassure, ce n'est pas du MySQL). S'il fa&llait près de 300 To de disque juste parce que le SGBD n'est pas capable de gérer un problème de FS plein ....
Faudrait etre le roi des andouilles pour confier une base de donnees de 100 TO a un MySQL.
Bon ceci dit, je n'ai jamais travaille avec des capacites pareilles, il est clair que les problematiques sont tres differentes. Mais on est dans un cas absolument extreme qui necessite des solutions extremes.
Tonton Th
On 11/23/2010 03:39 PM, totof01 wrote:
Vu les prix des disques, si on peut se le permettre.
Tu gères des serveurs toi ? Sans savoir quelle est l'infrastructure qui gère les disques durs derrière ?
:) Je connais des serveurs avec plus de 100 To (je te rassure, ce n'est pas du MySQL). S'il fa&llait près de 300 To de disque juste parce que le SGBD n'est pas capable de gérer un problème de FS plein ....
Dans le cas d'une bédédé bien conçue, utilisée pas des applications raisonnables, il est certainement possible d'estimer (à la louche, ou par la méthode de la rache) la taille d'espace libre qu'il est _nécessaire_ de garder sous le coude pour passer les caps difficiles.
Bien sur, dans certains cas (eg: hébergement mutualisé), c'est beaucoup plus difficile...
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 11/23/2010 03:39 PM, totof01 wrote:
Vu les prix des disques, si on peut se le permettre.
Tu gères des serveurs toi ? Sans savoir quelle est l'infrastructure qui gère
les disques durs derrière ?
:) Je connais des serveurs avec plus de 100 To (je te rassure, ce
n'est pas du MySQL). S'il fa&llait près de 300 To de disque juste
parce que le SGBD n'est pas capable de gérer un problème de FS
plein ....
Dans le cas d'une bédédé bien conçue, utilisée pas des
applications raisonnables, il est certainement possible
d'estimer (à la louche, ou par la méthode de la rache)
la taille d'espace libre qu'il est _nécessaire_ de garder
sous le coude pour passer les caps difficiles.
Bien sur, dans certains cas (eg: hébergement mutualisé),
c'est beaucoup plus difficile...
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
Vu les prix des disques, si on peut se le permettre.
Tu gères des serveurs toi ? Sans savoir quelle est l'infrastructure qui gère les disques durs derrière ?
:) Je connais des serveurs avec plus de 100 To (je te rassure, ce n'est pas du MySQL). S'il fa&llait près de 300 To de disque juste parce que le SGBD n'est pas capable de gérer un problème de FS plein ....
Dans le cas d'une bédédé bien conçue, utilisée pas des applications raisonnables, il est certainement possible d'estimer (à la louche, ou par la méthode de la rache) la taille d'espace libre qu'il est _nécessaire_ de garder sous le coude pour passer les caps difficiles.
Bien sur, dans certains cas (eg: hébergement mutualisé), c'est beaucoup plus difficile...
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
Tonton Th
On 11/23/2010 03:48 PM, ST wrote:
:) Je connais des serveurs avec plus de 100 To (je te rassure, ce n'est pas du MySQL). S'il fa&llait près de 300 To de disque juste parce que le SGBD n'est pas capable de gérer un problème de FS plein ....
Faudrait etre le roi des andouilles pour confier une base de donnees de 100 TO a un MySQL.
http://meta.wikimedia.org/wiki/Wikimedia_servers mais je ne suis pas arrivé à trouver la taille des bédédés.
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 11/23/2010 03:48 PM, ST wrote:
:) Je connais des serveurs avec plus de 100 To (je te rassure, ce
n'est pas du MySQL). S'il fa&llait près de 300 To de disque juste
parce que le SGBD n'est pas capable de gérer un problème de FS
plein ....
Faudrait etre le roi des andouilles pour confier une base de donnees de
100 TO a un MySQL.
http://meta.wikimedia.org/wiki/Wikimedia_servers mais je ne suis
pas arrivé à trouver la taille des bédédés.
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
:) Je connais des serveurs avec plus de 100 To (je te rassure, ce n'est pas du MySQL). S'il fa&llait près de 300 To de disque juste parce que le SGBD n'est pas capable de gérer un problème de FS plein ....
Faudrait etre le roi des andouilles pour confier une base de donnees de 100 TO a un MySQL.
http://meta.wikimedia.org/wiki/Wikimedia_servers mais je ne suis pas arrivé à trouver la taille des bédédés.
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
Baton Rouge
On Tue, 23 Nov 2010 08:17:55 +0800, ST wrote:
On 11/23/10 12:38 AM, Nicolas George wrote:
En revanche, tel ou tel logiciel peut résister plus ou moins bien à un disque qui retourne une erreur de lecture sur un secteur demandé.
Deja, quand ca arrive, c'est que ça pue sévere pour tes données.
A chaque fois que j'ai vu ce genre d'erreur, le disque est mort dans les deux semaines (avec tout ce qu'il y avait dessus).
Pas toujours J'en ai 2 qui tournent depuis 3 et 5 ans sur de vieille machine. Le jour où il claquent, je remplace par un autre.
J'ai pas eu d'autre choix que de les passer au LLF avec le logiciel du constructeur.
-- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
On Tue, 23 Nov 2010 08:17:55 +0800, ST <st@unices.org> wrote:
On 11/23/10 12:38 AM, Nicolas George wrote:
En revanche, tel ou tel logiciel peut résister plus ou moins bien à un
disque qui retourne une erreur de lecture sur un secteur demandé.
Deja, quand ca arrive, c'est que ça pue sévere pour tes données.
A chaque fois que j'ai vu ce genre d'erreur, le disque est mort dans les
deux semaines (avec tout ce qu'il y avait dessus).
Pas toujours
J'en ai 2 qui tournent depuis 3 et 5 ans sur de vieille machine. Le
jour où il claquent, je remplace par un autre.
J'ai pas eu d'autre choix que de les passer au LLF avec le logiciel du
constructeur.
--
Travailler plus pour gagner plus pour quoi faire ?
Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
En revanche, tel ou tel logiciel peut résister plus ou moins bien à un disque qui retourne une erreur de lecture sur un secteur demandé.
Deja, quand ca arrive, c'est que ça pue sévere pour tes données.
A chaque fois que j'ai vu ce genre d'erreur, le disque est mort dans les deux semaines (avec tout ce qu'il y avait dessus).
Pas toujours J'en ai 2 qui tournent depuis 3 et 5 ans sur de vieille machine. Le jour où il claquent, je remplace par un autre.
J'ai pas eu d'autre choix que de les passer au LLF avec le logiciel du constructeur.
-- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
