Je le sais aussi. Et je dis que si tu dis ça, ce n'est pas parce que c'est stupide, mais parce que tu ne comprends pas les raisons des autres.
Parce que si on vient ici, c'est bien pour se bouffer du con,
Pas forcément.
Absolument. Si je lis fcold, c'est pour étendre ma culture informatique. Je ne suis pas du métier, et j'ai appris un tas de trucs ici, le dernier en date étant l'existence de sshfs. Dont je me sers régulièrement depuis.
J'aurais pu trouver l'info ailleurs, mais encore aurait-il fallu qu'il me vienne à l'idée de chercher. Au détour d'un fil, il y a parfois des pépites.
Donc si on pouvait amélirer le rapport signal/bruit, je ne serais pas contre. Mais je n'utilise pas de killfile, essentiellement parce que ça donne des fils hachés qui sont finalement plus pénibles que la version complète qu'on peut zapper rapidement à grands coups de touche 'n'.
-- Olivier -- "On est comme tous les artistes, on croit à notre produit." -+-groupe Début de Soirée-+-
Stephane CARPENTIER écrivait :
Je le sais aussi. Et je dis que si tu dis ça, ce n'est pas parce que c'est
stupide, mais parce que tu ne comprends pas les raisons des autres.
Parce que si on vient ici, c'est bien pour se bouffer du con,
Pas forcément.
Absolument. Si je lis fcold, c'est pour étendre ma culture informatique.
Je ne suis pas du métier, et j'ai appris un tas de trucs ici, le dernier
en date étant l'existence de sshfs. Dont je me sers régulièrement
depuis.
J'aurais pu trouver l'info ailleurs, mais encore aurait-il fallu qu'il
me vienne à l'idée de chercher. Au détour d'un fil, il y a parfois des
pépites.
Donc si on pouvait amélirer le rapport signal/bruit, je ne serais pas
contre. Mais je n'utilise pas de killfile, essentiellement parce que ça
donne des fils hachés qui sont finalement plus pénibles que la version
complète qu'on peut zapper rapidement à grands coups de touche 'n'.
--
Olivier -- "On est comme tous les artistes, on croit à notre produit."
-+-groupe Début de Soirée-+-
Je le sais aussi. Et je dis que si tu dis ça, ce n'est pas parce que c'est stupide, mais parce que tu ne comprends pas les raisons des autres.
Parce que si on vient ici, c'est bien pour se bouffer du con,
Pas forcément.
Absolument. Si je lis fcold, c'est pour étendre ma culture informatique. Je ne suis pas du métier, et j'ai appris un tas de trucs ici, le dernier en date étant l'existence de sshfs. Dont je me sers régulièrement depuis.
J'aurais pu trouver l'info ailleurs, mais encore aurait-il fallu qu'il me vienne à l'idée de chercher. Au détour d'un fil, il y a parfois des pépites.
Donc si on pouvait amélirer le rapport signal/bruit, je ne serais pas contre. Mais je n'utilise pas de killfile, essentiellement parce que ça donne des fils hachés qui sont finalement plus pénibles que la version complète qu'on peut zapper rapidement à grands coups de touche 'n'.
-- Olivier -- "On est comme tous les artistes, on croit à notre produit." -+-groupe Début de Soirée-+-
Dellara
olive a papoté sur Usenet le novembre 21, 2010 11:16 AM:
Donc si on pouvait amélirer le rapport signal/bruit, je ne serais pas contre. Mais je n'utilise pas de killfile, essentiellement parce que ça donne des fils hachés qui sont finalement plus pénibles que la version complète qu'on peut zapper rapidement à grands coups de touche 'n'.
Ça c'est possible parce que tu utilises slrn, un lecteur de news connu comme étant imbittable et d'un autre âge. Pour être à la page, il faut utiliser KNode avec KDE4.x :)
olive a papoté sur Usenet le novembre 21, 2010 11:16 AM:
Donc si on pouvait amélirer le rapport signal/bruit, je ne serais pas
contre. Mais je n'utilise pas de killfile, essentiellement parce que
ça donne des fils hachés qui sont finalement plus pénibles que la
version complète qu'on peut zapper rapidement à grands coups de touche
'n'.
Ça c'est possible parce que tu utilises slrn, un lecteur de news connu
comme étant imbittable et d'un autre âge. Pour être à la page, il faut
utiliser KNode avec KDE4.x :)
olive a papoté sur Usenet le novembre 21, 2010 11:16 AM:
Donc si on pouvait amélirer le rapport signal/bruit, je ne serais pas contre. Mais je n'utilise pas de killfile, essentiellement parce que ça donne des fils hachés qui sont finalement plus pénibles que la version complète qu'on peut zapper rapidement à grands coups de touche 'n'.
Ça c'est possible parce que tu utilises slrn, un lecteur de news connu comme étant imbittable et d'un autre âge. Pour être à la page, il faut utiliser KNode avec KDE4.x :)
olive
Dellara écrivait :
Ça c'est possible parce que tu utilises slrn, un lecteur de news connu comme étant imbittable et d'un autre âge. Pour être à la page, il faut utiliser KNode avec KDE4.x :)
Ah, je vois qu'on raffine le troll. Avec ton Knode, tu peux lire les news à distance sans mettre en place une usine à gaz ?
-- Olivier -- "On est comme tous les artistes, on croit à notre produit." -+-groupe Début de Soirée-+-
Dellara écrivait :
Ça c'est possible parce que tu utilises slrn, un lecteur de news connu
comme étant imbittable et d'un autre âge. Pour être à la page, il faut
utiliser KNode avec KDE4.x :)
Ah, je vois qu'on raffine le troll. Avec ton Knode, tu peux lire les
news à distance sans mettre en place une usine à gaz ?
--
Olivier -- "On est comme tous les artistes, on croit à notre produit."
-+-groupe Début de Soirée-+-
Ça c'est possible parce que tu utilises slrn, un lecteur de news connu comme étant imbittable et d'un autre âge. Pour être à la page, il faut utiliser KNode avec KDE4.x :)
Ah, je vois qu'on raffine le troll. Avec ton Knode, tu peux lire les news à distance sans mettre en place une usine à gaz ?
-- Olivier -- "On est comme tous les artistes, on croit à notre produit." -+-groupe Début de Soirée-+-
Dellara
olive a papoté sur Usenet le novembre 21, 2010 03:24 PM:
Ça c'est possible parce que tu utilises slrn, un lecteur de news connu comme étant imbittable et d'un autre âge. Pour être à la page, il faut utiliser KNode avec KDE4.x :)
Ah, je vois qu'on raffine le troll. Avec ton Knode, tu peux lire les news à distance sans mettre en place une usine à gaz ?
Ah ben non! Il faut utiliser l'usine à gaz qu'on lui a vendu à force marketing et publicité. Alors se conter d'un ersatz de lecteur de news, faut rouler avec un 386 et 4 megs de mémoire :) Donc je peux lire les news à distance et faire travailler mon usine à gaz.
olive a papoté sur Usenet le novembre 21, 2010 03:24 PM:
Ça c'est possible parce que tu utilises slrn, un lecteur de news
connu comme étant imbittable et d'un autre âge. Pour être à la page,
il faut utiliser KNode avec KDE4.x :)
Ah, je vois qu'on raffine le troll. Avec ton Knode, tu peux lire les
news à distance sans mettre en place une usine à gaz ?
Ah ben non! Il faut utiliser l'usine à gaz qu'on lui a vendu à force
marketing et publicité. Alors se conter d'un ersatz de lecteur de news,
faut rouler avec un 386 et 4 megs de mémoire :) Donc je peux lire les
news à distance et faire travailler mon usine à gaz.
olive a papoté sur Usenet le novembre 21, 2010 03:24 PM:
Ça c'est possible parce que tu utilises slrn, un lecteur de news connu comme étant imbittable et d'un autre âge. Pour être à la page, il faut utiliser KNode avec KDE4.x :)
Ah, je vois qu'on raffine le troll. Avec ton Knode, tu peux lire les news à distance sans mettre en place une usine à gaz ?
Ah ben non! Il faut utiliser l'usine à gaz qu'on lui a vendu à force marketing et publicité. Alors se conter d'un ersatz de lecteur de news, faut rouler avec un 386 et 4 megs de mémoire :) Donc je peux lire les news à distance et faire travailler mon usine à gaz.
Hugues
ST a suggéré :
On 11/19/10 7:18 PM, Hugues wrote:
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque arrive en saturation ou qu'il y a une erreur d'accès mal placé ou n'importe quoi d'autre, le journal explose en vol et on perd _tout_.
Ben oui, mais si tu geres tes machines comme un goret aussi.
Je suis curieux, tu pourrais être plus explicite stp ? J'aimerais bien apprendre à gérer mes machines proprement, comme tu sais faire.
Ben tu te mets un Nagios avec un seuil d'alerte assez bas sur le taux de remplissage des disques et tu laisses JAMAIS un disque de SGDB arriver a saturation parce que tu sais que si ca arrive, ca peut avoir des consequences plutot ... nefaste (MySQL ou pas).
Ok, merci.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
ST <st@unices.org> a suggéré :
On 11/19/10 7:18 PM, Hugues wrote:
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque arrive en
saturation ou qu'il y a une erreur d'accès mal placé ou n'importe
quoi d'autre, le journal explose en vol et on perd _tout_.
Ben oui, mais si tu geres tes machines comme un goret aussi.
Je suis curieux, tu pourrais être plus explicite stp ?
J'aimerais bien apprendre à gérer mes machines proprement, comme tu sais faire.
Ben tu te mets un Nagios avec un seuil d'alerte assez bas sur le taux
de remplissage des disques et tu laisses JAMAIS un disque de SGDB
arriver a saturation parce que tu sais que si ca arrive, ca peut avoir
des consequences plutot ... nefaste (MySQL ou pas).
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque arrive en saturation ou qu'il y a une erreur d'accès mal placé ou n'importe quoi d'autre, le journal explose en vol et on perd _tout_.
Ben oui, mais si tu geres tes machines comme un goret aussi.
Je suis curieux, tu pourrais être plus explicite stp ? J'aimerais bien apprendre à gérer mes machines proprement, comme tu sais faire.
Ben tu te mets un Nagios avec un seuil d'alerte assez bas sur le taux de remplissage des disques et tu laisses JAMAIS un disque de SGDB arriver a saturation parce que tu sais que si ca arrive, ca peut avoir des consequences plutot ... nefaste (MySQL ou pas).
Ok, merci.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
JKB
Le Mon, 22 Nov 2010 11:25:10 +0100, Hugues écrivait :
ST a suggéré :
On 11/19/10 7:18 PM, Hugues wrote:
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque arrive en saturation ou qu'il y a une erreur d'accès mal placé ou n'importe quoi d'autre, le journal explose en vol et on perd _tout_.
Ben oui, mais si tu geres tes machines comme un goret aussi.
Je suis curieux, tu pourrais être plus explicite stp ? J'aimerais bien apprendre à gérer mes machines proprement, comme tu sais faire.
Ben tu te mets un Nagios avec un seuil d'alerte assez bas sur le taux de remplissage des disques et tu laisses JAMAIS un disque de SGDB arriver a saturation parce que tu sais que si ca arrive, ca peut avoir des consequences plutot ... nefaste (MySQL ou pas).
Ok, merci.
Sauf que tu n'es _jamais_ à l'abri d'un disque qui explose pour une raison ou pour une autre, nagios ou pas. Il ne faut jamais désespérer de ce que peut faire un utilisateur qui _doit_ avoir un accès en écriture (voire qui lance des requêtes sur des tables temporaires assez grosses qui bouffent quelques dizaines de Go de disque).
Nagios est juste un cataplasme sur une jambe de bois, il ne règle absolument pas les causes du problème. Si un postgres ne peut plus écrire un enregistrement, il remonte une erreur _et_ un rollback. MySQL s'arrête simplement et laisse les choses en vrac. Là où ça peut devenir marrant, c'est avec un MySQL sur VMS lorsque la couche RMS t'insulte sur des histoires de quota (à mon avis, la même chose arrive sous Linux avec les quotas activés, mais je n'ai pas eu l'occasion de tester).
Tout ça pour dire qu'une base de données, quelle que soit cette base doit planter proprement pour que l'état reste cohérent. Ce n'est pas le cas de MySQL. 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.
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 11:25:10 +0100,
Hugues <hugues@hiegel.fr> écrivait :
ST <st@unices.org> a suggéré :
On 11/19/10 7:18 PM, Hugues wrote:
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque arrive en
saturation ou qu'il y a une erreur d'accès mal placé ou n'importe
quoi d'autre, le journal explose en vol et on perd _tout_.
Ben oui, mais si tu geres tes machines comme un goret aussi.
Je suis curieux, tu pourrais être plus explicite stp ?
J'aimerais bien apprendre à gérer mes machines proprement, comme tu sais faire.
Ben tu te mets un Nagios avec un seuil d'alerte assez bas sur le taux
de remplissage des disques et tu laisses JAMAIS un disque de SGDB
arriver a saturation parce que tu sais que si ca arrive, ca peut avoir
des consequences plutot ... nefaste (MySQL ou pas).
Ok, merci.
Sauf que tu n'es _jamais_ à l'abri d'un disque qui explose pour une
raison ou pour une autre, nagios ou pas. Il ne faut jamais
désespérer de ce que peut faire un utilisateur qui _doit_ avoir un
accès en écriture (voire qui lance des requêtes sur des tables
temporaires assez grosses qui bouffent quelques dizaines de Go de
disque).
Nagios est juste un cataplasme sur une jambe de bois, il ne règle
absolument pas les causes du problème. Si un postgres ne peut plus
écrire un enregistrement, il remonte une erreur _et_ un rollback.
MySQL s'arrête simplement et laisse les choses en vrac. Là où ça
peut devenir marrant, c'est avec un MySQL sur VMS lorsque la couche
RMS t'insulte sur des histoires de quota (à mon avis, la même chose
arrive sous Linux avec les quotas activés, mais je n'ai pas eu
l'occasion de tester).
Tout ça pour dire qu'une base de données, quelle que soit cette base
doit planter proprement pour que l'état reste cohérent. Ce n'est pas
le cas de MySQL. 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.
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 11:25:10 +0100, Hugues écrivait :
ST a suggéré :
On 11/19/10 7:18 PM, Hugues wrote:
Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disque arrive en saturation ou qu'il y a une erreur d'accès mal placé ou n'importe quoi d'autre, le journal explose en vol et on perd _tout_.
Ben oui, mais si tu geres tes machines comme un goret aussi.
Je suis curieux, tu pourrais être plus explicite stp ? J'aimerais bien apprendre à gérer mes machines proprement, comme tu sais faire.
Ben tu te mets un Nagios avec un seuil d'alerte assez bas sur le taux de remplissage des disques et tu laisses JAMAIS un disque de SGDB arriver a saturation parce que tu sais que si ca arrive, ca peut avoir des consequences plutot ... nefaste (MySQL ou pas).
Ok, merci.
Sauf que tu n'es _jamais_ à l'abri d'un disque qui explose pour une raison ou pour une autre, nagios ou pas. Il ne faut jamais désespérer de ce que peut faire un utilisateur qui _doit_ avoir un accès en écriture (voire qui lance des requêtes sur des tables temporaires assez grosses qui bouffent quelques dizaines de Go de disque).
Nagios est juste un cataplasme sur une jambe de bois, il ne règle absolument pas les causes du problème. Si un postgres ne peut plus écrire un enregistrement, il remonte une erreur _et_ un rollback. MySQL s'arrête simplement et laisse les choses en vrac. Là où ça peut devenir marrant, c'est avec un MySQL sur VMS lorsque la couche RMS t'insulte sur des histoires de quota (à mon avis, la même chose arrive sous Linux avec les quotas activés, mais je n'ai pas eu l'occasion de tester).
Tout ça pour dire qu'une base de données, quelle que soit cette base doit planter proprement pour que l'état reste cohérent. Ce n'est pas le cas de MySQL. 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.
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
ST
On 11/22/10 6:38 PM, JKB wrote:
Sauf que tu n'es _jamais_ à l'abri d'un disque qui explose pour une raison ou pour une autre, nagios ou pas ...
Je vois pas trop comment un MySQL peut resister a un disque qui explose (note que je n'ai jamais vu un disque "exploser"). Je ne pense que Oracle ou PostgreSQL, ni meme Linux en fait, pourrait resister mieux a un disque qui "explose".
A noter qu'on est passé d'un disque "saturé" (parce que l'admin est une andouille qui ne sait pas monitorer ses serveurs) à un disque qui "explose" (peut etre l'admin a-t-il des ennemis au moyen Orient).
... 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.
On 11/22/10 6:38 PM, JKB wrote:
Sauf que tu n'es _jamais_ à l'abri d'un disque qui explose pour une
raison ou pour une autre, nagios ou pas ...
Je vois pas trop comment un MySQL peut resister a un disque qui explose
(note que je n'ai jamais vu un disque "exploser"). Je ne pense que
Oracle ou PostgreSQL, ni meme Linux en fait, pourrait resister mieux a
un disque qui "explose".
A noter qu'on est passé d'un disque "saturé" (parce que l'admin est une
andouille qui ne sait pas monitorer ses serveurs) à un disque qui
"explose" (peut etre l'admin a-t-il des ennemis au moyen Orient).
... 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.
Sauf que tu n'es _jamais_ à l'abri d'un disque qui explose pour une raison ou pour une autre, nagios ou pas ...
Je vois pas trop comment un MySQL peut resister a un disque qui explose (note que je n'ai jamais vu un disque "exploser"). Je ne pense que Oracle ou PostgreSQL, ni meme Linux en fait, pourrait resister mieux a un disque qui "explose".
A noter qu'on est passé d'un disque "saturé" (parce que l'admin est une andouille qui ne sait pas monitorer ses serveurs) à un disque qui "explose" (peut etre l'admin a-t-il des ennemis au moyen Orient).
... 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.
Hugues
JKB a suggéré :
Le Mon, 22 Nov 2010 11:25:10 +0100, Hugues écrivait :
ST a suggéré :
Ben tu te mets un Nagios avec un seuil d'alerte assez bas sur le taux de remplissage des disques et tu laisses JAMAIS un disque de SGDB arriver a saturation parce que tu sais que si ca arrive, ca peut avoir des consequences plutot ... nefaste (MySQL ou pas).
Ok, merci.
Sauf que tu n'es _jamais_ à l'abri d'un disque qui explose pour une raison ou pour une autre, nagios ou pas. Il ne faut jamais désespérer de ce que peut faire un utilisateur qui _doit_ avoir un accès en écriture (voire qui lance des requêtes sur des tables temporaires assez grosses qui bouffent quelques dizaines de Go de disque).
Nagios est juste un cataplasme sur une jambe de bois, il ne règle absolument pas les causes du problème. Si un postgres ne peut plus écrire un enregistrement, il remonte une erreur _et_ un rollback. MySQL s'arrête simplement et laisse les choses en vrac. Là où ça peut devenir marrant, c'est avec un MySQL sur VMS lorsque la couche RMS t'insulte sur des histoires de quota (à mon avis, la même chose arrive sous Linux avec les quotas activés, mais je n'ai pas eu l'occasion de tester).
Tout ça pour dire qu'une base de données, quelle que soit cette base doit planter proprement pour que l'état reste cohérent. Ce n'est pas le cas de MySQL. 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.
Tu prêches un converti :) Je suis d'accord sur le principe qu'une erreur doit être gérée à la source, et non être prévenue à des endroits qui n'ont rien à y faire :
- un disque est fait pour être rempli. Quand il atteint saturation, ce n'est pas son problème, il va juste se contenter d'informer qui le lui demande.
- une application qui a besoin de place pour écrire des infos, c'est son problème à elle de s'assurer qu'elle en aura, et c'est son problème à elle de gérer le cas où il n'y a plus de place.
Qu'une appli plante et laisse le boxon parce qu'elle a tenté de dumper 1Go de données sur un lecteur de disquettes d'1,44Mo, ce n'est pas normal. Un watchdog n'y résoudra rien.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
JKB <jkb@koenigsberg.invalid> a suggéré :
Le Mon, 22 Nov 2010 11:25:10 +0100,
Hugues <hugues@hiegel.fr> écrivait :
ST <st@unices.org> a suggéré :
Ben tu te mets un Nagios avec un seuil d'alerte assez bas sur le taux
de remplissage des disques et tu laisses JAMAIS un disque de SGDB
arriver a saturation parce que tu sais que si ca arrive, ca peut avoir
des consequences plutot ... nefaste (MySQL ou pas).
Ok, merci.
Sauf que tu n'es _jamais_ à l'abri d'un disque qui explose pour une
raison ou pour une autre, nagios ou pas. Il ne faut jamais
désespérer de ce que peut faire un utilisateur qui _doit_ avoir un
accès en écriture (voire qui lance des requêtes sur des tables
temporaires assez grosses qui bouffent quelques dizaines de Go de
disque).
Nagios est juste un cataplasme sur une jambe de bois, il ne règle
absolument pas les causes du problème. Si un postgres ne peut plus
écrire un enregistrement, il remonte une erreur _et_ un rollback.
MySQL s'arrête simplement et laisse les choses en vrac. Là où ça
peut devenir marrant, c'est avec un MySQL sur VMS lorsque la couche
RMS t'insulte sur des histoires de quota (à mon avis, la même chose
arrive sous Linux avec les quotas activés, mais je n'ai pas eu
l'occasion de tester).
Tout ça pour dire qu'une base de données, quelle que soit cette base
doit planter proprement pour que l'état reste cohérent. Ce n'est pas
le cas de MySQL. 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.
Tu prêches un converti :)
Je suis d'accord sur le principe qu'une erreur doit être gérée à la
source, et non être prévenue à des endroits qui n'ont rien à y faire :
- un disque est fait pour être rempli. Quand il atteint saturation, ce
n'est pas son problème, il va juste se contenter d'informer qui le lui
demande.
- une application qui a besoin de place pour écrire des infos, c'est son
problème à elle de s'assurer qu'elle en aura, et c'est son problème à
elle de gérer le cas où il n'y a plus de place.
Qu'une appli plante et laisse le boxon parce qu'elle a tenté de dumper
1Go de données sur un lecteur de disquettes d'1,44Mo, ce n'est pas
normal. Un watchdog n'y résoudra rien.
Le Mon, 22 Nov 2010 11:25:10 +0100, Hugues écrivait :
ST a suggéré :
Ben tu te mets un Nagios avec un seuil d'alerte assez bas sur le taux de remplissage des disques et tu laisses JAMAIS un disque de SGDB arriver a saturation parce que tu sais que si ca arrive, ca peut avoir des consequences plutot ... nefaste (MySQL ou pas).
Ok, merci.
Sauf que tu n'es _jamais_ à l'abri d'un disque qui explose pour une raison ou pour une autre, nagios ou pas. Il ne faut jamais désespérer de ce que peut faire un utilisateur qui _doit_ avoir un accès en écriture (voire qui lance des requêtes sur des tables temporaires assez grosses qui bouffent quelques dizaines de Go de disque).
Nagios est juste un cataplasme sur une jambe de bois, il ne règle absolument pas les causes du problème. Si un postgres ne peut plus écrire un enregistrement, il remonte une erreur _et_ un rollback. MySQL s'arrête simplement et laisse les choses en vrac. Là où ça peut devenir marrant, c'est avec un MySQL sur VMS lorsque la couche RMS t'insulte sur des histoires de quota (à mon avis, la même chose arrive sous Linux avec les quotas activés, mais je n'ai pas eu l'occasion de tester).
Tout ça pour dire qu'une base de données, quelle que soit cette base doit planter proprement pour que l'état reste cohérent. Ce n'est pas le cas de MySQL. 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.
Tu prêches un converti :) Je suis d'accord sur le principe qu'une erreur doit être gérée à la source, et non être prévenue à des endroits qui n'ont rien à y faire :
- un disque est fait pour être rempli. Quand il atteint saturation, ce n'est pas son problème, il va juste se contenter d'informer qui le lui demande.
- une application qui a besoin de place pour écrire des infos, c'est son problème à elle de s'assurer qu'elle en aura, et c'est son problème à elle de gérer le cas où il n'y a plus de place.
Qu'une appli plante et laisse le boxon parce qu'elle a tenté de dumper 1Go de données sur un lecteur de disquettes d'1,44Mo, ce n'est pas normal. Un watchdog n'y résoudra rien.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Nicolas George
ST , dans le message , a écrit :
Je vois pas trop comment un MySQL peut resister a un disque qui explose (note que je n'ai jamais vu un disque "exploser"). Je ne pense que Oracle ou PostgreSQL, ni meme Linux en fait, pourrait resister mieux a un disque qui "explose".
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é.
ST , dans le message <5t9qr7-pqp.ln1@gulliver.unices.org>, a écrit :
Je vois pas trop comment un MySQL peut resister a un disque qui explose
(note que je n'ai jamais vu un disque "exploser"). Je ne pense que
Oracle ou PostgreSQL, ni meme Linux en fait, pourrait resister mieux a
un disque qui "explose".
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é.
Je vois pas trop comment un MySQL peut resister a un disque qui explose (note que je n'ai jamais vu un disque "exploser"). Je ne pense que Oracle ou PostgreSQL, ni meme Linux en fait, pourrait resister mieux a un disque qui "explose".
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é.
