Kommentare zu: Gentoo und MySQL: A never-ending story http://node-0.mneisen.org/2006/10/25/gentoo-und-mysql-a-never-ending-story/ more random ramblings ... Fri, 09 Jul 2010 11:33:23 +0200 http://wordpress.org/?v=2.8.4 hourly 1 Von: pille http://node-0.mneisen.org/2006/10/25/gentoo-und-mysql-a-never-ending-story/comment-page-1/#comment-521 pille Tue, 13 Feb 2007 11:43:00 +0000 http://node-0.mneisen.org/?p=166#comment-521 auf meinen gentoo-servern habe ich auch immer die bange frage, ob ein update jetzt was kaputt macht, oder nicht. um schnell wieder auf die alte version zurueckzuwechseln, mache ich daher vorher von allen mir wichtigen packeten (=diensten), die geupdatet werden sollen ein 'quickpkg'. das ist ein tar aller installierten files des packetes und kann im falle eines falles schnell zurueckinstalliert werden. auf meinen gentoo-servern habe ich auch immer die bange frage, ob ein update jetzt was kaputt macht, oder nicht. um schnell wieder auf die alte version zurueckzuwechseln, mache ich daher vorher von allen mir wichtigen packeten (=diensten), die geupdatet werden sollen ein ‘quickpkg’.

