Il faut payer maintenant pour être d'accord sur fcold ?-)
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
Doug713705
Le 18/11/2010 16:49 dans fr.comp.os.linux.debats ST nous expliquait:
Moi, j'applaudis des deux mains. C'est la meilleure chose qui puisse arriver puisqu'au final, on remplacera MySQL par MariaDB (il faut lire la genèse de MariaDB et pourquoi le développeur principal de MySQL a décidé de 'forker' son projet, entre autres en raison des bugs de l'engin...) et qu'on verra peut-être enfin quelque chose de meilleur que Java arriver.
Tiens, je suis globalement d'accord avec le JKB. Pas dans le detail, bien sur, mais dans l'idee generale : oui !
Aller jusque sur fcold pour obtenir un consensus... Usenet is _really_ dying.
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) Usenet-fr ? Mais qu'est-ce que c'est ? Comment ça marche ? Pour en savoir plus : http://usenet-fr.dougwise.org/
Le 18/11/2010 16:49 dans fr.comp.os.linux.debats ST nous expliquait:
Moi, j'applaudis des deux mains. C'est la meilleure chose qui puisse
arriver puisqu'au final, on remplacera MySQL par MariaDB (il faut
lire la genèse de MariaDB et pourquoi le développeur principal de
MySQL a décidé de 'forker' son projet, entre autres en raison des
bugs de l'engin...) et qu'on verra peut-être enfin quelque chose de
meilleur que Java arriver.
Tiens, je suis globalement d'accord avec le JKB. Pas dans le detail,
bien sur, mais dans l'idee generale : oui !
Aller jusque sur fcold pour obtenir un consensus... Usenet is _really_
dying.
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Usenet-fr ? Mais qu'est-ce que c'est ? Comment ça marche ?
Pour en savoir plus : http://usenet-fr.dougwise.org/
Le 18/11/2010 16:49 dans fr.comp.os.linux.debats ST nous expliquait:
Moi, j'applaudis des deux mains. C'est la meilleure chose qui puisse arriver puisqu'au final, on remplacera MySQL par MariaDB (il faut lire la genèse de MariaDB et pourquoi le développeur principal de MySQL a décidé de 'forker' son projet, entre autres en raison des bugs de l'engin...) et qu'on verra peut-être enfin quelque chose de meilleur que Java arriver.
Tiens, je suis globalement d'accord avec le JKB. Pas dans le detail, bien sur, mais dans l'idee generale : oui !
Aller jusque sur fcold pour obtenir un consensus... Usenet is _really_ dying.
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) Usenet-fr ? Mais qu'est-ce que c'est ? Comment ça marche ? Pour en savoir plus : http://usenet-fr.dougwise.org/
ST
On 11/17/10 10:52 PM, JKB wrote:
C'est difficile, NG est dans ma boitakhon.
Et alors, c'est une raison pour nous en imposer les consequences. Si il est dans ta boitakon, tu lui reponds, meme pas par intermediaire. Ca nous epargneras tes interventions pathetiques.
On 11/17/10 10:52 PM, JKB wrote:
C'est difficile, NG est dans ma boitakhon.
Et alors, c'est une raison pour nous en imposer les consequences. Si il
est dans ta boitakon, tu lui reponds, meme pas par intermediaire. Ca
nous epargneras tes interventions pathetiques.
Et alors, c'est une raison pour nous en imposer les consequences. Si il est dans ta boitakon, tu lui reponds, meme pas par intermediaire. Ca nous epargneras tes interventions pathetiques.
ST
On 11/17/10 11:55 PM, JKB 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.
On 11/17/10 11:55 PM, JKB 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.
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.
Hugues
ST a suggéré :
On 11/17/10 10:52 PM, JKB wrote:
C'est difficile, NG est dans ma boitakhon.
Et alors, c'est une raison pour nous en imposer les consequences. Si il est dans ta boitakon, tu lui reponds, meme pas par intermediaire. Ca nous epargneras tes interventions pathetiques.
Je crois que je vais finir par suivre l'exemple de JKB...
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
ST <st@unices.org> a suggéré :
On 11/17/10 10:52 PM, JKB wrote:
C'est difficile, NG est dans ma boitakhon.
Et alors, c'est une raison pour nous en imposer les consequences. Si
il est dans ta boitakon, tu lui reponds, meme pas par
intermediaire. Ca nous epargneras tes interventions pathetiques.
Je crois que je vais finir par suivre l'exemple de JKB...
Et alors, c'est une raison pour nous en imposer les consequences. Si il est dans ta boitakon, tu lui reponds, meme pas par intermediaire. Ca nous epargneras tes interventions pathetiques.
Je crois que je vais finir par suivre l'exemple de JKB...
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Hugues
ST a suggéré :
On 11/17/10 11:55 PM, JKB 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.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
ST <st@unices.org> a suggéré :
On 11/17/10 11:55 PM, JKB 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.
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.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
JKB
Le Fri, 19 Nov 2010 12:18:31 +0100, Hugues écrivait :
ST a suggéré :
On 11/17/10 11:55 PM, JKB 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.
Fais gaffe, il va te donner un cours d'administration système. Tu verras très vite que le seul qui ne gère pas ses machines comme un goret (enfin, selon ses critères), c'est lui.
Et j'aimerais bien savoir comment on peut gérer MySQL autrement que comme un goret vu que les problèmes d'explosion en vol peuvent provenir d'un verrou foireux posé par MySQL ou de pleins d'erreurs relevant du système et mal récupérées par MySQL. Le dernier exemple que j'ai eu, c'est un verrou posé sur une transaction innoDB avec la transaction qui plante sans lever le verrou. Impossible d'arrêter la base sauf avec un kill. Là, tu croises les doigts lors du redémarrage de la 'chose'.
Et ce n'est pas moi qui critique MySQL, il suffit de lire les articles de son _concepteur_. Il a écrit des choses intéressantes sur la gestion des verrous, les erreurs système et la gestion de la mémoire du bouzin.
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 Fri, 19 Nov 2010 12:18:31 +0100,
Hugues <hugues@hiegel.fr> écrivait :
ST <st@unices.org> a suggéré :
On 11/17/10 11:55 PM, JKB 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.
Fais gaffe, il va te donner un cours d'administration système. Tu
verras très vite que le seul qui ne gère pas ses machines comme un
goret (enfin, selon ses critères), c'est lui.
Et j'aimerais bien savoir comment on peut gérer MySQL autrement que
comme un goret vu que les problèmes d'explosion en vol peuvent provenir
d'un verrou foireux posé par MySQL ou de pleins d'erreurs relevant
du système et mal récupérées par MySQL. Le dernier exemple que j'ai
eu, c'est un verrou posé sur une transaction innoDB avec la
transaction qui plante sans lever le verrou. Impossible d'arrêter la
base sauf avec un kill. Là, tu croises les doigts lors du
redémarrage de la 'chose'.
Et ce n'est pas moi qui critique MySQL, il suffit de lire les
articles de son _concepteur_. Il a écrit des choses intéressantes
sur la gestion des verrous, les erreurs système et la gestion de la
mémoire du bouzin.
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 Fri, 19 Nov 2010 12:18:31 +0100, Hugues écrivait :
ST a suggéré :
On 11/17/10 11:55 PM, JKB 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.
Fais gaffe, il va te donner un cours d'administration système. Tu verras très vite que le seul qui ne gère pas ses machines comme un goret (enfin, selon ses critères), c'est lui.
Et j'aimerais bien savoir comment on peut gérer MySQL autrement que comme un goret vu que les problèmes d'explosion en vol peuvent provenir d'un verrou foireux posé par MySQL ou de pleins d'erreurs relevant du système et mal récupérées par MySQL. Le dernier exemple que j'ai eu, c'est un verrou posé sur une transaction innoDB avec la transaction qui plante sans lever le verrou. Impossible d'arrêter la base sauf avec un kill. Là, tu croises les doigts lors du redémarrage de la 'chose'.
Et ce n'est pas moi qui critique MySQL, il suffit de lire les articles de son _concepteur_. Il a écrit des choses intéressantes sur la gestion des verrous, les erreurs système et la gestion de la mémoire du bouzin.
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
Hugues
JKB a suggéré :
Le Fri, 19 Nov 2010 12:18:31 +0100, Hugues écrivait :
ST a suggéré :
On 11/17/10 11:55 PM, JKB 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.
Fais gaffe, il va te donner un cours d'administration système. Tu verras très vite que le seul qui ne gère pas ses machines comme un goret (enfin, selon ses critères), c'est lui.
Même pas peur, ma question est à double tranchant : - soit il me donne une réponse cohérente, et au moins j'aurais appris quelque chose de lui - soit non, dans ce cas je vais me faire un plaisir d'agrémenter mon killfile sans aucun regret.
Et j'aimerais bien savoir comment on peut gérer MySQL autrement que comme un goret vu que les problèmes d'explosion en vol peuvent provenir d'un verrou foireux posé par MySQL ou de pleins d'erreurs relevant du système et mal récupérées par MySQL. Le dernier exemple que j'ai eu, c'est un verrou posé sur une transaction innoDB avec la transaction qui plante sans lever le verrou. Impossible d'arrêter la base sauf avec un kill. Là, tu croises les doigts lors du redémarrage de la 'chose'.
C'est moche, ça :)
Et ce n'est pas moi qui critique MySQL, il suffit de lire les articles de son _concepteur_. Il a écrit des choses intéressantes sur la gestion des verrous, les erreurs système et la gestion de la mémoire du bouzin.
Il est clair que je préfère croire le concepteur de la Chose, plutôt que l'avis d'un pseudo administrateur aigri qui te prend de haut au moindre de tes arguments.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
JKB <jkb@koenigsberg.invalid> a suggéré :
Le Fri, 19 Nov 2010 12:18:31 +0100,
Hugues <hugues@hiegel.fr> écrivait :
ST <st@unices.org> a suggéré :
On 11/17/10 11:55 PM, JKB 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.
Fais gaffe, il va te donner un cours d'administration système. Tu
verras très vite que le seul qui ne gère pas ses machines comme un
goret (enfin, selon ses critères), c'est lui.
Même pas peur, ma question est à double tranchant :
- soit il me donne une réponse cohérente, et au moins j'aurais appris
quelque chose de lui
- soit non, dans ce cas je vais me faire un plaisir d'agrémenter mon
killfile sans aucun regret.
Et j'aimerais bien savoir comment on peut gérer MySQL autrement que
comme un goret vu que les problèmes d'explosion en vol peuvent provenir
d'un verrou foireux posé par MySQL ou de pleins d'erreurs relevant
du système et mal récupérées par MySQL. Le dernier exemple que j'ai
eu, c'est un verrou posé sur une transaction innoDB avec la
transaction qui plante sans lever le verrou. Impossible d'arrêter la
base sauf avec un kill. Là, tu croises les doigts lors du
redémarrage de la 'chose'.
C'est moche, ça :)
Et ce n'est pas moi qui critique MySQL, il suffit de lire les
articles de son _concepteur_. Il a écrit des choses intéressantes
sur la gestion des verrous, les erreurs système et la gestion de la
mémoire du bouzin.
Il est clair que je préfère croire le concepteur de la Chose, plutôt que
l'avis d'un pseudo administrateur aigri qui te prend de haut au moindre
de tes arguments.
Le Fri, 19 Nov 2010 12:18:31 +0100, Hugues écrivait :
ST a suggéré :
On 11/17/10 11:55 PM, JKB 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.
Fais gaffe, il va te donner un cours d'administration système. Tu verras très vite que le seul qui ne gère pas ses machines comme un goret (enfin, selon ses critères), c'est lui.
Même pas peur, ma question est à double tranchant : - soit il me donne une réponse cohérente, et au moins j'aurais appris quelque chose de lui - soit non, dans ce cas je vais me faire un plaisir d'agrémenter mon killfile sans aucun regret.
Et j'aimerais bien savoir comment on peut gérer MySQL autrement que comme un goret vu que les problèmes d'explosion en vol peuvent provenir d'un verrou foireux posé par MySQL ou de pleins d'erreurs relevant du système et mal récupérées par MySQL. Le dernier exemple que j'ai eu, c'est un verrou posé sur une transaction innoDB avec la transaction qui plante sans lever le verrou. Impossible d'arrêter la base sauf avec un kill. Là, tu croises les doigts lors du redémarrage de la 'chose'.
C'est moche, ça :)
Et ce n'est pas moi qui critique MySQL, il suffit de lire les articles de son _concepteur_. Il a écrit des choses intéressantes sur la gestion des verrous, les erreurs système et la gestion de la mémoire du bouzin.
Il est clair que je préfère croire le concepteur de la Chose, plutôt que l'avis d'un pseudo administrateur aigri qui te prend de haut au moindre de tes arguments.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
ptilou
Bonjour,
On 18 nov, 10:17, JKB wrote:
Le Thu, 18 Nov 2010 01:10:32 -0800 (PST), ptilou écrivait :
>> Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disqu e 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 _to ut_. >> Aujourd'hui, avec MySQL, c'est ceinture _et_ bretelles . Et lorsque >> le client veut MySQL, je lui fais signer une décharg e dans laquelle >> il assure faire lui-même ses sauvegardes, parce que mêmes les >> répliques sont foutues de planter (le plus marrant, sur une requête >> qui est passée sans problème sur la base maître et qui est >> parfaitement conforme).
>> JKB
> Tiens du jour au lendemain MYSQL c'est de la merde, et avant c'était > recommander, Monsieur neuneu et madame Michu vont surement > comprendre !
Je veux bien bouffer un balai si tu trouves un seul de me s posts dans lequel je recommande l'utilisation de MySQL. J'ai ut ilisé - malheureusement - MySQL avant même que Sun ne l'achèt e, et ce produit a toujours été merdique. Sun et Oracle n'y so nt pour strictement rien.
> Deux question viennent à l'esprit : > Cas fait oracle contre le Libre ?
Tout. Voir l'histoire openSolaris, Java 7, OpenOffice et j'en passe.
Tous se qu'ils ont acheté chez sun, ils s'en débardassent ... ( peut on leur reprocher de vouloir être rentable ?)
> Pourquoi Oracle ne croit pas dans le Libre ?
Pourquoi Oracle ne croit-il pas en RDB qui éclate litt éralement OracleDB ?
Peut-être du coté technique, mais commercialement c'est Oracle
Ptilou
Bonjour,
On 18 nov, 10:17, JKB <j...@koenigsberg.invalid> wrote:
Le Thu, 18 Nov 2010 01:10:32 -0800 (PST),
ptilou <pti...@gmail.com> écrivait :
>> Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disqu e 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 _to ut_.
>> Aujourd'hui, avec MySQL, c'est ceinture _et_ bretelles . Et lorsque
>> le client veut MySQL, je lui fais signer une décharg e dans laquelle
>> il assure faire lui-même ses sauvegardes, parce que mêmes les
>> répliques sont foutues de planter (le plus marrant, sur une requête
>> qui est passée sans problème sur la base maître et qui est
>> parfaitement conforme).
>> JKB
> Tiens du jour au lendemain MYSQL c'est de la merde, et avant c'était
> recommander, Monsieur neuneu et madame Michu vont surement
> comprendre !
Je veux bien bouffer un balai si tu trouves un seul de me s posts
dans lequel je recommande l'utilisation de MySQL. J'ai ut ilisé -
malheureusement - MySQL avant même que Sun ne l'achèt e, et ce
produit a toujours été merdique. Sun et Oracle n'y so nt pour
strictement rien.
> Deux question viennent à l'esprit :
> Cas fait oracle contre le Libre ?
Tout. Voir l'histoire openSolaris, Java 7, OpenOffice et j'en passe.
Tous se qu'ils ont acheté chez sun, ils s'en débardassent ...
( peut on leur reprocher de vouloir être rentable ?)
> Pourquoi Oracle ne croit pas dans le Libre ?
Pourquoi Oracle ne croit-il pas en RDB qui éclate litt éralement
OracleDB ?
Peut-être du coté technique, mais commercialement c'est Oracle
Le Thu, 18 Nov 2010 01:10:32 -0800 (PST), ptilou écrivait :
>> Tant qu'il fonctionne ? Rien. Sauf que lorsqu'un disqu e 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 _to ut_. >> Aujourd'hui, avec MySQL, c'est ceinture _et_ bretelles . Et lorsque >> le client veut MySQL, je lui fais signer une décharg e dans laquelle >> il assure faire lui-même ses sauvegardes, parce que mêmes les >> répliques sont foutues de planter (le plus marrant, sur une requête >> qui est passée sans problème sur la base maître et qui est >> parfaitement conforme).
>> JKB
> Tiens du jour au lendemain MYSQL c'est de la merde, et avant c'était > recommander, Monsieur neuneu et madame Michu vont surement > comprendre !
Je veux bien bouffer un balai si tu trouves un seul de me s posts dans lequel je recommande l'utilisation de MySQL. J'ai ut ilisé - malheureusement - MySQL avant même que Sun ne l'achèt e, et ce produit a toujours été merdique. Sun et Oracle n'y so nt pour strictement rien.
> Deux question viennent à l'esprit : > Cas fait oracle contre le Libre ?
Tout. Voir l'histoire openSolaris, Java 7, OpenOffice et j'en passe.
Tous se qu'ils ont acheté chez sun, ils s'en débardassent ... ( peut on leur reprocher de vouloir être rentable ?)
> Pourquoi Oracle ne croit pas dans le Libre ?
Pourquoi Oracle ne croit-il pas en RDB qui éclate litt éralement OracleDB ?
Peut-être du coté technique, mais commercialement c'est Oracle
Ptilou
ST
On 11/19/10 8:15 PM, JKB wrote:
Fais gaffe, il va te donner un cours d'administration système. Tu verras très vite que le seul qui ne gère pas ses machines comme un goret (enfin, selon ses critères), c'est lui.
Non, je n'ai jamais dit ca. Par contre, que tu laisses des disques arriver a saturation sur des machines de prod (ou que tu sous-entendes que ca arrive) en dit long sur ta facon de travailler.
Et j'aimerais bien savoir comment on peut gérer MySQL autrement que comme un goret vu que les problèmes d'explosion en vol peuvent provenir d'un verrou foireux posé par MySQL ou de pleins d'erreurs relevant du système et mal récupérées par MySQL. Le dernier exemple que j'ai eu, c'est un verrou posé sur une transaction innoDB avec la transaction qui plante sans lever le verrou. Impossible d'arrêter la base sauf avec un kill. Là, tu croises les doigts lors du redémarrage de la 'chose'.
MySQL est une bouse, mais ca reste une base pratique pour gerer des sites web, des blogs et tout ce qui ne necessite pas l'armement lourd. Utilise dans des conditions normales et administré correctement, ca reste stable et utilisable.
C'est juste une question d'echelle, le piege etant de l'utiliser sur des bases qui deviennent tres grosses avec le temps.
On 11/19/10 8:15 PM, JKB wrote:
Fais gaffe, il va te donner un cours d'administration système. Tu
verras très vite que le seul qui ne gère pas ses machines comme un
goret (enfin, selon ses critères), c'est lui.
Non, je n'ai jamais dit ca. Par contre, que tu laisses des disques
arriver a saturation sur des machines de prod (ou que tu sous-entendes
que ca arrive) en dit long sur ta facon de travailler.
Et j'aimerais bien savoir comment on peut gérer MySQL autrement que
comme un goret vu que les problèmes d'explosion en vol peuvent provenir
d'un verrou foireux posé par MySQL ou de pleins d'erreurs relevant
du système et mal récupérées par MySQL. Le dernier exemple que j'ai
eu, c'est un verrou posé sur une transaction innoDB avec la
transaction qui plante sans lever le verrou. Impossible d'arrêter la
base sauf avec un kill. Là, tu croises les doigts lors du
redémarrage de la 'chose'.
MySQL est une bouse, mais ca reste une base pratique pour gerer des
sites web, des blogs et tout ce qui ne necessite pas l'armement lourd.
Utilise dans des conditions normales et administré correctement, ca
reste stable et utilisable.
C'est juste une question d'echelle, le piege etant de l'utiliser sur des
bases qui deviennent tres grosses avec le temps.
Fais gaffe, il va te donner un cours d'administration système. Tu verras très vite que le seul qui ne gère pas ses machines comme un goret (enfin, selon ses critères), c'est lui.
Non, je n'ai jamais dit ca. Par contre, que tu laisses des disques arriver a saturation sur des machines de prod (ou que tu sous-entendes que ca arrive) en dit long sur ta facon de travailler.
Et j'aimerais bien savoir comment on peut gérer MySQL autrement que comme un goret vu que les problèmes d'explosion en vol peuvent provenir d'un verrou foireux posé par MySQL ou de pleins d'erreurs relevant du système et mal récupérées par MySQL. Le dernier exemple que j'ai eu, c'est un verrou posé sur une transaction innoDB avec la transaction qui plante sans lever le verrou. Impossible d'arrêter la base sauf avec un kill. Là, tu croises les doigts lors du redémarrage de la 'chose'.
MySQL est une bouse, mais ca reste une base pratique pour gerer des sites web, des blogs et tout ce qui ne necessite pas l'armement lourd. Utilise dans des conditions normales et administré correctement, ca reste stable et utilisable.
C'est juste une question d'echelle, le piege etant de l'utiliser sur des bases qui deviennent tres grosses avec le temps.
