Feb. 2012
mysql 5.5 - Die Kontroverse: "innodb" kontra "myisam"
Mit der Suse 12.1 wird jetzt aktuell mysql 5.5.16 ausgeliefert / angeboten (mysql wurde von Oracle für mehrere hundert Millionen Dollar gekauft). Nur Wenige machen sich Gedanken, was hinter der jeweiligen default Konfiguration eines Produktes steht, auch bei opensource.
Oracle tummelt sich seit Menschegedenken in der Groß-EDV und so fehlt meines Erachtens (im Moment) der Blick für die normalen Anwender, die ja das (zur Zeit noch kostenfreie) mysql so bedeutend (und vor Allem so wertvoll) gemacht hatten. Novell zum Beispiel ist vor vielen Jahren mit dieser Philosophie voll auf die Nase gefallen, nämlich Suse zu kaufen, alles umzustricken und sofort Geld heraus zu quetschen. Suse ging ab Version 9.1 kläglich am Stock.
Zurück zu mysql von Oracle:
Inzwischen ist die "default" Speicher-Engine von myisam auf innodb abgeändert worden und allen Zweiflern wird ein enormer Geschwindigkeitsgewinn und viel mehr Sicherheit angepriesen. Doch über 90% der Typo3 Nutzer und Programmierer haben keine 100.000.000 (100 Millionen) Datensätze mit unabdingbarer refrentieller Integrität und Rollback Notwendigkeit. Sie bauen ganz einfach nur komfortable Webseiten - und viele denken inzwischen über "PostgreSQL" nach.
Nur wenig über die Nachteile bekannt
Man muß schon akribisch suchen, bevor man auf die Nachteile dieses "Fortschritts" stößt und die die sind für viele viele Typo3- und (Wordpress-) Blog- und Foren- Anwendungen gravierend.
Da ist der um fast Faktor 10 größere Plattenplatz, der nur "mit Gewalt" wieder reduziert werden kann. Angeblich kostet Festplattenplatz heute nichts mehr. Das ist natürlich ganz großer Unsinn, denn zum Beispiel jede Datensicherung wird wegen der Datenmenge aus Zeitgründen exorbitant teurer. Auch Export/Import Prozeduren dauern deutlich länger.
Und der zur Verfügung stehende Hauptspeicher soll jetzt auf mindestens 4 Gigabyte (nur für mysql) dimensioniert werden. Damit lassen sich virtuelle Maschinen überhaupt nicht mehr vernünftig betreiben. Unter Suse 11.4 /64bit konnte man mit 12 Gigabyte RAM 6 bis 8 VMs mit je 3 GB Maximalzuordnung super betreiben, mit mysql und myisam natürlich. Dafür braucht man jetzt 32 GB oder gar 64 GB und jetzt kosten richtige profesionelle Server richtiges Geld. Die Hobby Programmierer, die das alles auf dem Notebook ausprobieren, lassen wir mal völlig aussen vor.
Wie löse ich das myisam Problem bei unseren Typo3 Servern ?
Ich möchte nach wie vor ekonomisch arbeiten und vor allem effizient. Jede XEN-Webserver-VM hat bei mir 1GB "init" RAM und 3GB "max"RAM. Das scheint für innodb zu wenig zu sein. Darum soll myisam die default storage engine bleiben.
Hier erst mal die Skizze meiner Prozedur:
Direkt nach der Installation von mysql per yast wird in /etc/my.cnf die Default Engine auf MyISAM eingestellt.
[mysqld]
default-storage-engine=MYISAM
(vorher war unsichtbar folgendes eingestellt:
"default-storage-engine=innodb" - wie gesagt, es ist nicht sichtbar, vermutlich im den Libraries hart codiert.
dann erst wird die mysql Umgebung initialisiert:
/usr/bin/mysql_secure_installation
Dann wird phpmyadmin per yast installiert und ausprobiert und es werden die mysql Default Tabellen überprüft.
Kurz ein Abstecher in eine alte Erfahrung über innodb Eigenschaften
534 - für Typo3 innodb aktivieren ???
und wieder zurück.
-
Und wieder stolpert man über Bugs - Typo3 4.5.11 und Suse 12.1
Verwende ich die seit Jahren gängige Installalationsprozedur jetzt bei TYPO3 4.5.11, so sagt mir hier das Installtool "cannot connect to database".
User, und pw sind absolut korrekt, denn phpMyAdmin kann mit den ascii strings die Datenbanken alle sehen. Also ein externer Connect per http und Apache2 funktioniert, jedenfalls im Prinzip, nur mit TYPO3 nicht.
Was wurde denn da wieder verschlimmbessert ? Bei der 4.5.6 soll das Phänomen schon in Mengen aufgetreten sein.
Ein (leider einmaliger) Workaround war, den Datenbantreiber "mysql" von Hand explizit in die localconf.php einzutragen. Was für ein Umstand, beim zweiten Male funktionierte es wieder nicht.
Damit ist TYPO3 4.5 erledigt, nach mehreren Stunden.