das ist ein tar aller installierten files des packetes und kann im falle eines falles schnell zurueckinstalliert werden.

]]> Von: Markus http://node-0.mneisen.org/2006/10/25/gentoo-und-mysql-a-never-ending-story/comment-page-1/#comment-520 Markus Mon, 20 Nov 2006 18:12:15 +0000 http://node-0.mneisen.org/?p=166#comment-520 puh, kann wieder mailen... puh, kann wieder mailen…

]]> Von: Markus http://node-0.mneisen.org/2006/10/25/gentoo-und-mysql-a-never-ending-story/comment-page-1/#comment-519 Markus Mon, 20 Nov 2006 17:39:56 +0000 http://node-0.mneisen.org/?p=166#comment-519 Tja, da lief es ewig, ohne Probleme und dann will ich eben nur eine "Kleinigkeit" machen, da habe ich die selben Probs. Bin gerade dabei, mysql neu zu comilen, soll ja helfen. Hoffentlich! Tja, da lief es ewig, ohne Probleme und dann will ich eben nur eine “Kleinigkeit” machen, da habe ich die selben Probs. Bin gerade dabei, mysql neu zu comilen, soll ja helfen. Hoffentlich!

]]> Von: Johannes http://node-0.mneisen.org/2006/10/25/gentoo-und-mysql-a-never-ending-story/comment-page-1/#comment-518 Johannes Mon, 13 Nov 2006 14:38:09 +0000 http://node-0.mneisen.org/?p=166#comment-518 Danke für die Ausführungen. MySQL 5.0.26 ist ja jetzt stable, meine SASL/MySQL-Authentifizierung hat es heute aber dennoch zerhauen. Ich hab jetzt erstmal wieder ein downgrade auf 4.1 gemacht... Danke für die Ausführungen. MySQL 5.0.26 ist ja jetzt stable, meine SASL/MySQL-Authentifizierung hat es heute aber dennoch zerhauen. Ich hab jetzt erstmal wieder ein downgrade auf 4.1 gemacht…

]]> Von: Luca Longinotti http://node-0.mneisen.org/2006/10/25/gentoo-und-mysql-a-never-ending-story/comment-page-1/#comment-517 Luca Longinotti Fri, 27 Oct 2006 11:22:12 +0000 http://node-0.mneisen.org/?p=166#comment-517 Hallo Martin! Ja, dass MySQL 5.0 noch unstable ist, ist bedauerlich, doch das wird sich endlich bald ändern: https://bugs.gentoo.org/show_bug.cgi?id=144999#c17 Gründe waren vorallem noch Bugs die man beheben musste und viel Testing das man noch machen musste, beides sollte jetzt ok sein. Also so in 8-10 Tagen sollte MySQL 5.0.26-r1 anfangen stable markiert zu werden. Zum Testing: ja, wir werden das ausweitern, atm wurden vorallem die MySQL eigenen Tests und PHP/PHP Apps als Test-cases benutzt, MTA/Language-Bindings, wenigstens meinerseits, noch nie, muss gestehen daran nie gross gedacht zu haben... Demnächst werde ich nen neuen Server mit Linux-Vserver aufsetzen, und da werden wir wohl sicher ein paar Images für MySQL-Testing einrichten, was die Arbeit da vereinfachen sollte. ;) Mfg, Luca Longinotti. Hallo Martin!
Ja, dass MySQL 5.0 noch unstable ist, ist bedauerlich, doch das wird sich endlich bald ändern: https://bugs.gentoo.org/show_bug.cgi?id=144999#c17
Gründe waren vorallem noch Bugs die man beheben musste und viel Testing das man noch machen musste, beides sollte jetzt ok sein. Also so in 8-10 Tagen sollte MySQL 5.0.26-r1 anfangen stable markiert zu werden.
Zum Testing: ja, wir werden das ausweitern, atm wurden vorallem die MySQL eigenen Tests und PHP/PHP Apps als Test-cases benutzt, MTA/Language-Bindings, wenigstens meinerseits, noch nie, muss gestehen daran nie gross gedacht zu haben… Demnächst werde ich nen neuen Server mit Linux-Vserver aufsetzen, und da werden wir wohl sicher ein paar Images für MySQL-Testing einrichten, was die Arbeit da vereinfachen sollte. ;)
Mfg, Luca Longinotti.

]]> Von: Martin Eisenhardt http://node-0.mneisen.org/2006/10/25/gentoo-und-mysql-a-never-ending-story/comment-page-1/#comment-516 Martin Eisenhardt Fri, 27 Oct 2006 07:43:00 +0000 http://node-0.mneisen.org/?p=166#comment-516 Hallo Luca, danke für Deinen Kommentar und die Aufklärung, was da wirklich schief gelaufen ist. Ich möchte da mal auf ein paar Punkte eingehen: *MySQL 5 ist in Gentoo unstable* Das stimmt, ist aber sehr bedauerlich, da MySQL 5 viele neue Features mitgebracht hat, die zumindest ich gerne nutze. Das MySQL-Projekt hat die 5.0-Serie bereits seit langem als für den produktiven Einsatz bestimmt gekennzeichnet, und die meisten anderen Linux-Distributionen unterstützten inzwischen standardmäßig MySQL 5. Das soll jetzt _auf keinen Fall_ ein Gentoo-Bashing sein, aber da hinkt diese von mir sehr geschätzte Distribution ein wenig hinterher. Ich kann mir gut vorstellen, dass es dafür Gründe gibt - vielleicht kannst Du da ja ein bisschen Licht ins Dunkel bringen (Links welcome!). *Erklärung für das Problem mit MySQL 5.0.26-r1* Das Problem mit den Quotes in der eclass habe ich dann dank des entsprechenden "Threads in den Gentoo-Foren":http://forums.gentoo.org/viewtopic-t-510268.html auch bei "bugs.gentoo.org":http://bugs.gentoo.org/ gefunden - leider für meine Zwecke ein bisschen spät, aber daran bin ich selbst schuld. Inzwischen ist MySQL 5.0.26-r1 im Einsatz und läuft prima. *UTF-8 vs. Latin1* Ich stimme Dir vollkommen zu, dass UTF-8 die richtige Wahl für ein Charset ist - egal ob in der DB oder systemweit. Damals war halt ärgerlich, dass durch das Update gerade in Blogs, CMS und Foren ziemlich viel Unschönes passierte und ich schnell einen Fix brauchte, den ich dann eben wie in dem verlinkten Blogpost beschrieben vorgenommen habe. Ich gebe zu, dass es kein schöner Fix ist, aber er hat wenigstens funktioniert :-D Inzwischen ist das natürlich kein Thema mehr, alle DBs sind auf UTF-8 portiert und laufen klasse. *Oberthema: Patch-Qualität bzw. Release-Qualität* Es ist immer ein heikles Thema, wenn man über die Qualität der Arbeit anderer spricht. Besonders in diesem Fall, weil ich sowohl von Gentoo insgesamt, aber auch von der MySQL-Unterstützung ziemlich begeistert bin. Dennoch wage ich hier mal eine These aufzustellen: bq. Wenn es zu Problemen wie im April 2006 bzw. jetzt im Oktober 2006 kommt, könnte das ein Hinweis darauf sein, dass die an der Software vorgenommenen Tests eben _doch_ nicht ausreichend waren. Es gibt beim Thema Software-Tests (im Speziellen bei Unit Tests, aber das ist hier sicherlich übertragbar) eine Grundweisheit: bq. Durch Tests kann ich nur feststellen, _dass_ eine Software Fehler enthält, nämlich dann, wenn der Test fehlschlägt. Ich kann durch erfolgreiche Tests _niemals_ feststellen, dass eine Software _keine_ Fehler enthält. Das stellt einen Software-Entwickler oder Maintainer natürlich vor Probleme: Egal, wie sehr er sich anstrengt, er kann nie garantieren, dass die Software fehlerfrei ist. Meiner Meinung nach wäre es aber sinnvoll, die wichtigsten/häufigsten Einsatzszenarien durchzutesten. Im Falle von MySQL bedeutet dies etwa Wordpress, phpBB & Konsorten, diverse Language Bindings (Perl, Python, C, C++, Ruby), amarok u.ä. und eben den Bereich MTA(Mail Transfer Agent). Und da dürfte die Konfiguration Postfix+MySQL+Cyrus-SASL+Courier doch ziemlich häufig anzutreffen sein, also einen typischen _Use Case_ darstellen. *Eine kleine Statistik* Noch ein paar Worte zur Wichtigkeit der Qualitätssicherung bei MySQL: Dieses Blog hier ist noch nicht sehr alt, es gibt nicht allzu viele Artikel. Dennoch: Der am meisten gelesene Artikel ist mit Abstand der Artikel über die UTF-8 vs. Latin1-Geschichte mit PHP unter Gentoo. Auch jetzt kommen jeden Tag Dutzende von Besuchern über Suchmaschinen auf diesen Artikel, übliche Suchanfrage ist "Gentoo Mysql php latin1 utf8" oder etwas sehr ähnliches. *Kleines Fazit* Nach wie vor bin ich von der Qualität, Konfigurierbarkeit, Paketverfügbarkeit und Zuverlässigkeit von Gentoo und MySQL unter Gentoo sehr überzeugt - deshalb setze ich nach wie vor auf dieses Gespann. Im Einzelfall würde ich mir - nach Deinen Schilderungen - etwas umfangreichere und vielleicht realitätsnähere(?) Tests wünschen. Vielleicht gibt es die Möglichkeit, ein paar typische Einsatzszenarien (z.B. Mailserver mit Postfix+MySQL, Blog-Server mit Wordpress und phpBB, ...) als Image für QEMU zu erstellen und auch mit diesen Images zu testen. Ich wäre durchaus bereit, da mitzuhelfen - ich bastele gerne mit QEMU. Hallo Luca,

