MySQL 5.1 - Empfohlen?

User avatar
isotopp
RSAC
Posts: 482
Joined: 2003-08-21 10:21
Location: Berlin

MySQL 5.1 - Empfohlen?

Post by isotopp »

Dies ist ein langer Text. Er ist meine private Meinung, die auf meinem privaten Erleben beruht und in keiner Weise ein offizielles Statement von MySQL, Sun oder booking.com/Priceline. Er endet mit dieser vorweg genommenen Empfehlung:
Was bedeutet all das für den MySQL Anwender?

1. MySQL 5.1 ist eine gute Wahl, auch wenn Monty nicht mit dem Produkt zufrieden ist. MySQL 5.1 kann alles, was 5.0 kann und mehr. Das was 5.0 kann, kann 5.1 besser und stabiler. Das neue Zeugs in 5.1 will man testen.

2. Für den MySQL Enterprise Kunden gibt es keine Alternative zu MySQL 5.0 und 5.1. Das ist auch sehr in Ordnung, insbesondere hat Sun den sowieso schon guten MySQL Support nicht nur am Leben gelassen, sondern sogar personell sogar noch gestärkt. MySQL Consulting in Europa ist derzeit schwach, wird aber neu aufgebaut und in langfristig in Sun Consulting integriert. Das sollte insbesondere das Staffing Problem da recht endgültig beheben.

3. Für den Privatanwender ist die Frage im wesentlichen MySQL Community Edition oder XtraDB. XtraDB hat einen Haufen recht interessante Performance Patches, aber die meisten Leute sind nicht mal in der Lage, ein normales MySQL korrekt zu konfigurieren. Insofern macht es vielleicht keinen so großen Unterschied und man wäre mit dem offiziellen MySQL Zweig langfristig auf der sichereren Seite.

4. Für Code-Schreiber ist Drizzle das weitaus interessanteste Projekt. Wer einmal in die Eingeweide einer Datenbank greifen will und da *richtig* drin rumwühlen will - Drizzle ist genau das.

5. Vor dem Einsatz von 5.1 zu warnen, bloß weil Monty frustriert war, ist nicht der richtige Ansatz. Die neuen Features von 5.1 muß man sorgfältig testen und dann entscheiden ob sie Teil der Lösung oder Teil des Problems sind. Aber ein 5.1 wie ein 5.0 einzusetzen ist immer eine Verbesserung.


Vor dem Verkauf von MySQL an Sun war MySQL eine eigenständige Open Source Firma. Die Strategie von MySQL war damals von zwei Notwendigkeiten geprägt, die sich in zwei Personen verkörpert haben.

Zum einen ist da die Weiterentwicklung des Produktes zu einer leistungsfähigen Datenbank, die eine stabile und leicht erweiterbare Open Source Codebasis hat. Monty ist die Person, die sich diese Idee und ihre Prinzipien auf die Fahnen geschrieben hat und die MySQL in dieser Hinsicht geprägt hat - Monty stellt Codekorrektheit über alles und weigert sich, Code mit bekannten kritischen Bugs als 'stabil' zu releasen.

Zum anderen sind da die geschäftlichen Notwendigkeiten - MySQL war unmittelbar vor dem Verkauf eine Firma von 500 Mitarbeitern, von denen etwa 150 oder so Entwickler waren, die für Geld am MySQL Source gearbeitet haben und das Produkt weiter entwickelt und Bugs gefixt haben. Deren Gehalt muß rein kommen und MySQL mußte daher auch einen kommerziellen Appeal haben, der es rechtfertigt, eine kommerzielle Lizenz zu kaufen oder Support und Consulting für MySQL einzukaufen. Mårten ist die Person, die sich dieses Ziel vorgenommen hat und MySQL in dieser Richtung entwickelt hat.

Mårten ist als Manager eine Person, die den Begriff 'Verantwortung für Mitarbeiter' sehr ernst nimmt. Während meiner Zeit bei MySQL ist es Mårten immer wieder gelungen, mich und andere zu überraschen, denn er kennt seine Leute und er weiß, was sie tun. Jeden von Ihnen.

Neben seinem Schreibtisch in seinem Home Office hängen zwei aus Mitarbeiterfotos zusammengesetzte Collagen in Delfinform. Als ich das erste Mal am Rande der MySQL Users Conference bei Mårten in Kalifornien auf einer Party in seinem Haus gewesen bin, kam er auf mich zu, schüttelte mir die Hand, kannte mein Gesicht und wußte, wo ich Lebe, für was ich mich interessiere und auch, bei welchen Kunden ich zuletzt gewesen bin. Wir hatten uns vorher nie von Angesicht zu Angesicht getroffen. Ich habe Mårten an diesem Abend dasselbe noch mit vielen anderen Personen tun sehen.

