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 Programmierer machen sich Gedanken, was hinter der jeweiligen default Konfiguration eines Produktes steht, auch bei opensource.

Oracle tummelt sich seit "Menschengedenken" 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.
.

Man muß schon akribisch suchen, bevor man (vor dem Echtbetrieb) auf die Nachteile dieses "Fortschritts" stößt und die sind für viele viele Typo3- und (Wordpress-) Blog- und Foren- Anwendungen gravierend.

Da ist der jetzt um fast Faktor 10 größere benötigte Festplattenplatz, 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 5.3 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.

Ich möchte nach wie vor ökonomisch arbeiten und vor allem effizient. Jede XEN-Webserver-VM hat bei mir 1GB "init- = mindest" RAM und 4GB "max"RAM. Das scheint für innodb zu wenig zu sein. Darum soll (bei mir) myisam die default storage engine bleiben.

Hier erst mal die Skizze meiner Vorbereitungs-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.
-

Nachdem soeben der Server mit 60 Gigabyte voll war (und dadurch abgestürzt war), mußte ich zwangsläufig der Ursache endlich mal voll auf den Grund gehen.

Bei der Verwendung von innodb für einige Tabellen als Datenbank-Engine ist das Logging für eine eventuelle Replikation per default aktiviert. Die Begrenzung der Logfiles nach Größe und / oder nach Datum ist per default jedoch NICHT aktiviert.

Das muß man bei der Grundinstallation als Erstes ändern. Wen man die mysql Datenbank nicht auf einen zweiten Server repliziert, kann man das Logging komplett abschalten. Das waren jetzt 47 Gigabye an unsinnigen Daten und vor allem auch an Geschwindigkeit. In der my.cnf wird das gemacht. In Kürze schreibe ich auch, wo ich das geändert habe.

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 diesen ascii strings die Datenbanken und Tabellen alle sehen. Also ein Connect per http und Apache2 auf der lokalen Maschine 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 wieder für einige Zeit zu den Akten gelegt, nach mehreren Stunden. Und schon sind wir bei 4.5.16. Ob es da jetzt geht, habe ich nicht mehr probiert.

.

Hier steht mehr: (gefunden April 2013)
.
http://dev.mysql.com/doc/refman/5.1/en/optimize-table.html
.
.... You can use OPTIMIZE TABLE to reclaim the unused space and to defragment the data file. ....
.
.... OPTIMIZE TABLE works for <code class="literal">MyISAM</code>, <code class="literal">InnoDB</code>, and <code class="literal">ARCHIVE</code> tables. ....

Wichtig: Ich habe es noch nicht selbst getestet.
.
"innodb" Tabellen optimieren :

Hier steht noch etwas mehr
http://www.mysqlperformanceblog.com/2010/12/09/thinking-about-running-optimize-on-your-innodb-table-stop/
.
und noch eine Fundstelle:

http://dba.stackexchange.com/questions/23206/how-to-optimize-and-repair-innodb-tables-alter-and-optimize-table-failed

Ouch you have innodb_file_per_table off

I wrote articles on this before. You will have to convert the InnoDB infrastructure.
.

• <code>Oct 29, 2010</code> : My Original Post in StackOverflow
• <code>Apr 01, 2012</code> : Is innodb_file_per_table advisable?
• <code>Mar 25, 2012</code> : Why does InnoDB store all databases in one file?
• <code>Feb 03, 2012</code> : Scheduled optimization of tables in MySQL InnoDB

.
das muß jetzt noch getestet werden.
.