danke für Deinen Kommentar und die Aufklärung, was da wirklich schief gelaufen ist. Ich möchte da mal auf ein paar Punkte eingehen:

MySQL 5 ist in Gentoo unstable

Das stimmt, ist aber sehr bedauerlich, da MySQL 5 viele neue Features mitgebracht hat, die zumindest ich gerne nutze. Das MySQL-Projekt hat die 5.0-Serie bereits seit langem als für den produktiven Einsatz bestimmt gekennzeichnet, und die meisten anderen Linux-Distributionen unterstützten inzwischen standardmäßig MySQL 5. Das soll jetzt auf keinen Fall ein Gentoo-Bashing sein, aber da hinkt diese von mir sehr geschätzte Distribution ein wenig hinterher. Ich kann mir gut vorstellen, dass es dafür Gründe gibt – vielleicht kannst Du da ja ein bisschen Licht ins Dunkel bringen (Links welcome!).

Erklärung für das Problem mit MySQL 5.0.26-r1

Das Problem mit den Quotes in der eclass habe ich dann dank des entsprechenden Threads in den Gentoo-Foren auch bei bugs.gentoo.org gefunden – leider für meine Zwecke ein bisschen spät, aber daran bin ich selbst schuld.

Inzwischen ist MySQL 5.0.26-r1 im Einsatz und läuft prima.

UTF-8 vs. Latin1