Mårten kennt seine Leute, weiß, was sie tun, und er sieht seine Aufgabe darin, das Produkt und die Firma so zu entwickeln, daß seine Leute von MySQL leben können und eine Familie ernähren können. Mårten hat auch ein wesentlich weniger kritisches Releasemodell als Monty - wenn es für den Kunden gut genug ist, dann kann man es auch als stabil releasen.

Mårtens Einfluß auf MySQL beginnt nach dem Release von MySQL 4.0. Ein Ziel, das Mårten sich gesetzt hat, war MySQL als Produkt auf die Liste der SQL-Produkte von Joe Celko zu bekommen. Joe Celko hat 13 Jahre im SQL Standards Committee gesessen, die Sprache wesentlich mit geprägt und ist eine ältere SQL Gottheit (und, wie das mit älteren Göttern manchmal so ist, manchmal ein wenig garstig). Wenn man sein SQL-Produkt auf seine Liste bekommt, ist man offiziell 'enterprise ready' und das Produkt ist wesentlich leichter zu verkaufen.

Um dieses Ziel zu erreichen waren MySQL 4.1 und 5.0 große Feature Releases, die sehr weit reichende Erweiterungen in der Codebasis eingeführt haben. Die Anzahl der Zeilen im Sourcetree hat sich von 4.0 nach 5.0 mehr als verdoppelt. Die Anzahl der Mitarbeiter von MySQL ist in dieser Zeit um mehr als den Faktor 4 gewachsen.

Monty war gegen viele dieser Erweiterungen, damals schon, weil sie unter einem sehr anspruchsvollen Zeitplan stattfanden und die Codequalität sowie der Umfang der Implementation nicht seinen extrem hohen Ansprüchen genügten. Monty war auch eine der Personen, die ursächlich das initiale 5.0 Release verzögert haben. Das war auch gut so - zwar war 5.0.18 stabil deklariert, aber 5.0.26 war das erste wirklich stabile 5.0 Release und erst mit der Umstellung der internen Entwicklungsprozesse um 5.0.30 herum ist dann gelungen, mehr Bugs pro Monat zu fixen als gemeldet wurden.

Monty und Mårten hatten also schon zum 4.1 und zum 5.0 Release Streit, und Mårten hatte sich hier zwei Mal durchgesetzt. Das war auch gut so, denn ohne diese Releases und ihre Features wäre MySQL heute nicht da, wo es ist und Monty hätte weder Geld noch Entwickler um das zu tun, was er tun möchte.

Trotzdem hat Monty recht - Mårten und MySQL brauchen eine Pause und müssen sich einmal zwei Jahre Zeit nehmen, um die Codebasis aufzuräumen und von Ballast zu befreien. Das hätte zu 5.1 passieren sollen, war aber aus verschiedenen internen Entwicklungstechnischen Gründen so nicht möglich.

5.1 ist stattdessen in anderer Hinsicht ein Cleanup Release: Es führt die Entwicklungsprodukte verschiedener interner Teams ein, die schon zu 5.0 Zeiten in der Queue waren. Da sind einmal Partitions, die neue Row Based Replication und da sind vor allen Dingen viele, viele, viele Änderungen in MySQL Cluster, die für Cluster-Anwender absolut notwendig sind. Und Cluster-Anwender gibt es einige sehr wichtige, und sie zahlen ein Heidengeld an Lizenzen. Im Telekommunikationsmarkt ist MySQL Cluster ein etabliertes Produkt (Und für Leute, die keine GSM Switche bauen ist MySQL Cluster wahrscheinlich nicht das Produkt der Wahl, aber das ist ein anderer Artikel, den ich vielleicht irgendwann anders noch mal schreibe).

Wie dem auch sei: Die MySQL 5.1 Codebasis ist keine, mit der Monty oder sonst jemand, der Lesen und Schreiben kann, zufrieden sein kann. Man schaue sich einmal sql/sql_parse.cc an - selbst wenn man kein C oder C++ kann, wird einem davon schnell mal schlecht.

Nur: Ist MySQL 5.1 deswegen ein kaputtes oder nicht empfehlenswertes Produkt?

Die Antwort ist ein klares 'Nein'. MySQL 5.1 kann alles das, was MySQL 5.0 konnte und mehr. Das was 5.0 konnte, kann MySQL 5.1 besser und vermutlich mit weniger Fehlern.

MySQL 5.1 hat außerdem neue Features. Diese haben wahrscheinlich, wie das mit neuem Zeugs halt so ist, interessante neue Bugs. Man sollte sie daher sorgfältig testen.

Aber: Generell ist es so, daß das MySQL 5.1 Release von besserer Qualität ist als das initiale MySQL 5.0 Release. Es genügt Montys Ansprüchen noch immer nicht, aber es ist auch ein komplizierteres Produkt als etwa 3.23 oder 4.0.

Es ist auch so - und Monty hat da vollkommen Recht! - , daß die MySQL Codebasis aufgeräumt und restrukturiert werden muß.

Es ist weiter so, daß der neue Eigner von MySQL, Sun, da ganz entschiedene eigene Interessen hat. Sun hat zusätzlich auch noch einmal eine große Menge von Ingenieren, die da dran mitarbeiten werden und sollen. Es ist aus Suns Sicht jedoch nicht nur so, daß der Code saubeer und fehlerfreier werden muß, sondern MySQL muß auch für die massiv parallelen Kisten von Sun fit werden, muß mit anderen Sun Technologien wie DTrace integriert werden, muß in Enterprise Strategien von Sun wie Sun Cluster, Auditing, RBAC, SSO/LDAP und so weiter integriert werden und sich auch sonst in die Firmenstrukturen einfügen.

Das alles ist wiederum größer als die unmittelbaren Interessen von Monty und einer der Gründe, warum Monty bei Sun weg ist. Denn viele dieser Arbeiten sind aus Sun-Sicht zwar zwingend, aber es sind keine Datenbankarbeiten. Stattdessen handelt es sich um Enterprise Infrastruktur und aus der Sicht von Monty zunächst einmal Bloat, der einem Aufräumen im Wege steht (aus der Sicht von Fortune 500 Kunden allerdings ein k.o. Kriterium).

Und es gibt außerdem noch einen Haufen Ex-MySQLer, die es gewohnt sind, an der Codebasis rumzubasteln und das auch jetzt noch tun.

Daher gibt es nun mehr als ein MySQL. Das wird nicht so bleiben, aber zur Zeit ist das notwendig, um alle die verschiedenen Interessen und Interessengruppen zu befriedigen.

Da ist einmal die offizielle MySQL Codebasis bei Sun, an der nun ganz massiv mit MySQL Entwicklern und Sun Entwicklern dran rum entwickelt wird. Der Ansatz ist ein integrativer - man braucht ein verkaufbares und funktionsfähiges Produkt und Suns Zielrichtung ist und war der Enterprise Markt. Daher ist dort Aufräumen und Vereinfachen nicht der alleinige Focus, sondern auch die Integration mit bestehenden Sun Hardware- und Softwareporodukten sind ein Schwerpunkt.

Dann ist da der Mashup von Percona, XtraDB. Percona ist eine Firma von einer großen Menge sehr heller Köpfe, die vormals bei MySQL gearbeitet haben und die keinen Bock auf 37.000 Kollegen unter amerikanischem Management haben, sondern lieber in einer kleinen und agilen Firma arbeiten wollen. Unter dem Namen XtraDB hat Percona ihren Fork der MySQL Codebasis, mit einer ganzen Reihe von selbst entwickelten InnoDB Patches und Integration von Patches Dritter Parteien wie z.B. den Google Patches.

XtraDB ist anders als MySQL nicht Dual Licensed, sondern nur unter der GPL zu lizensieren. Im Geiste und von der Intention kommt XtraDB dem Vor-Verkaufs-MySQL am nächsten. Als Codebasis ist XtraDB für den Performance-orientierten Nicht-Cluster-Nutzer ein guter Deal, insbesondere weil des ein Drop-In Replacement für MySQL 5 sein soll. Percona verkauft Consulting und Support für XtraDB, und da sind sie verdammt gut drin.

Und schließlich ist da Drizzle. Drizzle ist ein sehr radikaler Fork von MySQL, an dem ein Haufen Mitarbeiter von Sun/MySQL und interessierte Dritte mitarbeiten. Drizzle hat kein Interesse an Rückwärtskompatibilität und in dieser Phase nicht einmal an Funktionsfähigkeit. Das Drizzle-Projekt räumt den MySQL Source stattdessen gerade auf.

Das geschieht erst einmal, indem alle Funktionalität rausgerissen wird, die den codeästhetischen Ansprüchen der Projektführer nicht entspricht. Dadurch ist es gelungen, die Codebasis von Drizzle um mehr als 50% zu verkleinern.

Erweiterungen von Drizzle sollen vornehmlich als P lugins gestaltet werden. Das bedeutet, daß Drizzle diese fehlende Funktionalität auch nicht wieder direkt erhalten wird, sondern daß es stattdessen an Stelle des entferntes Codes eine Plugin API geben wird, und daß man dann entsprechende Module in Drizzle laden kann, die diese Funktionen bereitstellen, wenn man sie denn braucht.

Das ist architekturell genau die richtige Sache und eine extrem spannendes Unterfangen.

Was bedeutet all das für den MySQL Anwender?