Ich stimme Dir vollkommen zu, dass UTF-8 die richtige Wahl für ein Charset ist – egal ob in der DB oder systemweit. Damals war halt ärgerlich, dass durch das Update gerade in Blogs, CMS und Foren ziemlich viel Unschönes passierte und ich schnell einen Fix brauchte, den ich dann eben wie in dem verlinkten Blogpost beschrieben vorgenommen habe. Ich gebe zu, dass es kein schöner Fix ist, aber er hat wenigstens funktioniert :-D

Inzwischen ist das natürlich kein Thema mehr, alle DBs sind auf UTF-8 portiert und laufen klasse.

Oberthema: Patch-Qualität bzw. Release-Qualität

Es ist immer ein heikles Thema, wenn man über die Qualität der Arbeit anderer spricht. Besonders in diesem Fall, weil ich sowohl von Gentoo insgesamt, aber auch von der MySQL-Unterstützung ziemlich begeistert bin.

Dennoch wage ich hier mal eine These aufzustellen:

Wenn es zu Problemen wie im April 2006 bzw. jetzt im Oktober 2006 kommt, könnte das ein Hinweis darauf sein, dass die an der Software vorgenommenen Tests eben doch nicht ausreichend waren.

Es gibt beim Thema Software-Tests (im Speziellen bei Unit Tests, aber das ist hier sicherlich übertragbar) eine Grundweisheit:

Durch Tests kann ich nur feststellen, dass eine Software Fehler enthält, nämlich dann, wenn der Test fehlschlägt. Ich kann durch erfolgreiche Tests niemals feststellen, dass eine Software keine Fehler enthält.

Das stellt einen Software-Entwickler oder Maintainer natürlich vor Probleme: Egal, wie sehr er sich anstrengt, er kann nie garantieren, dass die Software fehlerfrei ist.

Meiner Meinung nach wäre es aber sinnvoll, die wichtigsten/häufigsten Einsatzszenarien durchzutesten. Im Falle von MySQL bedeutet dies etwa Wordpress, phpBB & Konsorten, diverse Language Bindings (Perl, Python, C, C++, Ruby), amarok u.ä. und eben den Bereich MTA. Und da dürfte die Konfiguration Postfix+MySQL+Cyrus-SASL+Courier doch ziemlich häufig anzutreffen sein, also einen typischen Use Case darstellen.

Eine kleine Statistik

Noch ein paar Worte zur Wichtigkeit der Qualitätssicherung bei MySQL: Dieses Blog hier ist noch nicht sehr alt, es gibt nicht allzu viele Artikel. Dennoch: Der am meisten gelesene Artikel ist mit Abstand der Artikel über die UTF-8 vs. Latin1-Geschichte mit PHP unter Gentoo. Auch jetzt kommen jeden Tag Dutzende von Besuchern über Suchmaschinen auf diesen Artikel, übliche Suchanfrage ist “Gentoo Mysql php latin1 utf8” oder etwas sehr ähnliches.

Kleines Fazit

Nach wie vor bin ich von der Qualität, Konfigurierbarkeit, Paketverfügbarkeit und Zuverlässigkeit von Gentoo und MySQL unter Gentoo sehr überzeugt – deshalb setze ich nach wie vor auf dieses Gespann.

Im Einzelfall würde ich mir – nach Deinen Schilderungen – etwas umfangreichere und vielleicht realitätsnähere(?) Tests wünschen. Vielleicht gibt es die Möglichkeit, ein paar typische Einsatzszenarien (z.B. Mailserver mit Postfix+MySQL, Blog-Server mit Wordpress und phpBB, ...) als Image für QEMU zu erstellen und auch mit diesen Images zu testen.