1. MySQL 5.1 ist eine gute Wahl, auch wenn Monty nicht mit dem Produkt zufrieden ist. MySQL 5.1 kann alles, was 5.0 kann und mehr. Das was 5.0 kann, kann 5.1 besser und stabiler. Das neue Zeugs in 5.1 will man testen.

2. Für den MySQL Enterprise Kunden gibt es keine Alternative zu MySQL 5.0 und 5.1. Das ist auch sehr in Ordnung, insbesondere hat Sun den sowieso schon guten MySQL Support nicht nur am Leben gelassen, sondern sogar personell sogar noch gestärkt. MySQL Consulting in Europa ist derzeit schwach, wird aber neu aufgebaut und in langfristig in Sun Consulting integriert. Das sollte insbesondere das Staffing Problem da recht endgültig beheben.

3. Für den Privatanwender ist die Frage im wesentlichen MySQL Community Edition oder XtraDB. XtraDB hat einen Haufen recht interessante Performance Patches, aber die meisten Leute sind nicht mal in der Lage, ein normales MySQL korrekt zu konfigurieren. Insofern macht es vielleicht keinen so großen Unterschied und man wäre mit dem offiziellen MySQL Zweig langfristig auf der sichereren Seite.

4. Für Code-Schreiber ist Drizzle das weitaus interessanteste Projekt. Wer einmal in die Eingeweide einer Datenbank greifen will und da *richtig* drin rumwühlen will - Drizzle ist genau das.

5. Vor dem Einsatz von 5.1 zu warnen, bloß weil Monty frustriert war, ist nicht der richtige Ansatz. Die neuen Features von 5.1 muß man sorgfältig testen und dann entscheiden ob sie Teil der Lösung oder Teil des Problems sind. Aber ein 5.1 wie ein 5.0 einzusetzen ist immer eine Verbesserung.

Mein Arbeitgeber setzt ca. 140 MySQL Instanzen auf 120 Kisten ein. Wir sind zur Zeit fast durchgehend 5.0.68, und testen nun die ersten mitlaufenden 5.1 Slaves, um unser SQL clean zu bekommen (MySQL 5.1 erkennt ein paar fehlerhafte SQL Statements als fehlerhaft, die 5.0 irrtümlich für legal hielt). Bis zum Herbst wollen wir unsere Infrastruktur durchgehend auf aktuelle 5.1 Versionen angehoben haben.
Top

oxygen
RSAC
Posts: 2179
Joined: 2002-12-15 00:10
Location: Bergheim

Re: MySQL 5.1 - Empfohlen?

Post by oxygen »

Vielen dank für den interessanten Einblick.
Top

oschad
Posts: 10
Joined: 2009-04-22 12:04

Re: MySQL 5.1 - Empfohlen?

Post by oschad »

Die Frage ist ja eher, warum man MySQL mit den bekannten Problemen überhaupt einsetzen will. Die Probleme bei konkurrierenden Zugriffen, kaputten Query-Optimizer, Backup-Probleme etc. Ich will einfach mit einem DBMS arbeiten, ich will nicht ständig mich mit den Grenzen eines kaputten DBMS im Alltag beschäftigen, das muss zwingend funktionieren, einfach so.

Was macht man bei MySQL, wenn man Backup machen will? Man sperrt die zu sichernde DB für Schreibzugriffe und sichert dann - ja herzlichen Glückwunsch, das macht vor allen Dingen bei mehrere GB großen Datenbanken wirklich Sinn die mal ne Stunde vom Netz zu nehmen.

Und das beste ist: Wenn man mysqldump nicht explizit sagt, dass es die DB lockt, dann schreiben während des Dumps lustig andere Benutzer in der DB und machen den Dump wertlos. Das ist doch total krank, sowas DARF einfach nicht sein. Ich mein, man hat echt Milliarden von Anforderungen an ein DBMS, aber Backup muss doch wohl sauber gehen können, ohne das Ding schreibend vom Netz zu nehmen.

Na ja, die meisten Leute, die ich kenne, wissen das nicht einmal, dass man das müsste und dumpen daher irgendeinen Datenklumpen, den man nachher eh wegschmeißen kann.

mfg
Oli
Top

User avatar
isotopp
RSAC
Posts: 482
Joined: 2003-08-21 10:21
Location: Berlin

Re: MySQL 5.1 - Empfohlen?

Post by isotopp »

Ein MySQL in Linux will man unbedingt auf LVM2 betreiben.
Die Sicherung macht man dann unbedingt mit https://launchpad.net/mylvmbackup
Das ist inzwischen quasi die Standardlösung für dieses Problem.

https://launchpad.net/mylvmbackup unterstützt auch Solaris und FreeBSD ZFS.
Top