Ich wäre durchaus bereit, da mitzuhelfen – ich bastele gerne mit QEMU.

]]> Von: Luca Longinotti http://node-0.mneisen.org/2006/10/25/gentoo-und-mysql-a-never-ending-story/comment-page-1/#comment-515 Luca Longinotti Thu, 26 Oct 2006 20:00:01 +0000 http://node-0.mneisen.org/?p=166#comment-515 Hi, hab den Blogpost hier auf den Forums gesehen und will mal kommentieren... Also, zuerst hat das Problem mit den Sockets nichts mit dem -r1 upgrade zu tun um das ABI Breakage zu fixen. Wir haben 5.0.26 released, was auch all unsere Tests (MySQL-Testsuite, tests mit PHP etc.) durchging, als MySQL AB das freigegeben hat... Da dann aber ein ABI Breakage drin war, haben wir dann 5.0.26-r1 freigegeben mit dem korrekten fix dafür, und was wars bezüglich den "bindestrich Versionen" (wer hat da gesagt es können sich keine grossen Sachen ändern? Und auch ist MySQL 5.0.X _noch_ als unstable markiert...). Zeitgleich werkelten wir an den mysql Eclasses um MySQL 5.1 support zu fixen, und gaben diese neuen Eclasses Samstag Abend frei (auch da, all unsere Tests waren erfolgreich), doch da schlich sich ein minimaler Bug ein: die Socket-Path Angabe wurde mit '' quotiert, was theoretisch keine Probleme verursachen sollte, doch einige Programme nahmen das dann zu ernst und benutzten direkt '/var/.../mysql.sock' (MIT den quotes) als Socket-Path, was natürlich nicht geht... Sobald wir am Montag Morgen darüber informiert worden, wurde der Bug gefixt. Da das Problem in den Eclasses war, betraf es alle dev-db/mysql Versionen die in der Zeitspanne emerged wurden (natürlich vorausgesetzt man hatte in der Zeitspanne auch emerge --sync gemacht)... Korrekter fix: einfach re-emergen. :) Wir sind uns darüber im Klaren das solche Sachen nicht passieren sollten, doch leider kann man nicht alles vorhersehen, und wenn uns Probleme bekannt werden, versuchen wir die schnellstmöglich zu beheben. Auch das UTF-8/Latin1 Problem war n'bissel komplizierter als was hier geschrieben wurde, eine Serie an Updates in MySQL und PHP, die einzeln korrekt funktionierten, doch zusammen etwas weniger, war Schuld, und dann entschieden wir uns halt mit der UTF-8 Idee weiterzumachen, weil es unumstritten das bessere Charset der beiden ist, und haben dann den my.cnf fix für PHP bereitgestellt. Grüsse, Luca Longinotti, Gentoo PHP & MySQL Maintainer. Hi, hab den Blogpost hier auf den Forums gesehen und will mal kommentieren…
Also, zuerst hat das Problem mit den Sockets nichts mit dem -r1 upgrade zu tun um das ABI Breakage zu fixen.
Wir haben 5.0.26 released, was auch all unsere Tests (MySQL-Testsuite, tests mit PHP etc.) durchging, als MySQL AB das freigegeben hat… Da dann aber ein ABI Breakage drin war, haben wir dann 5.0.26-r1 freigegeben mit dem korrekten fix dafür, und was wars bezüglich den “bindestrich Versionen” (wer hat da gesagt es können sich keine grossen Sachen ändern? Und auch ist MySQL 5.0.X noch als unstable markiert…).
Zeitgleich werkelten wir an den mysql Eclasses um MySQL 5.1 support zu fixen, und gaben diese neuen Eclasses Samstag Abend frei (auch da, all unsere Tests waren erfolgreich), doch da schlich sich ein minimaler Bug ein: die Socket-Path Angabe wurde mit ‘’ quotiert, was theoretisch keine Probleme verursachen sollte, doch einige Programme nahmen das dann zu ernst und benutzten direkt ’/var/.../mysql.sock’ (MIT den quotes) als Socket-Path, was natürlich nicht geht… Sobald wir am Montag Morgen darüber informiert worden, wurde der Bug gefixt. Da das Problem in den Eclasses war, betraf es alle dev-db/mysql Versionen die in der Zeitspanne emerged wurden (natürlich vorausgesetzt man hatte in der Zeitspanne auch emerge—sync gemacht)... Korrekter fix: einfach re-emergen. :)
Wir sind uns darüber im Klaren das solche Sachen nicht passieren sollten, doch leider kann man nicht alles vorhersehen, und wenn uns Probleme bekannt werden, versuchen wir die schnellstmöglich zu beheben. Auch das UTF-8/Latin1 Problem war n’bissel komplizierter als was hier geschrieben wurde, eine Serie an Updates in MySQL und PHP, die einzeln korrekt funktionierten, doch zusammen etwas weniger, war Schuld, und dann entschieden wir uns halt mit der UTF-8 Idee weiterzumachen, weil es unumstritten das bessere Charset der beiden ist, und haben dann den my.cnf fix für PHP bereitgestellt.
Grüsse, Luca Longinotti, Gentoo PHP & MySQL Maintainer.

]]>